[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALMp9eRT3+amVEFvX1vzeqDoVP7Fz6a_xUorKYK63+QeyaO4kA@mail.gmail.com>
Date: Thu, 31 Aug 2023 12:28:27 -0700
From: Jim Mattson <jmattson@...gle.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
Tavis Ormandy <taviso@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>, Kyle Huey <me@...ehuey.com>,
"Chang S. Bae" <chang.seok.bae@...el.com>,
Feng Tang <feng.tang@...el.com>,
Andrew Cooper <andrew.cooper3@...rix.com>
Subject: Re: [PATCH] x86/fpu/xstate: Fix PKRU covert channel
On Thu, Aug 31, 2023 at 12:12 PM Dave Hansen <dave.hansen@...el.com> wrote:
>
> On 8/30/23 21:32, Jim Mattson wrote:
> > When XCR0[9] is set, PKRU can be read and written from userspace with
> > XSAVE and XRSTOR, even when CR4.PKE is clear.
> >
> > Clear XCR0[9] when protection keys are disabled.
> >
> > Reported-by: Tavis Ormandy <taviso@...gle.com>
> > Signed-off-by: Jim Mattson <jmattson@...gle.com>
>
> Is there any way to trigger this other than "nopku" on the command-line?
Or by configuration option:
CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS=n
> I'm not sure how scary this particular covert channel is, but it does
> make sense to do this even if it's only to avoid wasting XSAVE space on
> a feature that nobody can use (for things other than covert channels).
>
> Acked-by: Dave Hansen <dave.hansen@...ux.intel.com>
Powered by blists - more mailing lists