Message ID | 20190730191303.206365-1-thgarnie@chromium.org (mailing list archive) |
---|---|
Headers | show |
Series | x86: PIE support to extend KASLR randomization | expand |
On Tue, Jul 30, 2019 at 12:12:44PM -0700, Thomas Garnier wrote: > These patches make some of the changes necessary to build the kernel as > Position Independent Executable (PIE) on x86_64. Another patchset will > add the PIE option and larger architecture changes. Yeah, about this: do we have a longer writeup about the actual benefits of all this and why we should take this all? After all, after looking at the first couple of asm patches, it is posing restrictions to how we deal with virtual addresses in asm (only RIP-relative addressing in 64-bit mode, MOVs with 64-bit immediates, etc, for example) and I'm willing to bet money that some future unrelated change will break PIE sooner or later. And I'd like to have a better justification why we should enforce those new "rules" unconditionally. Thx.
On Tue, Aug 06, 2019 at 05:43:47PM +0200, Borislav Petkov wrote: > On Tue, Jul 30, 2019 at 12:12:44PM -0700, Thomas Garnier wrote: > > These patches make some of the changes necessary to build the kernel as > > Position Independent Executable (PIE) on x86_64. Another patchset will > > add the PIE option and larger architecture changes. > > Yeah, about this: do we have a longer writeup about the actual benefits > of all this and why we should take this all? After all, after looking > at the first couple of asm patches, it is posing restrictions to how > we deal with virtual addresses in asm (only RIP-relative addressing in > 64-bit mode, MOVs with 64-bit immediates, etc, for example) and I'm > willing to bet money that some future unrelated change will break PIE > sooner or later. Possibly objtool can help here; it should be possible to teach it about these rules, and then it will yell when violated. That should avoid regressions.
On Tue, Aug 6, 2019 at 8:51 AM Peter Zijlstra <peterz@infradead.org> wrote: > > On Tue, Aug 06, 2019 at 05:43:47PM +0200, Borislav Petkov wrote: > > On Tue, Jul 30, 2019 at 12:12:44PM -0700, Thomas Garnier wrote: > > > These patches make some of the changes necessary to build the kernel as > > > Position Independent Executable (PIE) on x86_64. Another patchset will > > > add the PIE option and larger architecture changes. > > > > Yeah, about this: do we have a longer writeup about the actual benefits > > of all this and why we should take this all? After all, after looking > > at the first couple of asm patches, it is posing restrictions to how > > we deal with virtual addresses in asm (only RIP-relative addressing in > > 64-bit mode, MOVs with 64-bit immediates, etc, for example) and I'm > > willing to bet money that some future unrelated change will break PIE > > sooner or later. The goal is being able to extend the range of addresses where the kernel can be placed with KASLR. I will look at clarifying that in the future. > > Possibly objtool can help here; it should be possible to teach it about > these rules, and then it will yell when violated. That should avoid > regressions. > I will look into that as well.
On Thu, Aug 29, 2019 at 12:55 PM Thomas Garnier <thgarnie@chromium.org> wrote: > > On Tue, Aug 6, 2019 at 8:51 AM Peter Zijlstra <peterz@infradead.org> wrote: > > > > On Tue, Aug 06, 2019 at 05:43:47PM +0200, Borislav Petkov wrote: > > > On Tue, Jul 30, 2019 at 12:12:44PM -0700, Thomas Garnier wrote: > > > > These patches make some of the changes necessary to build the kernel as > > > > Position Independent Executable (PIE) on x86_64. Another patchset will > > > > add the PIE option and larger architecture changes. > > > > > > Yeah, about this: do we have a longer writeup about the actual benefits > > > of all this and why we should take this all? After all, after looking > > > at the first couple of asm patches, it is posing restrictions to how > > > we deal with virtual addresses in asm (only RIP-relative addressing in > > > 64-bit mode, MOVs with 64-bit immediates, etc, for example) and I'm > > > willing to bet money that some future unrelated change will break PIE > > > sooner or later. > > The goal is being able to extend the range of addresses where the > kernel can be placed with KASLR. I will look at clarifying that in the > future. > > > > > Possibly objtool can help here; it should be possible to teach it about > > these rules, and then it will yell when violated. That should avoid > > regressions. > > > > I will look into that as well. Following a discussion with Kees. I will explore objtool in the follow-up patchset as we still have more elaborate pie changes in the second set. I like the idea overall and I think it would be great if it works.