Messages in this thread | | | 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 |
| |
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.
| |