From: Matt Parnell <mparnell@gmail.com>
To: Matthew Garrett <mjg59@google.com>
Cc: Kees Cook <keescook@chromium.org>,
LSM List <linux-security-module@vger.kernel.org>,
David Howells <dhowells@redhat.com>,
matthew.garrett@nebula.com
Subject: Re: [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even, in confidentiality mode.
Date: Mon, 2 Dec 2019 21:57:11 -0600 [thread overview]
Message-ID: <337e64ca-f2da-d8ff-0b64-fce00c9e1994@gmail.com> (raw)
In-Reply-To: <b887b039-ebf6-5ef1-429e-04792f3cd664@gmail.com>
...possibly a bug on my older 4790k system, on my 8550u this doesn't
seem to happen. Strange.
Either way, I can stop bugging you if you'd like.
On 12/2/19 8:50 PM, Matt Parnell wrote:
> Correction: I'm out of caffeine, tired, and it has made me an idiot.
>
> That message triggers regardless, it seems. I apologize.
>
> On 12/2/19 8:24 PM, Matt Parnell wrote:
>> For what it is worth, this doesn't happen with lockdown disabled.
>>
>> That message and the code that checks for mitigations is in
>> arch/x86/kvm/vmx/vmx.c - for some reason locking down the MSRs is even
>> making the kernel think that the MSR for the mitigation isn't there,
>> meaning that it is also likely not mitigating the bug.
>>
>> On 12/2/19 8:16 PM, Matthew Garrett wrote:
>>> On Mon, Dec 2, 2019 at 6:01 PM Matt Parnell <mparnell@gmail.com> wrote:
>>>> I should also mention the kernel itself thinks it is vulnerable with the
>>>> MSRs locked down:
>>>>
>>>> [ 7.367922] L1TF CPU bug present and SMT on, data leak possible. See
>>>> CVE-2018-3646 and
>>>> https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for
>>>> details.
>>> The lockdown code doesn't touch any of the codepaths the kernel uses
>>> to access MSRs itself (a *lot* would break in that case), so if the
>>> kernel is asserting this inappropriately then that seems like a kernel
>>> bug.
next prev parent reply other threads:[~2019-12-03 3:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-30 6:49 [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even, in confidentiality mode Matt Parnell
2019-11-30 18:36 ` Kees Cook
2019-11-30 19:09 ` Matt Parnell
2019-12-01 20:53 ` Matt Parnell
2019-12-02 18:29 ` Matt Parnell
2019-12-02 22:55 ` Jordan Glover
2019-12-02 23:13 ` Matt Parnell
2019-12-02 23:29 ` Matthew Garrett
2019-12-02 23:31 ` Matt Parnell
2019-12-03 2:13 ` Matt Parnell
2019-12-03 2:16 ` Matthew Garrett
2019-12-03 2:24 ` Matt Parnell
2019-12-03 2:50 ` Matt Parnell
2019-12-03 3:57 ` Matt Parnell [this message]
2019-12-02 19:43 ` Matthew Garrett
2019-12-02 20:39 ` Matt Parnell
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=337e64ca-f2da-d8ff-0b64-fce00c9e1994@gmail.com \
--to=mparnell@gmail.com \
--cc=dhowells@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-security-module@vger.kernel.org \
--cc=matthew.garrett@nebula.com \
--cc=mjg59@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.