Messages in this thread | | | From | Kees Cook <> | Date | Wed, 18 May 2016 10:11:02 -0400 | Subject | Re: [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
| |