Linux-Security-Module Archive on lore.kernel.org
 help / color / Atom feed
From: Matt Parnell <mparnell@gmail.com>
To: Jordan Glover <Golden_Miller83@protonmail.ch>
Cc: Kees Cook <keescook@chromium.org>,
	"linux-security-module@vger.kernel.org" 
	<linux-security-module@vger.kernel.org>,
	"dhowells@redhat.com" <dhowells@redhat.com>,
	"matthew.garrett@nebula.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 17:13:12 -0600
Message-ID: <c355cc94-3ea6-a0fb-af25-8871aae311aa@gmail.com> (raw)
In-Reply-To: <-uRGQFmc8hMANlmvOpPXEib39VyGsx15MXwgVf-vripxhDcjILDfe5O17fyf5MXoZflmIE4avp7SqW4ijO1kHPqgHJMCqg1fWtXeGylu2uc=@protonmail.ch>

I am not presently in a position to check this as I tend to use the
ondemand cpu scheduler, and not userspace tools to manage CPU power
consumption, and get decent battery life doing so because of the built
in settings in the bios.

I can say with certainty that the second option is true, though, however
it should be noted that it is not just for power adjustments that the
MSRs need, at least in many cases to be readable -
spectre-meltdown-checker, for example, relies on checking an MSR to
determine if the foreshadow exploit is mitigated or not.

https://github.com/speed47/spectre-meltdown-checker

On 12/2/19 4:55 PM, Jordan Glover wrote:
> On Monday, December 2, 2019 6:29 PM, Matt Parnell <mparnell@gmail.com> wrote:
>
>> After doing some research it appears that for Intel chips, only a single
>> register needs to be writeable. I'm not sure about AMD etc.
>>
>> intel-undervolt/blob/master/config.h:
>>
>>     #define MSR_ADDR_TEMPERATURE 0x1a2
>>     #define MSR_ADDR_UNITS 0x606
>>     #define MSR_ADDR_VOLTAGE 0x150
>>
>> Perhaps add an MSR whitelist to allow writing, if
>> LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY=Y and
>> CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=Y?
>>
>> CONFIG_SECURITY_LOCKDOWN_LSM_EARLY is likely what prevents Apparmor or
>> some other LSM policy manager allow this behavior...
>>
>> as an option at build time would be more sensible?
>>
>> On 12/1/19 2:53 PM, Matt Parnell wrote:
>>
>>> That is, I was intending to use lockdown from boot, which isn't
>>> changeable after the fact if I'm not mistaken. How possible is granular
>>> control of what is and is not locked down?
>>> On 11/30/19 1:09 PM, Matt Parnell wrote:
>>>
>>>> I can see how using a policy would be beneficial; I only did this
>>>> because as I understood it, policy wouldn't be able to change these
>>>> particular settings since anything attempting to do so would be from
>>>> userspace.
>>>> On 11/30/19 12:36 PM, Kees Cook wrote:
>>>>
>>>>> On Sat, Nov 30, 2019 at 12:49:48AM -0600, Matt Parnell wrote:
>>>>>
>>>>>> From 452b8460e464422d268659a8abb93353a182f8c8 Mon Sep 17 00:00:00 2001
>>>>>> From: Matt Parnell mparnell@gmail.com
>>>>>> Date: Sat, 30 Nov 2019 00:44:09 -0600
>>>>>> Subject: [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even
>>>>>>  in confidentiality mode.
>>>>>> For Intel CPUs, some of the MDS mitigations utilize the new "flush" MSR, and
>>>>>> while this isn't something normally used in userspace, it does cause false
>>>>>> positives for the "Forshadow" vulnerability.
>>>>>> Additionally, Intel CPUs use MSRs for voltage and frequency controls,
>>>>>> which in
>>>>>> many cases is useful for undervolting to avoid excess heat.
> Could you clarify if blocking msr breaks internal power management of intel
> cpu or it only prevents manual tinkering with it by user? If the latter then
> I think it's ok to keep it as is.
>
> Jordan

  reply index

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-30  6:49 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 [this message]
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
2019-12-02 19:43 ` Matthew Garrett
2019-12-02 20:39   ` Matt Parnell

Reply instructions:

You may reply publically 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=c355cc94-3ea6-a0fb-af25-8871aae311aa@gmail.com \
    --to=mparnell@gmail.com \
    --cc=Golden_Miller83@protonmail.ch \
    --cc=dhowells@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=matthew.garrett@nebula.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

Linux-Security-Module Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-security-module/0 linux-security-module/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-security-module linux-security-module/ https://lore.kernel.org/linux-security-module \
		linux-security-module@vger.kernel.org
	public-inbox-index linux-security-module

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-security-module


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git