On Fri, Jul 12, 2019 at 12:06 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > On Fri, Jul 12, 2019 at 06:37:47PM +0200, Alexandre Chartre wrote: > > On 7/12/19 5:16 PM, Thomas Gleixner wrote: > > > > Right. If we decide to expose more parts of the kernel mappings then that's > > > just adding more stuff to the existing user (PTI) map mechanics. > > > > If we expose more parts of the kernel mapping by adding them to the existing > > user (PTI) map, then we only control the mapping of kernel sensitive data but > > we don't control user mapping (with ASI, we exclude all user mappings). > > > > How would you control the mapping of userland sensitive data and exclude them > > from the user map? Would you have the application explicitly identify sensitive > > data (like Andy suggested with a /dev/xpfo device)? > > To what purpose do you want to exclude userspace from the kernel > mapping; that is, what are you mitigating against with that? Mutually distrusting user/guest tenants. Imagine an attack against a VM hosting provider (GCE, for example). If the overall system is well-designed, the host kernel won't possess secrets that are important to the overall hosting network. The interesting secrets are in the memory of other tenants running under the same host. So, if we can mostly or completely avoid mapping one tenant's memory in the host, we reduce the amount of valuable information that could leak via a speculation (or wild read) attack to another tenant. The practicality of such a scheme is obviously an open question.
