[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5j+XTq6vyn176fHCDDgkLtVyBwEC8J3DUDVhy9z87ODF2Q@mail.gmail.com>
Date: Sat, 9 Feb 2013 07:10:16 -0800
From: Kees Cook <keescook@...omium.org>
To: Borislav Petkov <bp@...en8.de>, Kees Cook <keescook@...omium.org>,
Matthew Garrett <matthew.garrett@...ula.com>,
"H. Peter Anvin" <hpa@...or.com>,
LKML <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"x86@...nel.org" <x86@...nel.org>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
linux-security-module <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH] x86: Lock down MSR writing in secure boot
On Sat, Feb 9, 2013 at 1:29 AM, Borislav Petkov <bp@...en8.de> wrote:
> On Fri, Feb 08, 2013 at 10:45:35PM -0800, Kees Cook wrote:
>> Also, _reading_ MSRs from userspace arguably has utility that doesn't
>> compromise ring-0.
>
> And to come back to the original question: what is that utility, who
> would need it on a secure boot system and why?
I have used it for double-checking the state of VMX (is it disabled
and locked), and for making sure that XD isn't masked, checking
thermal stuff, etc. I'm not arguing to keep the MSR driver while in
secure mode, mind you, I was just pointing out that like /dev/mem
there could be some utility to keeping the read half around. That
said, it could also be seen as an info leak. *shrug* My goal was just
to make sure it wasn't writable in the secure boot mode.
-Kees
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists