From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752597AbcERI3o (ORCPT ); Wed, 18 May 2016 04:29:44 -0400 Received: from mail-wm0-f49.google.com ([74.125.82.49]:35918 "EHLO mail-wm0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752097AbcERI3l (ORCPT ); Wed, 18 May 2016 04:29:41 -0400 Date: Wed, 18 May 2016 10:29:35 +0200 From: Ingo Molnar To: Kees Cook Cc: "H. Peter Anvin" , Borislav Petkov , Baoquan He , Yinghai Lu , Thomas Gleixner , Ingo Molnar , "x86@kernel.org" , Andrew Morton , Josh Poimboeuf , Andrey Ryabinin , "H.J. Lu" , Dmitry Vyukov , LKML Subject: Re: [PATCH] x86/boot: Refuse to build with data relocations Message-ID: <20160518082935.GA8163@gmail.com> References: <20160512203104.GA7425@www.outflux.net> <8bc4f1fd-c6f8-4643-becf-4f84be378807@zytor.com> <20160516103051.GA11330@gmail.com> <3b9c1266-f69b-50e4-36fd-ab3e75875293@zytor.com> <4a2a6750-5ee3-4549-a92d-f39a2c0e1aad@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Kees Cook 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