On Sun, Jul 14, 2019 at 08:06:12AM -0700, Andy Lutomirski wrote: > 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. Ah, ok. So it's some virt specific nonsense. I'll go on ignoring it then ;-)
