linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Paul Mackerras <paulus@ozlabs.org>
Cc: benh@kernel.crashing.org, mpe@ellerman.id.au,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH 2/2] powerpc/mm: Replace _PAGE_USER with _PAGE_PRIV
Date: Sat, 05 Mar 2016 13:59:02 +0530	[thread overview]
Message-ID: <87lh5xs4z5.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160302010759.GB3160@oak.ozlabs.ibm.com>

Paul Mackerras <paulus@ozlabs.org> writes:

> [ text/plain ]
> On Fri, Feb 26, 2016 at 08:50:50AM +0530, Aneesh Kumar K.V wrote:
>> _PAGE_PRIV means the page can be accessed only by kernel. This is done
>> to keep pte bits similar to PowerISA 3.0 radix PTE format. User
>> pages are now makred by clearing _PAGE_PRIV bit.
>
>

.....

>> @@ -40,6 +40,11 @@ int __hash_page_4K(unsigned long ea, unsigned long access, unsigned long vsid,
>>  		if (unlikely(access & ~old_pte))
>>  			return 1;
>
> This check is going to do a different thing now as far as
> _PAGE_USER/_PAGE_PRIV is concerned: previously it would prevent a
> non-privileged access to a privileged page from creating a HPTE, now
> it prevents a privileged access to a non-privileged page from creating
> a HPTE.  A privileged access means an access by the kernel to a high
> address, and arguably we would never have a non-privileged PTE at a
> high (i.e. kernel) address, but it's still a semantic change that
> should have been flagged in the patch description.


We don't set _PAGE_PRIVILGED when we have a privilged acess to a non
privilged page. We set it as below (with updated comments)

	/*
	 * We set _PAGE_PRIVILEGED only when
	 * kernel mode access kernel space.
	 *
	 * _PAGE_PRIVILGED is NOT set
	 * 1) when kernel mode access user space
	 * 2) user space access kernel space.
	 */
	if (!(msr & MSR_PR) && !(REGION_ID(ea) == USER_REGION_ID))
		access |= _PAGE_PRIVILEGED;



>
> In fact it wouldn't really matter if we didn't check the privilege
> here and went ahead and created the HPTE - if it's a non-privileged
> access to a privileged page, the HPTE will get its permission bits set
> so as to prevent non-privileged access anyway.
>
>>  		/*
>> +		 * access from user, but pte in _PAGE_PRIV
>> +		 */
>> +		if (unlikely((access & _PAGE_PRIV) != (old_pte & _PAGE_PRIV)))
>> +			return 1;
>
> And this catches both the privileged access to non-privileged page
> case (which the previous statement already caught) and the
> non-privileged access to privileged page case.

The actual PRIVILEGED check is done by the above conditional. 


-aneesh

  reply	other threads:[~2016-03-05  8:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-26  3:20 [RFC PATCH 1/2] powerpc/mm: Update prot_none implementation using _PAGE_READ Aneesh Kumar K.V
2016-02-26  3:20 ` [RFC PATCH 2/2] powerpc/mm: Replace _PAGE_USER with _PAGE_PRIV Aneesh Kumar K.V
2016-02-29  2:36   ` Benjamin Herrenschmidt
2016-02-29  7:49     ` Aneesh Kumar K.V
2016-03-02  1:07   ` Paul Mackerras
2016-03-05  8:29     ` Aneesh Kumar K.V [this message]
2016-03-05 10:41       ` Paul Mackerras
2016-03-02  0:38 ` [RFC PATCH 1/2] powerpc/mm: Update prot_none implementation using _PAGE_READ Paul Mackerras
2016-03-02  1:39 ` Paul Mackerras

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=87lh5xs4z5.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@ozlabs.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).