All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Huang\, Ying" <ying.huang@intel.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Michal Hocko <mhocko@suse.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Andrei Vagin <avagin@openvz.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Jerome Glisse <jglisse@redhat.com>,
	Daniel Colascione <dancol@google.com>,
	Zi Yan <zi.yan@cs.rutgers.edu>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Subject: Re: [PATCH -mm] mm, pagemap: Fix swap offset value for PMD migration entry
Date: Wed, 11 Apr 2018 08:56:58 +0800	[thread overview]
Message-ID: <87r2nmftlx.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <20180410111222.akgtbqsmrpmm2clt@node.shutemov.name> (Kirill A. Shutemov's message of "Tue, 10 Apr 2018 14:12:22 +0300")

"Kirill A. Shutemov" <kirill@shutemov.name> writes:

> On Tue, Apr 10, 2018 at 08:57:19AM +0800, Huang, Ying wrote:
>> >> the swap offset reported doesn't
>> >> reflect this.  And in the loop to report information of each sub-page,
>> >> the swap offset isn't increased accordingly as that for PFN.
>> >> 
>> >> BTW: migration swap entries have PFN information, do we need to
>> >> restrict whether to show them?
>> >
>> > For what reason?  Address obfuscation?
>> 
>> This is an existing feature for PFN report of /proc/<pid>/pagemap,
>> reason is in following commit log.  I am wondering whether that is
>> necessary for migration swap entries too.
>> 
>> ab676b7d6fbf4b294bf198fb27ade5b0e865c7ce
>> Author:     Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>> AuthorDate: Mon Mar 9 23:11:12 2015 +0200
>> Commit:     Linus Torvalds <torvalds@linux-foundation.org>
>> CommitDate: Tue Mar 17 09:31:30 2015 -0700
>> 
>> pagemap: do not leak physical addresses to non-privileged userspace
>> 
>> As pointed by recent post[1] on exploiting DRAM physical imperfection,
>> /proc/PID/pagemap exposes sensitive information which can be used to do
>> attacks.
>> 
>> This disallows anybody without CAP_SYS_ADMIN to read the pagemap.
>> 
>> [1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
>> 
>> [ Eventually we might want to do anything more finegrained, but for now
>>   this is the simple model.   - Linus ]
>
> Note that there's follow up to the commit: 
>
> 1c90308e7a77 ("pagemap: hide physical addresses from non-privileged users")
>
> It introduces pm->show_pfn and it should be applied to swap entries too.

So you think we should hide all swap entry information if
(!pm->show_pfn) regardless they are migration swap entries or not?

Best Regards,
Huang, Ying

WARNING: multiple messages have this Message-ID (diff)
From: "Huang\, Ying" <ying.huang@intel.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Andrew Morton <akpm@linux-foundation.org>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>, Michal Hocko <mhocko@suse.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Andrei Vagin <avagin@openvz.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Jerome Glisse <jglisse@redhat.com>,
	Daniel Colascione <dancol@google.com>,
	Zi Yan <zi.yan@cs.rutgers.edu>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Subject: Re: [PATCH -mm] mm, pagemap: Fix swap offset value for PMD migration entry
Date: Wed, 11 Apr 2018 08:56:58 +0800	[thread overview]
Message-ID: <87r2nmftlx.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <20180410111222.akgtbqsmrpmm2clt@node.shutemov.name> (Kirill A. Shutemov's message of "Tue, 10 Apr 2018 14:12:22 +0300")

"Kirill A. Shutemov" <kirill@shutemov.name> writes:

> On Tue, Apr 10, 2018 at 08:57:19AM +0800, Huang, Ying wrote:
>> >> the swap offset reported doesn't
>> >> reflect this.  And in the loop to report information of each sub-page,
>> >> the swap offset isn't increased accordingly as that for PFN.
>> >> 
>> >> BTW: migration swap entries have PFN information, do we need to
>> >> restrict whether to show them?
>> >
>> > For what reason?  Address obfuscation?
>> 
>> This is an existing feature for PFN report of /proc/<pid>/pagemap,
>> reason is in following commit log.  I am wondering whether that is
>> necessary for migration swap entries too.
>> 
>> ab676b7d6fbf4b294bf198fb27ade5b0e865c7ce
>> Author:     Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>> AuthorDate: Mon Mar 9 23:11:12 2015 +0200
>> Commit:     Linus Torvalds <torvalds@linux-foundation.org>
>> CommitDate: Tue Mar 17 09:31:30 2015 -0700
>> 
>> pagemap: do not leak physical addresses to non-privileged userspace
>> 
>> As pointed by recent post[1] on exploiting DRAM physical imperfection,
>> /proc/PID/pagemap exposes sensitive information which can be used to do
>> attacks.
>> 
>> This disallows anybody without CAP_SYS_ADMIN to read the pagemap.
>> 
>> [1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
>> 
>> [ Eventually we might want to do anything more finegrained, but for now
>>   this is the simple model.   - Linus ]
>
> Note that there's follow up to the commit: 
>
> 1c90308e7a77 ("pagemap: hide physical addresses from non-privileged users")
>
> It introduces pm->show_pfn and it should be applied to swap entries too.

So you think we should hide all swap entry information if
(!pm->show_pfn) regardless they are migration swap entries or not?

Best Regards,
Huang, Ying

  reply	other threads:[~2018-04-11  0:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-08  3:37 [PATCH -mm] mm, pagemap: Fix swap offset value for PMD migration entry Huang, Ying
2018-04-10  0:47 ` Andrew Morton
2018-04-10  0:57   ` Huang, Ying
2018-04-10  0:57     ` Huang, Ying
2018-04-10 11:12     ` Kirill A. Shutemov
2018-04-11  0:56       ` Huang, Ying [this message]
2018-04-11  0:56         ` Huang, Ying
2018-04-10  1:28 ` Huang, Ying
2018-04-10  1:28   ` Huang, Ying

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=87r2nmftlx.fsf@yhuang-dev.intel.com \
    --to=ying.huang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=avagin@openvz.org \
    --cc=dan.j.williams@intel.com \
    --cc=dancol@google.com \
    --cc=jglisse@redhat.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=zi.yan@cs.rutgers.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.