Re: [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease of attacking

["H. Peter Anvin" <hpa@zytor.com>]

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" <andi@firstfloor.org> wrote:

>Marcus Meissner <meissner@suse.de> 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.