It looks like the MM track isn't full, and I think this topic is an important thing to discuss. Cheers, - Jonathan On Sat, Feb 16, 2019 at 3:14 AM Paul Turner <pjt@xxxxxxxxxx> wrote: > > I wanted to second the proposal for address space isolation. > > We have some new techniques to introduce her also, built around some new ideas using page-faults that we believe are interesting. > > To wit, page faults uniquely allow us to fork speculative and non-speculative execution as we can control the retired path within the fault itself (which as it turns out, will obviously never be executed speculatively). > > This lets us provide isolation against variant1 gadgets, as well as guarantee what data may or may not be cache present for the purposes of L1TF and Meltdown mitigation. > > I'm not sure whether or not I'll be able to attend (I have a newborn and there's a lot of other scheduling I'm trying to work out). But Jonathan Adams (cc'd) has been working on this and can speak to it. We also have some write-ups to publish independently of this. > > Thanks, > > - Paul > >> (Joint proposal with James Bottomley) >> >> Address space isolation has been used to protect the kernel from the >> userspace and userspace programs from each other since the invention of >> the virtual memory. >> >> Assuming that kernel bugs and therefore vulnerabilities are inevitable >> it might be worth isolating parts of the kernel to minimize damage >> that these vulnerabilities can cause. >> >> There is already ongoing work in a similar direction, like XPFO [1] and >> temporary mappings proposed for the kernel text poking [2]. >> >> We have several vague ideas how we can take this even further and make >> different parts of kernel run in different address spaces: >> * Remove most of the kernel mappings from the syscall entry and add a >> trampoline when the syscall processing needs to call the "core >> kernel". >> * Make the parts of the kernel that execute in a namespace use their >> own mappings for the namespace private data >> * Extend EXPORT_SYMBOL to include a trampoline so that the code >> running in modules won't map the entire kernel >> * Execute BFP programs in a dedicated address space >> >> These are very general possible directions. We are exploring some of >> them now to understand if the security value is worth the complexity >> and the performance impact. >> >> We believe it would be helpful to discuss the general idea of address >> space isolation inside the kernel, both from the technical aspect of >> how it can be achieved simply and efficiently and from the isolation >> aspect of what actual security guarantees it usefully provides. >> >> [1] https://lore.kernel.org/lkml/cover.1547153058.git.khalid.aziz@xxxxxxxxxx/ >> [2] https://lore.kernel.org/lkml/20190129003422.9328-4-rick.p.edgecombe@xxxxxxxxx/ >> >> -- >> Sincerely yours, >> Mike.
