[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization


> > We do need to consider how we want modules to fit into whatever model we
> > choose, though.  They can be adjacent, or we could go with a more
> > traditional dynamic link model where the modules can be separate, and
> > chained together with the main kernel via the GOT.
> So I believe we should start with 'adjacent'. The thing is, having modules 
> separately randomized mostly helps if any of the secret locations fails and
> we want to prevent hopping from one to the other. But if one the 
> kernel-privileged
> secret location fails then KASLR has already failed to a significant degree...
> So I think the large-PIC model for modules does not buy us any real 
> advantages in 
> practice, and the disadvantages of large-PIC are real and most Linux users 
> have to 
> pay that cost unconditionally, as distro kernels have half of their kernel 
> functionality living in modules.
> But I do see fundamental value in being able to hide the kernel somewhere in 
> a ~48 
> bits address space, especially if we also implement Linus's suggestion to 
> utilize 
> the lower bits as well. 0..281474976710656 is a nicely large range and will 
> get 
> larger with time.
> But it should all be done smartly and carefully:
> For example, there would be collision with regular user-space mappings, right?
> Can local unprivileged users use mmap(MAP_FIXED) probing to figure out where
> the kernel lives?

Local unpriviledged users can probably get your secret bits using
cache probing and jump prediction buffers.

Yes, you don't want to leak the information using mmap(MAP_FIXED), but
CPU will leak it for you, anyway.

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 

Attachment: signature.asc
Description: Digital signature

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.