All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@linux.intel.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Andy Lutomirski <luto@amacapital.net>
Cc: X86 ML <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Minor PKRU bug?
Date: Thu, 21 Jul 2016 15:26:44 -0700	[thread overview]
Message-ID: <57914C24.3040408@linux.intel.com> (raw)
In-Reply-To: <1CBB681E-737A-4799-ADE6-3CDD904D33D3@zytor.com>

On 07/21/2016 02:48 PM, H. Peter Anvin wrote:
>> >I like it, except that reading just a single byte is a bit silly.
>> >OTOH, that's what the current code needs and I see no fundamental
>> >reason to change it until there's a real user.
>>> 
> The thing is that we can't actually test this, since there is no
> machine on which this code path will ever execute.  That concerns me
> a bit.

I rigged the is_prefetch() check to return true on an instruction that I
know causes a sigbus.  If I run without protection keys, this setup sits
in a never-ending fault loop, which is the behavior that we want from
*real* prefetch instructions.

But, if I have that instruction be marked execute-only by pkeys,
is_prefetch() returns false and the app gets the sigbus, and it *looks*
like it came from the (fake) prefetch instruction, which isn't what we want.

It's not exactly a real-world test, but it did convince me that the code
is doing the right thing.

      reply	other threads:[~2016-07-21 22:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-09 21:27 Minor PKRU bug? Andy Lutomirski
2016-07-12 15:32 ` Dave Hansen
2016-07-12 22:55   ` H. Peter Anvin
2016-07-12 22:59     ` Dave Hansen
2016-07-12 22:59     ` Andy Lutomirski
2016-07-21 21:35       ` Dave Hansen
2016-07-21 21:45         ` Andy Lutomirski
2016-07-21 21:48           ` H. Peter Anvin
2016-07-21 22:26             ` Dave Hansen [this message]

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=57914C24.3040408@linux.intel.com \
    --to=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --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 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.