Re: [RFC 1/7] mm: Add new vma flag VM_LOCAL_CPU

[Boaz Harrosh <openosd@gmail.com>]

On 15/03/18 17:34, Matthew Wilcox wrote:
> On Thu, Mar 15, 2018 at 05:27:09PM +0200, Boaz Harrosh wrote:
>> Not really there is already an high trust between the APP and the
>> filesystem Server owning the all of the APP's data. A compromised
>> Server can do lots and lots of bad things before a bug trashes the
>> unaligned tails of a buffer.
>> (And at that the Server only has access to IO buffers in the short window
>>  of the IO execution. Once on IO return this access is disconnected)
> 
> Without a TLB shootdown, you can't guarantee that.  Here's how it works:
> 
> CPU A is notified of a new page, starts accessing the page.
> CPU B decides to access the same page
> CPU A notifies the kernel
> Kernel withdraws the PTE mapping, but doesn't zap it.
> CPU B can still access the page until whatever CPU magic happens to discard
> the PTE from the TLB.
> Kernel decides to recycle the page
> Kernel allocates it to some kernel data structure
> CPU B writes to it, can probably escalate to kernel privileges.
> 
> Now, you're going to argue that the process is trusted and should
> be considered to be part of the kernel from a trust point of view.
> In that case it needs to be distributed as part of the kernel and not
> be an independent user process.
> 

You are right in the General case but this is not the case for ZUF.

The buffers belong to the application, So it is all about the
zus Server having access to the APP buffers but please look exactly
what zufs does:
(Repeated from above)

On the same exact core always (zufs rules ZTs and all)
> A1 we punch in the pages at the per-core-VMA before they are used,
> A2 we then return to user-space, access these pages once.
     from this core only
> A3 Then return to kernel and punch in a drain page at that spot

At A1 A3 stages there is a local TLB-invalidate for the single core
but not a system-wide one. So the window of where the server
has access to app buffers is during the IO and not passed it.

There is a trust that zus server will not access the per-core private
vma from another core, yes. But the way it is implemented this
is very hard to do. Because the vma sits on a O_TMPFILE+exclusive private
to the affinity set thread's stack and is not public to anyone
but this single Z-Thread.

Yes if the zus will access that vma from another core what you say, will
happen but this can only happen on compromised server. And a compromised Server
can mess up the applications IO buffers through the front door so why
worry about a back door. Perhaps I'm missing something?

Thanks
Boaz