From: Kees Cook <keescook@chromium.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Dave Hansen <dave.hansen@intel.com>,
linux-kernel@vger.kernel.org,
kernel-hardening@lists.openwall.com
Subject: Re: [PATCH v3 1/3] lkdtm: Check for SMEP clearing protections
Date: Tue, 18 Jun 2019 00:23:11 -0700 [thread overview]
Message-ID: <201906180019.EEA60F3@keescook> (raw)
In-Reply-To: <580611da-fd97-e82e-b604-581f105416ee@rasmusvillemoes.dk>
On Tue, Jun 18, 2019 at 09:10:13AM +0200, Rasmus Villemoes wrote:
> On 18/06/2019 06.55, Kees Cook wrote:
>
> > +#else
> > + pr_err("FAIL: this test is x86_64-only\n");
> > +#endif
> > +}
>
> Why expose it at all on all other architectures? If you wrap the
> CRASHTYPE() in an #ifdef, you can also guard the whole lkdtm_UNSET_SMEP
> definition (the declaration in lkdtm.h can stay, possibly with a comment
> saying /* x86-64 only */).
My preference for LKDTM is for all the tests to be visible regardless
of architecture so that the testing "environment" doesn't have to change
depending on architecture. I've found it easier to deal with when I ran
test harnesses on Chrome OS where I had cross-architectural scripts.
Doing a side-by-side with a PASS and an XFAIL was more sensible to
compare than a PASS and a missing test.
--
Kees Cook
next prev parent reply other threads:[~2019-06-18 7:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-18 4:55 [PATCH v3 0/3] x86/asm: Pin sensitive CR4 and CR0 bits Kees Cook
2019-06-18 4:55 ` [PATCH v3 1/3] lkdtm: Check for SMEP clearing protections Kees Cook
2019-06-18 7:10 ` Rasmus Villemoes
2019-06-18 7:23 ` Kees Cook [this message]
2019-06-18 4:55 ` [PATCH v3 2/3] x86/asm: Pin sensitive CR4 bits Kees Cook
2019-06-22 9:58 ` [tip:x86/asm] " tip-bot for Kees Cook
2019-06-18 4:55 ` [PATCH v3 3/3] x86/asm: Pin sensitive CR0 bits Kees Cook
2019-06-18 9:38 ` Jann Horn
2019-06-18 12:24 ` Peter Zijlstra
2019-06-18 17:12 ` Kees Cook
2019-06-22 9:58 ` [tip:x86/asm] " tip-bot for 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=201906180019.EEA60F3@keescook \
--to=keescook@chromium.org \
--cc=dave.hansen@intel.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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