From: Solar Designer <email@example.com>
To: Kees Cook <firstname.lastname@example.org>
Cc: Thomas Gleixner <email@example.com>,
Jann Horn <firstname.lastname@example.org>,
Dominik Brodowski <email@example.com>,
Kernel Hardening <firstname.lastname@example.org>,
X86 ML <email@example.com>
Subject: Re: [PATCH v2] x86/asm: Pin sensitive CR4 bits
Date: Thu, 21 Feb 2019 14:06:45 +0100 [thread overview]
Message-ID: <20190221130645.GA8281@openwall.com> (raw)
On Wed, Feb 20, 2019 at 01:20:58PM -0800, Kees Cook wrote:
> On Wed, Feb 20, 2019 at 10:49 AM Solar Designer <firstname.lastname@example.org> wrote:
> > On Wed, Feb 20, 2019 at 10:09:34AM -0800, Kees Cook wrote:
> > > + if (WARN_ONCE((val & cr4_pin) != cr4_pin, "cr4 bypass attempt?!\n"))
> > > + goto again;
> > I think "goto again" is too mild a response given that it occurs after a
> > successful write of a non-pinned value to CR4. I think it'd allow some
> > exploits to eventually win the race: make their desired use of whatever
> > functionality SMEP, etc. would have prevented - which may be just a few
> > instructions they need to run - before the CR4 value is reverted after
> > "goto again". I think it's one of those cases where a kernel panic
> > would be more appropriate.
> It will not land upstream with a BUG() or panic(). Linus has
> explicitly stated that none of this work can do that until it has
> "baked" in the kernel for a couple years.
> In his defense, anyone sufficiently paranoid can already raise the
> priority of a WARN() into a panic via sysctl kernel.panic_on_warn (and
I think there are too many uses of WARN() for anyone sane to enable
that in production, whereas it'd have made sense to enable it for the
few security-related uses.
> > Also, WARN_ONCE possibly introduces a delay sufficient to realistically
> > win this race on the first try. If we choose to warn, we should do it
> > after having reverted the CR4 value, not before.
> Isn't cr4 CPU-local though?
Good point. I don't know. If CR4 is per hardware thread, then the race
would require an interrupt and would be much harder to win.
> Couldn't we turn off interrupts to stop the race?
This won't help. An attack would skip the code that disables interrupts
and land right on the MOV instruction.
next prev parent reply other threads:[~2019-02-21 13:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-20 18:09 [PATCH v2] x86/asm: Pin sensitive CR4 bits Kees Cook
2019-02-20 18:48 ` Solar Designer
2019-02-20 21:20 ` Kees Cook
2019-02-21 13:06 ` Solar Designer [this message]
2019-02-21 16:11 ` Kees Cook
2019-02-21 17:33 ` Sean Christopherson
2019-02-21 17:37 ` Kees Cook
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).