All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Borislav Petkov <bp@suse.de>,
	Baoquan He <bhe@redhat.com>, Yinghai Lu <yinghai@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "x86@kernel.org" <x86@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	"H.J. Lu" <hjl.tools@gmail.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86/boot: Refuse to build with data relocations
Date: Wed, 18 May 2016 10:29:35 +0200	[thread overview]
Message-ID: <20160518082935.GA8163@gmail.com> (raw)
In-Reply-To: <CAGXu5j+zVytGCJK8_fnzWMwNT6YA+SdQP=mt5NRfOymzKVpP6Q@mail.gmail.com>


* 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.

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

Thanks,

	Ingo

  parent reply	other threads:[~2016-05-18  8:29 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-12 20:31 [PATCH] x86/boot: Refuse to build with data relocations Kees Cook
2016-05-12 22:29 ` H. Peter Anvin
2016-05-12 22:54   ` Kees Cook
2016-05-13 20:45     ` H. Peter Anvin
2016-05-16 10:30       ` Ingo Molnar
2016-05-17  8:13         ` Kees Cook
2016-05-17  9:31           ` H. Peter Anvin
2016-05-17 13:53             ` Kees Cook
2016-05-17 16:56               ` H. Peter Anvin
2016-05-17 19:28                 ` Kees Cook
2016-05-17 19:33                   ` H. Peter Anvin
2016-05-18  8:29                   ` Ingo Molnar [this message]
2016-05-18 14:11                     ` Kees Cook
2016-05-20  6:41                       ` Ingo Molnar
2016-05-20 16:37                         ` Kees Cook
2016-05-16 15:57 ` Josh Poimboeuf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160518082935.GA8163@gmail.com \
    --to=mingo@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=aryabinin@virtuozzo.com \
    --cc=bhe@redhat.com \
    --cc=bp@suse.de \
    --cc=dvyukov@google.com \
    --cc=hjl.tools@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.