lkml.org 
[lkml]   [2016]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] x86/boot: Refuse to build with data relocations
On Wed, May 18, 2016 at 4:29 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Kees Cook <keescook@chromium.org> wrote:
>
>> > I think there is something way more subtle going on here, and it bothers me
>> > exactly because it is subtle. It may be that it is OK right now, but there
>> > are alarm bells going on all over my brain on this. I'm going to stare at
>> > this for a bit and see if I can make sense of it; but if it turns out that
>> > what we have is something really problematic it might be better to apply a big
>> > hammer and avoid future breakage once and for all.
>>
>> Sounds good. I would just like to decouple this from the KASLR improvements.
>> This fragility hasn't changed as a result of that work, but I'd really like to
>> have that series put to bed -- I've spent a lot of time already cleaning up it
>> and other areas of the compressed kernel code. :)
>
> So I disagree on that: while technically kASLR is independent of relocations, your
> series already introduced such a relocation bug and I don't want to further
> increase complexity via kASLR without first increasing robustness.

Well, in my defense, the bug was never actually reachable.

> So could we try something to either detect or avoid such subtle and hard to debug
> relocation bugs in very early boot code?

I've sent this (the readelf patch which detects the bug from the KASLR
series), but hpa wants to do a more comprehensive version. Could we
temporarily use my version of this, since it appears to accomplish at
least a subset of the new goal?

And on a related topic, how would you like me to send Thomas Garnier's
memory base randomization series? Pull request, or as a series like
I've done with the other KASLR improvements?

-Kees

--
Kees Cook
Chrome OS & Brillo Security

\
 
 \ /
  Last update: 2016-05-18 16:21    [W:0.086 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site