Re: [LSF/MM TOPIC] Address space isolation inside the kernel

[Jonathan Adams <jwadams@google.com>]

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@google.com> 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@oracle.com/
>> [2] https://lore.kernel.org/lkml/20190129003422.9328-4-rick.p.edgecombe@intel.com/
>>
>> --
>> Sincerely yours,
>> Mike.