linux-kernel - Re: [PATCH] x86/boot: Refuse to build with data relocations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160520064126.GA29418@gmail.com>
Date:	Fri, 20 May 2016 08:41:26 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Kees Cook <keescook@...omium.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...e.de>,
	Baoquan He <bhe@...hat.com>, Yinghai Lu <yinghai@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Andrey Ryabinin <aryabinin@...tuozzo.com>,
	"H.J. Lu" <hjl.tools@...il.com>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/boot: Refuse to build with data relocations


* Kees Cook <keescook@...omium.org> wrote:

> On Wed, May 18, 2016 at 4:29 AM, Ingo Molnar <mingo@...nel.org> wrote:
> >
> > * Kees Cook <keescook@...omium.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.

Hm, the changelog says a crash/reboot might happen:

commit 434a6c9f90f7ab5ade619455df01ef5ebea533ee
Author: Kees Cook <keescook@...omium.org>
Date:   Mon May 9 13:22:04 2016 -0700

    x86/KASLR: Initialize mapping_info every time
    
    As it turns out, mapping_info DOES need to be initialized every
    time, because pgt_data address could be changed during kernel
    relocation. So it can not be build time assigned.
    
    Without this, page tables were not being corrected updated, which
    could cause reboots when a physical address beyond 2G was chosen.

is the changelog wrong?

> > 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?

Yeah, that's fine with me.

> 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?

A series (size limited if necessary) would be nice!

Thanks,

	Ingo