Hi! > > 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. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel