Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752446Ab0KGSde (ORCPT ); Sun, 7 Nov 2010 13:33:34 -0500 Received: from terminus.zytor.com ([198.137.202.10]:40178 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751374Ab0KGSdd (ORCPT ); Sun, 7 Nov 2010 13:33:33 -0500 X-User-Agent: K-9 Mail for Android References: <20101104100914.GC25118@suse.de> <20101104114648.GA23381@elte.hu> <20101104122906.GH25118@suse.de> <20101104135802.GA31416@elte.hu> <20101104141104.GA31753@elte.hu> <20101104143322.GL25118@suse.de> <871v6xt3l1.fsf@basil.nowhere.org> In-Reply-To: <871v6xt3l1.fsf@basil.nowhere.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease of attacking From: "H. Peter Anvin" Date: Sun, 07 Nov 2010 10:32:33 -0800 To: Andi Kleen , Marcus Meissner CC: Ingo Molnar , linux-kernel@vger.kernel.org, jason.wessel@windriver.com, fweisbec@gmail.com, tj@kernel.org, mort@sgi.com, akpm@osdl.org, security@kernel.org, Andrew Morton , Linus Torvalds , Peter Zijlstra , Thomas Gleixner Message-ID: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1936 Lines: 48 We already do virtual relocation on 32 bits, and replicating that on 64 bits wouldn't be hard. However, the linkage script strongly assumes congruency mod 2/4 MiB, and that is probably nontrivial to change. However, that still gives about 9 bits of entrophy to play with. The question is if that is enough, or if we'd have to do more clever hacks. "Andi Kleen" wrote: >Marcus Meissner writes: >> >> I also briefly thought about kernel ASLR, but my knowledge of the >kernel >> loading is too limited whether this is even possible or at all >useful. > >Kernel ASLR sounds like a good idea, although there are some traps. > >On 32bit the available range is not too great, only a few hundred MB >max. Probably less on a larger systems, there will conflicts with a >large mem_map. On 64bit x86 it's nearly 2GB and somewhat easier >(although a large mem_map may still be a problem) > >You still want to not stray too much from a 2MB alignment >to make sure most of the main kernel is handled by a single 2MB TLB >entry. > >It would not be too hard to do today using kexec and loading the kernel >twice. Right now the kexec command doesn't allow specifying >the address, but the kernel interface supports it, so it could >be just implemented in the user tool. > >Doing it with a single boot sequence would be a bit more work. >Right now the relocation entries are not put into the bzImage >and that would be needed. > >That would not cover modules, but it shouldn't be too difficult >to do it for those either. > >-Andi > >-- >ak@linux.intel.com -- Speaking for myself only. -- Sent from my mobile phone. Please pardon any lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/