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.
>