Messages in this thread | | | From | Andy Lutomirski <> | Date | Thu, 21 Jul 2016 14:45:49 -0700 | Subject | Re: Minor PKRU bug? |
| |
On Thu, Jul 21, 2016 at 2:35 PM, Dave Hansen <dave.hansen@linux.intel.com> wrote: > On 07/12/2016 03:59 PM, Andy Lutomirski wrote: >> On Tue, Jul 12, 2016 at 3:55 PM, H. Peter Anvin <hpa@zytor.com> wrote: >>> On 07/12/16 08:32, Dave Hansen wrote: >>>> On 07/09/2016 02:27 PM, Andy Lutomirski wrote: >>>>> is_prefetch in arch/x86/mm/fault.c can be called on a user address >>>>> that's not readable due to PKRU. This could break it. You might need >>>>> to add a get_user_exec or similar. >>>> >>>> Thanks for the heads-up. I think I'll just need a version that does >>>> something along the lines of stac/clac, but with PKRU. >>>> >>>> I think I can do it with an "_exec" variant of probe_kernel_address(), >>>> but it's a bit messy. >>>> >>> Can this particular codepath even be executed on a PKRU-equipped >>> machine? I thought it was a bug fix for a specific AMD CPU line. >> >> It can certainly be executed -- do_sigbus will execute it every time. >> But I guess it doesn't matter if it fails on a PKRU machine, because a >> failure will just report the signal, and the erratum case can't happen >> in the first place. > > Hi Andy, > > I look at it this way: > > Systems without prefetch errata always see is_prefetch() return false. > If is_prefetch() faults when trying to fetch an instruction it returns > false. Protection keys will make it do this. > > Essentially, any pkeys-execute-only code can not have prefetch errata > detected inside it. Any future processor with such an erratum will need > a different workaround. > > What do folks think? Is it worth shoring this up in case of a future > erratum? > > The patch to fix it isn't too invasive (attached).
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.
--Andy
-- Andy Lutomirski AMA Capital Management, LLC
| |