From: Solar Designer <solar@openwall.com>
To: Kees Cook <keescook@chromium.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Jann Horn <jannh@google.com>,
Dominik Brodowski <linux@dominikbrodowski.net>,
linux-kernel@vger.kernel.org,
kernel-hardening@lists.openwall.com, x86@kernel.org
Subject: Re: [PATCH v2] x86/asm: Pin sensitive CR4 bits
Date: Wed, 20 Feb 2019 19:48:59 +0100 [thread overview]
Message-ID: <20190220184859.GA6429@openwall.com> (raw)
In-Reply-To: <20190220180934.GA46255@beast>
On Wed, Feb 20, 2019 at 10:09:34AM -0800, Kees Cook wrote:
> +extern volatile unsigned long cr4_pin;
> +
> static inline void native_write_cr4(unsigned long val)
> {
> +again:
> + val |= cr4_pin;
> asm volatile("mov %0,%%cr4": : "r" (val), "m" (__force_order));
> + /*
> + * If the MOV above was used directly as a ROP gadget we can
> + * notice the lack of pinned bits in "val" and start the function
> + * from the beginning to gain the cr4_pin bits for sure.
> + */
> + 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.
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.
Alexander
next prev parent reply other threads:[~2019-02-20 18:48 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 [this message]
2019-02-20 21:20 ` Kees Cook
2019-02-21 13:06 ` Solar Designer
2019-02-21 16:11 ` Kees Cook
2019-02-21 17:33 ` Sean Christopherson
2019-02-21 17:37 ` Kees Cook
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=20190220184859.GA6429@openwall.com \
--to=solar@openwall.com \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=tglx@linutronix.de \
--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 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).