From: Boaz Harrosh <boazh@netapp.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Matthew Wilcox <willy@infradead.org>,
Jeff Moyer <jmoyer@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
<x86@kernel.org>, Dave Hansen <dave.hansen@linux.intel.com>,
Rik van Riel <riel@redhat.com>, Jan Kara <jack@suse.cz>,
Matthew Wilcox <mawilcox@microsoft.com>,
Amit Golander <Amit.Golander@netapp.com>
Subject: Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU
Date: Tue, 15 May 2018 15:31:02 +0300 [thread overview]
Message-ID: <de0384c7-23a0-fb92-3672-d89b364c5597@netapp.com> (raw)
In-Reply-To: <20180515120939.GA12217@hirez.programming.kicks-ass.net>
On 15/05/18 15:09, Peter Zijlstra wrote:
> On Tue, May 15, 2018 at 02:41:41PM +0300, Boaz Harrosh wrote:
>> On 15/05/18 14:11, Matthew Wilcox wrote:
>
>>> You're still thinking about this from the wrong perspective. If you
>>> were writing a program to attack this facility, how would you do it?
>>> It's not exactly hard to leak one pointer's worth of information.
>>>
>>
>> That would be very hard. Because that program would:
>> - need to be root
>> - need to start and pretend it is zus Server with the all mount
>> thread thing, register new filesystem, grab some pmem devices.
>> - Mount the said filesystem on said pmem. Create core-pinned ZT threads
>> for all CPUs, start accepting IO.
>> - And only then it can start leaking the pointer and do bad things.
>> The bad things it can do to the application, not to the Kernel.
>
> No I think you can do bad things to the kernel at that point. Consider
> it populating the TLBs on the 'wrong' CPU by 'inadvertenly' touching
> 'random' memory.
>
> Then cause an invalidation and get the page re-used for kernel bits.
>
> Then access that page through the 'stale' TLB entry we still have on the
> 'wrong' CPU and corrupt kernel data.
>
Yes a BAD filesystem Server can do bad things I agree. But a filesystem can
do very bad things in any case. through the front door, No? and we trust
it with our data. So there is some trust we already put in a filesystem i think.
I will try to look at this deeper, see if I can actually enforce this policy.
Do you have any ideas? can I force page_faults on the other cores?
Thank you for looking
Boaz
next prev parent reply other threads:[~2018-05-15 12:31 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-14 17:28 [PATCH] mm: Add new vma flag VM_LOCAL_CPU Boaz Harrosh
2018-05-14 18:26 ` Boaz Harrosh
2018-05-15 7:08 ` Christoph Hellwig
2018-05-15 10:45 ` Boaz Harrosh
2018-05-14 19:15 ` Matthew Wilcox
2018-05-14 19:37 ` Boaz Harrosh
2018-05-15 0:41 ` Matthew Wilcox
2018-05-15 10:43 ` Boaz Harrosh
2018-05-15 11:11 ` Matthew Wilcox
2018-05-15 11:41 ` Boaz Harrosh
2018-05-15 12:03 ` Matthew Wilcox
2018-05-15 13:29 ` Boaz Harrosh
2018-05-15 13:50 ` Matthew Wilcox
2018-05-15 14:10 ` Boaz Harrosh
2018-05-15 14:18 ` Matthew Wilcox
2018-05-15 14:30 ` Boaz Harrosh
2018-05-15 12:09 ` Peter Zijlstra
2018-05-15 12:31 ` Boaz Harrosh [this message]
2018-05-15 11:47 ` Peter Zijlstra
2018-05-15 12:01 ` Boaz Harrosh
2018-05-15 12:07 ` Mark Rutland
2018-05-15 12:35 ` Peter Zijlstra
2018-05-15 13:19 ` Boaz Harrosh
2018-05-18 14:14 ` Christopher Lameter
2018-05-22 16:05 ` Boaz Harrosh
2018-05-22 16:18 ` Dave Hansen
2018-05-22 16:46 ` Christopher Lameter
2018-05-22 16:56 ` Peter Zijlstra
2018-05-22 17:03 ` Dave Hansen
2018-05-22 17:35 ` Christopher Lameter
2018-05-22 17:51 ` Matthew Wilcox
2018-05-23 17:30 ` Dave Hansen
2018-05-23 17:46 ` Nadav Amit
2018-05-23 18:10 ` Mark Rutland
2018-05-14 21:49 ` Andrew Morton
2018-05-15 0:44 ` Matthew Wilcox
2018-05-15 11:54 ` Boaz Harrosh
2018-05-15 13:24 ` Boaz Harrosh
2018-05-15 14:17 ` Peter Zijlstra
2018-05-15 14:36 ` Boaz Harrosh
2018-05-15 14:19 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=de0384c7-23a0-fb92-3672-d89b364c5597@netapp.com \
--to=boazh@netapp.com \
--cc=Amit.Golander@netapp.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jack@suse.cz \
--cc=jmoyer@redhat.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mawilcox@microsoft.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=tglx@linutronix.de \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).