From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755275AbcETGlf (ORCPT ); Fri, 20 May 2016 02:41:35 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:33966 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753554AbcETGld (ORCPT ); Fri, 20 May 2016 02:41:33 -0400 Date: Fri, 20 May 2016 08:41:26 +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: <20160520064126.GA29418@gmail.com> References: <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> <20160518082935.GA8163@gmail.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: > On Wed, May 18, 2016 at 4:29 AM, Ingo Molnar wrote: > > > > * 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. > > Well, in my defense, the bug was never actually reachable. Hm, the changelog says a crash/reboot might happen: commit 434a6c9f90f7ab5ade619455df01ef5ebea533ee Author: Kees Cook 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