* [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even, in confidentiality mode.
From: Matt Parnell @ 2019-11-30 6:49 UTC (permalink / raw)
To: linux-security-module; +Cc: dhowells, matthew.garrett, keescook
[-- Attachment #1.1: Type: text/plain, Size: 2587 bytes --]
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.
Signed-off-by: Matt Parnell <mparnell@gmail.com>
---
arch/x86/kernel/msr.c | 5 ++++-
security/lockdown/Kconfig | 12 ++++++++++++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index 1547be359d7f..4adce59455c3 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -80,10 +80,11 @@ static ssize_t msr_write(struct file *file, const
char __user *buf,
int err = 0;
ssize_t bytes = 0;
+#if defined(LOCK_DOWN_DENY_RAW_MSR)
err = security_locked_down(LOCKDOWN_MSR);
if (err)
return err;
-
+#endif
if (count % 8)
return -EINVAL; /* Invalid chunk size */
@@ -135,9 +136,11 @@ static long msr_ioctl(struct file *file, unsigned
int ioc, unsigned long arg)
err = -EFAULT;
break;
}
+#if defined(LOCK_DOWN_DENY_RAW_MSR)
err = security_locked_down(LOCKDOWN_MSR);
if (err)
break;
+#endif
err = wrmsr_safe_regs_on_cpu(cpu, regs);
if (err)
break;
diff --git a/security/lockdown/Kconfig b/security/lockdown/Kconfig
index e84ddf484010..f4fe72c4bf8f 100644
--- a/security/lockdown/Kconfig
+++ b/security/lockdown/Kconfig
@@ -44,4 +44,16 @@ config LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY
code to read confidential material held inside the kernel are
disabled.
+config LOCK_DOWN_DENY_RAW_MSR
+ bool "Lock down and deny raw MSR access"
+ depends on LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY
+ default y
+ help
+ Some Intel based systems require raw MSR access to use the flush
+ MSR for MDS mitigation confirmation. Raw access can also be used
+ to undervolt many Intel CPUs.
+
+ Say Y to prevent access or N to allow raw MSR access for such
+ cases.
+
endchoice
--
2.24.0
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply related
* Re: [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even, in confidentiality mode.
From: Kees Cook @ 2019-11-30 18:36 UTC (permalink / raw)
To: Matt Parnell; +Cc: linux-security-module, dhowells, matthew.garrett
In-Reply-To: <339ca47a-6ed1-4ab4-f8cf-7b205fa9f773@gmail.com>
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.
>
> Signed-off-by: Matt Parnell <mparnell@gmail.com>
I would expect this to just be implemented via LSM policy, not ifdefs
and Kconfig?
-Kees
> ---
> arch/x86/kernel/msr.c | 5 ++++-
> security/lockdown/Kconfig | 12 ++++++++++++
> 2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
> index 1547be359d7f..4adce59455c3 100644
> --- a/arch/x86/kernel/msr.c
> +++ b/arch/x86/kernel/msr.c
> @@ -80,10 +80,11 @@ static ssize_t msr_write(struct file *file, const
> char __user *buf,
> int err = 0;
> ssize_t bytes = 0;
>
> +#if defined(LOCK_DOWN_DENY_RAW_MSR)
> err = security_locked_down(LOCKDOWN_MSR);
> if (err)
> return err;
> -
> +#endif
> if (count % 8)
> return -EINVAL; /* Invalid chunk size */
>
> @@ -135,9 +136,11 @@ static long msr_ioctl(struct file *file, unsigned
> int ioc, unsigned long arg)
> err = -EFAULT;
> break;
> }
> +#if defined(LOCK_DOWN_DENY_RAW_MSR)
> err = security_locked_down(LOCKDOWN_MSR);
> if (err)
> break;
> +#endif
> err = wrmsr_safe_regs_on_cpu(cpu, regs);
> if (err)
> break;
> diff --git a/security/lockdown/Kconfig b/security/lockdown/Kconfig
> index e84ddf484010..f4fe72c4bf8f 100644
> --- a/security/lockdown/Kconfig
> +++ b/security/lockdown/Kconfig
> @@ -44,4 +44,16 @@ config LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY
> code to read confidential material held inside the kernel are
> disabled.
>
> +config LOCK_DOWN_DENY_RAW_MSR
> + bool "Lock down and deny raw MSR access"
> + depends on LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY
> + default y
> + help
> + Some Intel based systems require raw MSR access to use the flush
> + MSR for MDS mitigation confirmation. Raw access can also be used
> + to undervolt many Intel CPUs.
> +
> + Say Y to prevent access or N to allow raw MSR access for such
> + cases.
> +
> endchoice
> --
> 2.24.0
>
>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even, in confidentiality mode.
From: Matt Parnell @ 2019-11-30 19:09 UTC (permalink / raw)
To: Kees Cook; +Cc: linux-security-module, dhowells, matthew.garrett
In-Reply-To: <201911301035.74813D4533@keescook>
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.
>>
>> Signed-off-by: Matt Parnell <mparnell@gmail.com>
> I would expect this to just be implemented via LSM policy, not ifdefs
> and Kconfig?
>
> -Kees
>
>> ---
>> arch/x86/kernel/msr.c | 5 ++++-
>> security/lockdown/Kconfig | 12 ++++++++++++
>> 2 files changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
>> index 1547be359d7f..4adce59455c3 100644
>> --- a/arch/x86/kernel/msr.c
>> +++ b/arch/x86/kernel/msr.c
>> @@ -80,10 +80,11 @@ static ssize_t msr_write(struct file *file, const
>> char __user *buf,
>> int err = 0;
>> ssize_t bytes = 0;
>>
>> +#if defined(LOCK_DOWN_DENY_RAW_MSR)
>> err = security_locked_down(LOCKDOWN_MSR);
>> if (err)
>> return err;
>> -
>> +#endif
>> if (count % 8)
>> return -EINVAL; /* Invalid chunk size */
>>
>> @@ -135,9 +136,11 @@ static long msr_ioctl(struct file *file, unsigned
>> int ioc, unsigned long arg)
>> err = -EFAULT;
>> break;
>> }
>> +#if defined(LOCK_DOWN_DENY_RAW_MSR)
>> err = security_locked_down(LOCKDOWN_MSR);
>> if (err)
>> break;
>> +#endif
>> err = wrmsr_safe_regs_on_cpu(cpu, regs);
>> if (err)
>> break;
>> diff --git a/security/lockdown/Kconfig b/security/lockdown/Kconfig
>> index e84ddf484010..f4fe72c4bf8f 100644
>> --- a/security/lockdown/Kconfig
>> +++ b/security/lockdown/Kconfig
>> @@ -44,4 +44,16 @@ config LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY
>> code to read confidential material held inside the kernel are
>> disabled.
>>
>> +config LOCK_DOWN_DENY_RAW_MSR
>> + bool "Lock down and deny raw MSR access"
>> + depends on LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY
>> + default y
>> + help
>> + Some Intel based systems require raw MSR access to use the flush
>> + MSR for MDS mitigation confirmation. Raw access can also be used
>> + to undervolt many Intel CPUs.
>> +
>> + Say Y to prevent access or N to allow raw MSR access for such
>> + cases.
>> +
>> endchoice
>> --
>> 2.24.0
>>
>>
>
>
>
^ permalink raw reply
* Re: [GIT PULL] pipe: Notification queue preparation
From: pr-tracker-bot @ 2019-11-30 23:05 UTC (permalink / raw)
To: David Howells
Cc: torvalds, dhowells, Rasmus Villemoes, Greg Kroah-Hartman,
Peter Zijlstra, raven, Christian Brauner, keyrings, linux-usb,
linux-block, linux-security-module, linux-fsdevel, linux-api,
linux-kernel
In-Reply-To: <31452.1574721589@warthog.procyon.org.uk>
The pull request you sent on Mon, 25 Nov 2019 22:39:49 +0000:
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/notifications-pipe-prep-20191115
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6a965666b7e7475c2f8c8e724703db58b8a8a445
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [GIT PULL] SELinux patches for v5.5
From: pr-tracker-bot @ 2019-12-01 1:40 UTC (permalink / raw)
To: Paul Moore; +Cc: Linus Torvalds, selinux, linux-security-module, linux-kernel
In-Reply-To: <CAHC9VhRj-vx8AnP5tKcq9joNqWSHRv1bk+3e7DGU9mxjN+fVFg@mail.gmail.com>
The pull request you sent on Tue, 26 Nov 2019 16:24:34 -0500:
> git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git tags/selinux-pr-20191126
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ba75082efc18ced6def42e8f85c494aa2578760e
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even, in confidentiality mode.
From: Matt Parnell @ 2019-12-01 20:53 UTC (permalink / raw)
To: Kees Cook; +Cc: linux-security-module, dhowells, matthew.garrett
In-Reply-To: <f415ec28-8440-3b29-176c-50da09247ea3@gmail.com>
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.
>>>
>>> Signed-off-by: Matt Parnell <mparnell@gmail.com>
>> I would expect this to just be implemented via LSM policy, not ifdefs
>> and Kconfig?
>>
>> -Kees
>>
>>> ---
>>> arch/x86/kernel/msr.c | 5 ++++-
>>> security/lockdown/Kconfig | 12 ++++++++++++
>>> 2 files changed, 16 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
>>> index 1547be359d7f..4adce59455c3 100644
>>> --- a/arch/x86/kernel/msr.c
>>> +++ b/arch/x86/kernel/msr.c
>>> @@ -80,10 +80,11 @@ static ssize_t msr_write(struct file *file, const
>>> char __user *buf,
>>> int err = 0;
>>> ssize_t bytes = 0;
>>>
>>> +#if defined(LOCK_DOWN_DENY_RAW_MSR)
>>> err = security_locked_down(LOCKDOWN_MSR);
>>> if (err)
>>> return err;
>>> -
>>> +#endif
>>> if (count % 8)
>>> return -EINVAL; /* Invalid chunk size */
>>>
>>> @@ -135,9 +136,11 @@ static long msr_ioctl(struct file *file, unsigned
>>> int ioc, unsigned long arg)
>>> err = -EFAULT;
>>> break;
>>> }
>>> +#if defined(LOCK_DOWN_DENY_RAW_MSR)
>>> err = security_locked_down(LOCKDOWN_MSR);
>>> if (err)
>>> break;
>>> +#endif
>>> err = wrmsr_safe_regs_on_cpu(cpu, regs);
>>> if (err)
>>> break;
>>> diff --git a/security/lockdown/Kconfig b/security/lockdown/Kconfig
>>> index e84ddf484010..f4fe72c4bf8f 100644
>>> --- a/security/lockdown/Kconfig
>>> +++ b/security/lockdown/Kconfig
>>> @@ -44,4 +44,16 @@ config LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY
>>> code to read confidential material held inside the kernel are
>>> disabled.
>>>
>>> +config LOCK_DOWN_DENY_RAW_MSR
>>> + bool "Lock down and deny raw MSR access"
>>> + depends on LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY
>>> + default y
>>> + help
>>> + Some Intel based systems require raw MSR access to use the flush
>>> + MSR for MDS mitigation confirmation. Raw access can also be used
>>> + to undervolt many Intel CPUs.
>>> +
>>> + Say Y to prevent access or N to allow raw MSR access for such
>>> + cases.
>>> +
>>> endchoice
>>> --
>>> 2.24.0
>>>
>>>
>>
>>
^ permalink raw reply
* Re: [PATCH 0/2] Revert patches fixing probing of interrupts
From: Stefan Berger @ 2019-12-01 23:54 UTC (permalink / raw)
To: Jarkko Sakkinen, Stefan Berger
Cc: linux-integrity, linux-kernel, stable, linux-security-module
In-Reply-To: <20191129223418.GA15726@linux.intel.com>
On 11/29/19 5:37 PM, Jarkko Sakkinen wrote:
> On Tue, Nov 26, 2019 at 08:17:51AM -0500, Stefan Berger wrote:
>> From: Stefan Berger <stefanb@linux.ibm.com>
>>
>> Revert the patches that were fixing the probing of interrupts due
>> to reports of interrupt stroms on some systems
> Can you explain how reverting is going to fix the issue?
The reverts fix 'the interrupt storm issue' that they are causing on
some systems but don't fix the issue with the interrupt mode not being
used. I was hoping Jerry would get access to a system faster but this
didn't seem to be the case. So sending these patches seemed the better
solution than leaving 5.4.x with the problem but going back to when it
worked 'better.'
>
> This is wrong way to move forward. The root cause must be identified
> first and then decide actions like always in any situation.
>
> /Jarkko
^ permalink raw reply
* Re: [PATCH -next] x86/efi: remove unused variables
From: Nayna @ 2019-12-02 14:38 UTC (permalink / raw)
To: YueHaibing, jmorris, serge, nayna, zohar, dhowells, jwboyer
Cc: linux-security-module, linux-kernel
In-Reply-To: <20191115130830.13320-1-yuehaibing@huawei.com>
On 11/15/19 8:08 AM, YueHaibing wrote:
> commit ad723674d675 ("x86/efi: move common keyring
> handler functions to new file") leave this unused.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> security/integrity/platform_certs/load_uefi.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
> index 4369204..111898a 100644
> --- a/security/integrity/platform_certs/load_uefi.c
> +++ b/security/integrity/platform_certs/load_uefi.c
> @@ -11,11 +11,6 @@
> #include "../integrity.h"
> #include "keyring_handler.h"
>
> -static efi_guid_t efi_cert_x509_guid __initdata = EFI_CERT_X509_GUID;
> -static efi_guid_t efi_cert_x509_sha256_guid __initdata =
> - EFI_CERT_X509_SHA256_GUID;
> -static efi_guid_t efi_cert_sha256_guid __initdata = EFI_CERT_SHA256_GUID;
> -
> /*
> * Look to see if a UEFI variable called MokIgnoreDB exists and return true if
> * it does.
Thanks for noticing and fixing this.
Thanks & Regards,
- Nayna
^ permalink raw reply
* Re: [PATCH v24 12/24] x86/sgx: Linux Enclave Driver
From: Haitao Huang @ 2019-12-02 15:48 UTC (permalink / raw)
To: linux-kernel, x86, linux-sgx, Jarkko Sakkinen
Cc: akpm, dave.hansen, sean.j.christopherson, nhorman, npmccallum,
serge.ayoun, shay.katz-zamir, haitao.huang, andriy.shevchenko,
tglx, kai.svahn, bp, josh, luto, kai.huang, rientjes, cedric.xing,
puiterwijk, linux-security-module, Suresh Siddha
In-Reply-To: <20191129231326.18076-13-jarkko.sakkinen@linux.intel.com>
On Fri, 29 Nov 2019 17:13:14 -0600, Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
> +
> + for (c = 0 ; c < addp.length; c += PAGE_SIZE) {
> + if (signal_pending(current)) {
> + ret = -ERESTARTSYS;
> + break;
> + }
This IOC is not idempotent as pages EADDed at this point can not be
re-EADDed again. So we can't return ERESTARTSYS
Haitao
^ permalink raw reply
* Re: [GIT PULL] SELinux patches for v5.5
From: Mimi Zohar @ 2019-12-02 15:58 UTC (permalink / raw)
To: Paul Moore; +Cc: selinux, linux-security-module, Roberto Sassu, initramfs
In-Reply-To: <CAHC9VhRj-vx8AnP5tKcq9joNqWSHRv1bk+3e7DGU9mxjN+fVFg@mail.gmail.com>
[Truncated Cc list, adding Roberto and the initramfs mailing list]
Hi Paul,
On Tue, 2019-11-26 at 16:24 -0500, Paul Moore wrote:
> - Allow file labeling before the policy is loaded. This should ease
> some of the burden when the policy is initially loaded (no need to
> relabel files), but it should also help enable some new system
> concepts which dynamically create the root filesystem in the initrd.
Any chance you're planning on using Roberto's patches for including
security xattrs in the initramfs?[1] Any help reviewing his patches
would be much appreciated!
thanks,
Mimi
[1] https://www.spinics.net/lists/linux-initramfs/msg04771.html
^ permalink raw reply
* Re: general protection fault in __schedule (2)
From: Sean Christopherson @ 2019-12-02 16:56 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzkaller, syzbot, Casey Schaufler, Frederic Weisbecker,
Greg Kroah-Hartman, H. Peter Anvin, Jim Mattson, James Morris,
Raslan, KarimAllah, Kate Stewart, KVM list, LKML,
linux-security-module, Ingo Molnar, Ingo Molnar, Pavel Tatashin,
Paolo Bonzini, Philippe Ombredanne, Radim Krčmář,
Serge E. Hallyn, syzkaller-bugs, Thomas Gleixner,
the arch/x86 maintainers
In-Reply-To: <CACT4Y+Yu2LxcpQmNMjVTzc4bWojda0+qWJmrdRSc-XTyN8C20A@mail.gmail.com>
On Thu, Nov 28, 2019 at 10:53:10AM +0100, Dmitry Vyukov wrote:
> On Mon, Nov 25, 2019 at 6:54 PM Sean Christopherson
> <sean.j.christopherson@intel.com> wrote:
> > I have no objection to explicit status tracking or getting pinged on old
> > open bugs. I suppose I don't even mind the belated bisection, I'd probably
> > whine if syzbot didn't do the bisection :-).
> >
> > What's annoying is the report doesn't provide any information about when it
> > originally occured or on what kernel it originally failed. It didn't occur
> > to me that the original bug might be a year old and I only realized it was
> > from an old kernel when I saw "4.19.0-rc4+" in the dashboard's sample crash
> > log. Knowing that the original crash was a year old would have saved me
> > 5-10 minutes of getting myself oriented.
> >
> > Could syzbot provide the date and reported kernel version (assuming the
> > kernel version won't be misleading) of the original failure in its reports?
>
> +syzkaller mailing list for syzbot discussion
>
> We tried to provide some aggregate info in email reports long time ago
> (like trees where it occurred, number of crashes). The problem was
> that any such info captured in emails become stale very quickly. E.g.
> later somebody looks at the report and thinking "oh, linux-next only"
> or "it happened only once", but maybe it's not for a long time. E.g.
> if we say "it last happened 3 months" ago, maybe it's just happened
> again once we send it... While this "emails always provide latest
> updates" works for kernel in other context b/c updates provided by
> humans and there is no other source of truth; it does not play well
> with automated systems, or syzbot will need to send several emails per
> second, because it's really the rate at which things change.
>
> If we add some info, which one should it be? The original crash, the
> one used for bisection, or the latest one? All these are different...
> syzbot does not know "4.19.0-rc4+" strings for commits, it generally
> identifies commits by hashes. There are dates, but then again which
> one? Author or commit? Author is what generally shown, but I remember
> a number of patches where Author date is 1.5 years old for just merged
> commits :)
>
> There is another problem: if we stuff too many info into emails,
> people still stop reading them. This is very serious and real concern.
> If you have 1000-page manual, it's well documented, but it's
> equivalent to no docs at all, nobody is reading 1000 pages to find 1
> bit of info. Especially if you don't know that there is an important
> bit that you need to find in the first place...
>
> What would be undoubtedly positive is presenting information on the
> dashboard better (If we find a way).
> Currently the page says near the top:
>
> First crash: 478d, last: 430d
>
> The idea was that "last: 430d" is supposed to communicate the bit of
> info that confused you. Is it what you were looking for? Is there a
> better way to present it?
Ah, yes, that's what I was looking for. Tweaking the presention of the
dashboard and/or email reports, e.g. to encourage readers to go to the
dashboard in the first place, would definitely help. A few ideas:
- Display the first/last crash dates in yyyy/mm/dd format rather than
showing the number of days since failure. I didn't even realize 478d
and 430d were relative dates until your email, though that's probably
more my failing than syzbot's :-)
- On the dashboard page, separate the basic crash info from the bisection
details, e.g. display the basic crash info using the same table format
as "Duplicate of" and "similar bugs", and/or move the bisection details
below the aforementioned tables. The basic info stands out fairly well
when there aren't bisection details, but for bugs with bisection info
the combined info becomes a wall of text that my eyes tend to skip over.
- Don't rely on the recipients of bisection reports having the original
crash report, e.g. use the dashboard link to reference the crash and
always display it at the top, maybe isolated via whitespace. The other
auto-generated reports could use a similar format to teach folks that
the dashboard link is the canonical reference.
For example, on bisection show:
syzbot has bisected crash:
https://syzkaller.appspot.com/bug?extid=7e2ab84953e4084a638d
first bad commit:
commit 8fcc4b5923af5de58b80b53a069453b135693304
Author: Jim Mattson <jmattson@google.com>
Date: Tue Jul 10 09:27:20 2018 +0000
kvm: nVMX: Introduce KVM_CAP_NESTED_STATE
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=124cdbace00000
start commit: 234b69e3 ocfs2: fix ocfs2 read block panic
git tree: upstream
final crash: https://syzkaller.appspot.com/x/report.txt?x=114cdbace00000
console output: https://syzkaller.appspot.com/x/log.txt?x=164cdbace00000
kernel config: https://syzkaller.appspot.com/x/.config?x=5fa12be50bca08d8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=150f0a4e400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17f67111400000
vs.
syzbot has bisected this bug to:
commit 8fcc4b5923af5de58b80b53a069453b135693304
Author: Jim Mattson <jmattson@google.com>
Date: Tue Jul 10 09:27:20 2018 +0000
kvm: nVMX: Introduce KVM_CAP_NESTED_STATE
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=124cdbace00000
start commit: 234b69e3 ocfs2: fix ocfs2 read block panic
git tree: upstream
final crash: https://syzkaller.appspot.com/x/report.txt?x=114cdbace00000
console output: https://syzkaller.appspot.com/x/log.txt?x=164cdbace00000
kernel config: https://syzkaller.appspot.com/x/.config?x=5fa12be50bca08d8
dashboard link: https://syzkaller.appspot.com/bug?extid=7e2ab84953e4084a638d
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=150f0a4e400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17f67111400000
And a similar format for the initial crash report:
syzbot found the following crash:
https://syzkaller.appspot.com/bug?extid=00be5da1d75f1cc95f6b
HEAD commit: ad062195 Merge tag 'platform-drivers-x86-v5.4-1' of git://..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=154910ad600000
kernel config: https://syzkaller.appspot.com/x/.config?x=f9fc16a6374d5fd0
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
vs.
syzbot found the following crash on:
HEAD commit: ad062195 Merge tag 'platform-drivers-x86-v5.4-1' of git://..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=154910ad600000
kernel config: https://syzkaller.appspot.com/x/.config?x=f9fc16a6374d5fd0
dashboard link: https://syzkaller.appspot.com/bug?extid=00be5da1d75f1cc95f6b
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
^ permalink raw reply
* Re: [PATCH v24 12/24] x86/sgx: Linux Enclave Driver
From: Sean Christopherson @ 2019-12-02 18:21 UTC (permalink / raw)
To: Haitao Huang
Cc: linux-kernel, x86, linux-sgx, Jarkko Sakkinen, akpm, dave.hansen,
nhorman, npmccallum, serge.ayoun, shay.katz-zamir, haitao.huang,
andriy.shevchenko, tglx, kai.svahn, bp, josh, luto, kai.huang,
rientjes, cedric.xing, puiterwijk, linux-security-module,
Suresh Siddha
In-Reply-To: <op.0b6gvhtiwjvjmi@hhuan26-mobl.amr.corp.intel.com>
On Mon, Dec 02, 2019 at 09:48:43AM -0600, Haitao Huang wrote:
> On Fri, 29 Nov 2019 17:13:14 -0600, Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
>
>
> >+
> >+ for (c = 0 ; c < addp.length; c += PAGE_SIZE) {
> >+ if (signal_pending(current)) {
> >+ ret = -ERESTARTSYS;
> >+ break;
> >+ }
>
> This IOC is not idempotent as pages EADDed at this point can not be
> re-EADDed again. So we can't return ERESTARTSYS
Ah, and now I remember why I opted for modifying the parameters directly
instead of including a "number processed" field. Andy pointed out the
ERESTARTSYS thing in the original multi-page add RFC[*], so presumably
updating the params and returning ERESTARTSYS is legal/acceptable.
[*] https://lkml.kernel.org/r/CALCETrUb4X9_L9RXKhmyNpfSCsbNodP=BfbfO8Fz_efq24jp8w@mail.gmail.com
^ permalink raw reply
* Re: [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even, in confidentiality mode.
From: Matt Parnell @ 2019-12-02 18:29 UTC (permalink / raw)
To: Kees Cook; +Cc: linux-security-module, dhowells, matthew.garrett
In-Reply-To: <f988a531-a7f8-cef6-d3b4-6fbd89f5351f@gmail.com>
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.
>>>>
>>>> Signed-off-by: Matt Parnell <mparnell@gmail.com>
>>> I would expect this to just be implemented via LSM policy, not ifdefs
>>> and Kconfig?
>>>
>>> -Kees
>>>
>>>> ---
>>>> arch/x86/kernel/msr.c | 5 ++++-
>>>> security/lockdown/Kconfig | 12 ++++++++++++
>>>> 2 files changed, 16 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
>>>> index 1547be359d7f..4adce59455c3 100644
>>>> --- a/arch/x86/kernel/msr.c
>>>> +++ b/arch/x86/kernel/msr.c
>>>> @@ -80,10 +80,11 @@ static ssize_t msr_write(struct file *file, const
>>>> char __user *buf,
>>>> int err = 0;
>>>> ssize_t bytes = 0;
>>>>
>>>> +#if defined(LOCK_DOWN_DENY_RAW_MSR)
>>>> err = security_locked_down(LOCKDOWN_MSR);
>>>> if (err)
>>>> return err;
>>>> -
>>>> +#endif
>>>> if (count % 8)
>>>> return -EINVAL; /* Invalid chunk size */
>>>>
>>>> @@ -135,9 +136,11 @@ static long msr_ioctl(struct file *file, unsigned
>>>> int ioc, unsigned long arg)
>>>> err = -EFAULT;
>>>> break;
>>>> }
>>>> +#if defined(LOCK_DOWN_DENY_RAW_MSR)
>>>> err = security_locked_down(LOCKDOWN_MSR);
>>>> if (err)
>>>> break;
>>>> +#endif
>>>> err = wrmsr_safe_regs_on_cpu(cpu, regs);
>>>> if (err)
>>>> break;
>>>> diff --git a/security/lockdown/Kconfig b/security/lockdown/Kconfig
>>>> index e84ddf484010..f4fe72c4bf8f 100644
>>>> --- a/security/lockdown/Kconfig
>>>> +++ b/security/lockdown/Kconfig
>>>> @@ -44,4 +44,16 @@ config LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY
>>>> code to read confidential material held inside the kernel are
>>>> disabled.
>>>>
>>>> +config LOCK_DOWN_DENY_RAW_MSR
>>>> + bool "Lock down and deny raw MSR access"
>>>> + depends on LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY
>>>> + default y
>>>> + help
>>>> + Some Intel based systems require raw MSR access to use the flush
>>>> + MSR for MDS mitigation confirmation. Raw access can also be used
>>>> + to undervolt many Intel CPUs.
>>>> +
>>>> + Say Y to prevent access or N to allow raw MSR access for such
>>>> + cases.
>>>> +
>>>> endchoice
>>>> --
>>>> 2.24.0
>>>>
>>>>
>>>
^ permalink raw reply
* possible deadlock in process_measurement (2)
From: syzbot @ 2019-12-02 18:45 UTC (permalink / raw)
To: dmitry.kasatkin, jmorris, linux-integrity, linux-kernel,
linux-security-module, serge, syzkaller-bugs, zohar
Hello,
syzbot found the following crash on:
HEAD commit: 81b6b964 Merge branch 'master' of git://git.kernel.org/pub..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17019696e00000
kernel config: https://syzkaller.appspot.com/x/.config?x=333b76551307b2a0
dashboard link: https://syzkaller.appspot.com/bug?extid=18a1619cceea30ed45af
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+18a1619cceea30ed45af@syzkaller.appspotmail.com
======================================================
WARNING: possible circular locking dependency detected
5.4.0-syzkaller #0 Not tainted
------------------------------------------------------
syz-executor.2/596 is trying to acquire lock:
ffff88802b0761a0 (&ovl_i_mutex_key[depth]){+.+.}, at: inode_lock
include/linux/fs.h:791 [inline]
ffff88802b0761a0 (&ovl_i_mutex_key[depth]){+.+.}, at:
process_measurement+0x6f4/0x1810 security/integrity/ima/ima_main.c:230
but task is already holding lock:
ffff8880547b07d0 (&sig->cred_guard_mutex){+.+.}, at: prepare_bprm_creds
fs/exec.c:1409 [inline]
ffff8880547b07d0 (&sig->cred_guard_mutex){+.+.}, at:
__do_execve_file.isra.0+0x376/0x22b0 fs/exec.c:1754
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&sig->cred_guard_mutex){+.+.}:
__mutex_lock_common kernel/locking/mutex.c:959 [inline]
__mutex_lock+0x156/0x13c0 kernel/locking/mutex.c:1106
mutex_lock_killable_nested+0x16/0x20 kernel/locking/mutex.c:1136
lock_trace+0x4a/0xe0 fs/proc/base.c:406
proc_pid_personality+0x1c/0xd0 fs/proc/base.c:2961
proc_single_show+0xfd/0x1c0 fs/proc/base.c:756
seq_read+0x4ca/0x1110 fs/seq_file.c:229
do_loop_readv_writev fs/read_write.c:714 [inline]
do_loop_readv_writev fs/read_write.c:701 [inline]
do_iter_read+0x4a4/0x660 fs/read_write.c:935
vfs_readv+0xf0/0x160 fs/read_write.c:997
do_preadv+0x1c4/0x280 fs/read_write.c:1089
__do_sys_preadv fs/read_write.c:1139 [inline]
__se_sys_preadv fs/read_write.c:1134 [inline]
__x64_sys_preadv+0x9a/0xf0 fs/read_write.c:1134
do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #2 (&p->lock){+.+.}:
__mutex_lock_common kernel/locking/mutex.c:959 [inline]
__mutex_lock+0x156/0x13c0 kernel/locking/mutex.c:1106
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1121
seq_read+0x71/0x1110 fs/seq_file.c:161
do_loop_readv_writev fs/read_write.c:714 [inline]
do_loop_readv_writev fs/read_write.c:701 [inline]
do_iter_read+0x4a4/0x660 fs/read_write.c:935
vfs_readv+0xf0/0x160 fs/read_write.c:997
kernel_readv fs/splice.c:359 [inline]
default_file_splice_read+0x482/0x980 fs/splice.c:414
do_splice_to+0x127/0x180 fs/splice.c:877
splice_direct_to_actor+0x2d2/0x970 fs/splice.c:954
do_splice_direct+0x1da/0x2a0 fs/splice.c:1063
do_sendfile+0x597/0xd00 fs/read_write.c:1464
__do_sys_sendfile64 fs/read_write.c:1525 [inline]
__se_sys_sendfile64 fs/read_write.c:1511 [inline]
__x64_sys_sendfile64+0x1dd/0x220 fs/read_write.c:1511
do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #1 (sb_writers#3){.+.+}:
percpu_down_read include/linux/percpu-rwsem.h:40 [inline]
__sb_start_write+0x241/0x460 fs/super.c:1672
sb_start_write include/linux/fs.h:1650 [inline]
mnt_want_write+0x3f/0xc0 fs/namespace.c:354
ovl_want_write+0x76/0xa0 fs/overlayfs/util.c:21
ovl_setattr+0xdd/0x8b0 fs/overlayfs/inode.c:27
notify_change+0xad7/0xfb0 fs/attr.c:337
do_truncate+0x158/0x220 fs/open.c:64
handle_truncate fs/namei.c:2998 [inline]
do_last fs/namei.c:3414 [inline]
path_openat+0x2d63/0x46d0 fs/namei.c:3525
do_filp_open+0x1a1/0x280 fs/namei.c:3555
do_sys_open+0x3fe/0x5d0 fs/open.c:1097
ksys_open include/linux/syscalls.h:1385 [inline]
__do_sys_creat fs/open.c:1155 [inline]
__se_sys_creat fs/open.c:1153 [inline]
__x64_sys_creat+0x61/0x80 fs/open.c:1153
do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #0 (&ovl_i_mutex_key[depth]){+.+.}:
check_prev_add kernel/locking/lockdep.c:2476 [inline]
check_prevs_add kernel/locking/lockdep.c:2581 [inline]
validate_chain kernel/locking/lockdep.c:2971 [inline]
__lock_acquire+0x2596/0x4a00 kernel/locking/lockdep.c:3955
lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4485
down_write+0x93/0x150 kernel/locking/rwsem.c:1534
inode_lock include/linux/fs.h:791 [inline]
process_measurement+0x6f4/0x1810
security/integrity/ima/ima_main.c:230
ima_file_check+0xc5/0x110 security/integrity/ima/ima_main.c:438
do_last fs/namei.c:3412 [inline]
path_openat+0x113d/0x46d0 fs/namei.c:3525
do_filp_open+0x1a1/0x280 fs/namei.c:3555
do_open_execat+0x137/0x690 fs/exec.c:857
__do_execve_file.isra.0+0x1702/0x22b0 fs/exec.c:1762
do_execveat_common fs/exec.c:1868 [inline]
do_execve fs/exec.c:1885 [inline]
__do_sys_execve fs/exec.c:1961 [inline]
__se_sys_execve fs/exec.c:1956 [inline]
__x64_sys_execve+0x8f/0xc0 fs/exec.c:1956
do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe
other info that might help us debug this:
Chain exists of:
&ovl_i_mutex_key[depth] --> &p->lock --> &sig->cred_guard_mutex
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&sig->cred_guard_mutex);
lock(&p->lock);
lock(&sig->cred_guard_mutex);
lock(&ovl_i_mutex_key[depth]);
*** DEADLOCK ***
1 lock held by syz-executor.2/596:
#0: ffff8880547b07d0 (&sig->cred_guard_mutex){+.+.}, at:
prepare_bprm_creds fs/exec.c:1409 [inline]
#0: ffff8880547b07d0 (&sig->cred_guard_mutex){+.+.}, at:
__do_execve_file.isra.0+0x376/0x22b0 fs/exec.c:1754
stack backtrace:
CPU: 1 PID: 596 Comm: syz-executor.2 Not tainted 5.4.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x197/0x210 lib/dump_stack.c:118
print_circular_bug.isra.0.cold+0x163/0x172 kernel/locking/lockdep.c:1685
check_noncircular+0x32e/0x3e0 kernel/locking/lockdep.c:1809
check_prev_add kernel/locking/lockdep.c:2476 [inline]
check_prevs_add kernel/locking/lockdep.c:2581 [inline]
validate_chain kernel/locking/lockdep.c:2971 [inline]
__lock_acquire+0x2596/0x4a00 kernel/locking/lockdep.c:3955
lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4485
down_write+0x93/0x150 kernel/locking/rwsem.c:1534
inode_lock include/linux/fs.h:791 [inline]
process_measurement+0x6f4/0x1810 security/integrity/ima/ima_main.c:230
ima_file_check+0xc5/0x110 security/integrity/ima/ima_main.c:438
do_last fs/namei.c:3412 [inline]
path_openat+0x113d/0x46d0 fs/namei.c:3525
do_filp_open+0x1a1/0x280 fs/namei.c:3555
do_open_execat+0x137/0x690 fs/exec.c:857
__do_execve_file.isra.0+0x1702/0x22b0 fs/exec.c:1762
do_execveat_common fs/exec.c:1868 [inline]
do_execve fs/exec.c:1885 [inline]
__do_sys_execve fs/exec.c:1961 [inline]
__se_sys_execve fs/exec.c:1956 [inline]
__x64_sys_execve+0x8f/0xc0 fs/exec.c:1956
do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x45a679
Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffbf4072c78 EFLAGS: 00000246 ORIG_RAX: 000000000000003b
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 000000000045a679
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000040
RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffbf40736d4
R13: 00000000004c0fcd R14: 00000000004d41f0 R15: 00000000ffffffff
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* Re: [PATCH 0/2] Revert patches fixing probing of interrupts
From: Jerry Snitselaar @ 2019-12-02 18:55 UTC (permalink / raw)
To: Stefan Berger
Cc: Jarkko Sakkinen, Stefan Berger, linux-integrity, linux-kernel,
stable, linux-security-module
In-Reply-To: <6f6f60a2-3b55-e76d-c11a-4677fcb72c16@linux.ibm.com>
On Sun Dec 01 19, Stefan Berger wrote:
>On 11/29/19 5:37 PM, Jarkko Sakkinen wrote:
>>On Tue, Nov 26, 2019 at 08:17:51AM -0500, Stefan Berger wrote:
>>>From: Stefan Berger <stefanb@linux.ibm.com>
>>>
>>>Revert the patches that were fixing the probing of interrupts due
>>>to reports of interrupt stroms on some systems
>>Can you explain how reverting is going to fix the issue?
>
>
>The reverts fix 'the interrupt storm issue' that they are causing on
>some systems but don't fix the issue with the interrupt mode not being
>used. I was hoping Jerry would get access to a system faster but this
>didn't seem to be the case. So sending these patches seemed the better
>solution than leaving 5.4.x with the problem but going back to when it
>worked 'better.'
>
I finally heard back from IT support, and unfortunately they don't
have any T490s systems to give out on temp loan. So I can only send
patched kernels to the end user that had the problem.
>
>>
>>This is wrong way to move forward. The root cause must be identified
>>first and then decide actions like always in any situation.
>>
>>/Jarkko
>
>
^ permalink raw reply
* Re: [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even, in confidentiality mode.
From: Matthew Garrett @ 2019-12-02 19:43 UTC (permalink / raw)
To: Matt Parnell; +Cc: LSM List, David Howells, matthew.garrett, Kees Cook
In-Reply-To: <339ca47a-6ed1-4ab4-f8cf-7b205fa9f773@gmail.com>
On Fri, Nov 29, 2019 at 10:50 PM Matt Parnell <mparnell@gmail.com> wrote:
> 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.
The msr interface is pretty terrible - it exposes a consistent
interface over very inconsistent CPUs. Where there's CPU functionality
that's implemented via MSRs it makes sense to expose that over a
separate kernel interface.
^ permalink raw reply
* Re: [GIT PULL] SELinux patches for v5.5
From: Paul Moore @ 2019-12-02 20:04 UTC (permalink / raw)
To: Mimi Zohar; +Cc: selinux, linux-security-module, Roberto Sassu, initramfs
In-Reply-To: <1575302310.4793.379.camel@linux.ibm.com>
On Mon, Dec 2, 2019 at 10:58 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> [Truncated Cc list, adding Roberto and the initramfs mailing list]
>
> Hi Paul,
>
> On Tue, 2019-11-26 at 16:24 -0500, Paul Moore wrote:
>
> > - Allow file labeling before the policy is loaded. This should ease
> > some of the burden when the policy is initially loaded (no need to
> > relabel files), but it should also help enable some new system
> > concepts which dynamically create the root filesystem in the initrd.
>
> Any chance you're planning on using Roberto's patches for including
> security xattrs in the initramfs?[1]
> [1] https://www.spinics.net/lists/linux-initramfs/msg04771.html
I'm assuming you're not asking about me personally? ;)
However, just in case, I'll probably wait until it is picked up by the
various distributions; somehow I haven't yet found the time to roll my
own distribution for personal use ;)
> Any help reviewing his patches
> would be much appreciated!
I would love to help, but given my current workload I'm not sure how
timely the review would be, I would suggest reaching out to the
distributions who maintain the userspace (and have asked for this
feature).
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even, in confidentiality mode.
From: Matt Parnell @ 2019-12-02 20:39 UTC (permalink / raw)
To: Matthew Garrett; +Cc: LSM List, David Howells, matthew.garrett, Kees Cook
In-Reply-To: <CACdnJus-CQPKgL8cW1TAH3u_SSWHBk608tJsx8Uc-dMDPHyRqg@mail.gmail.com>
Agreed.
That said, if we don't mind working with what already exists, this
whitelist addition (I have trouble calling it a module) exists. I wonder
if it could be reshaped into something that ties in with the lockdown
functionality?
It looks like a mixture of commits from Intel engineers and Lawrence
Livermore engineers (GPLv3) :
https://github.com/LLNL/msr-safe
On 12/2/19 1:43 PM, Matthew Garrett wrote:
> On Fri, Nov 29, 2019 at 10:50 PM Matt Parnell <mparnell@gmail.com> wrote:
>> 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.
> The msr interface is pretty terrible - it exposes a consistent
> interface over very inconsistent CPUs. Where there's CPU functionality
> that's implemented via MSRs it makes sense to expose that over a
> separate kernel interface.
^ permalink raw reply
* Re: [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even, in confidentiality mode.
From: Jordan Glover @ 2019-12-02 22:55 UTC (permalink / raw)
To: Matt Parnell
Cc: Kees Cook, linux-security-module@vger.kernel.org,
dhowells@redhat.com, matthew.garrett@nebula.com
In-Reply-To: <96625b06-3bba-6831-7127-22b690fccf1b@gmail.com>
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
^ permalink raw reply
* Re: [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even, in confidentiality mode.
From: Matt Parnell @ 2019-12-02 23:13 UTC (permalink / raw)
To: Jordan Glover
Cc: Kees Cook, linux-security-module@vger.kernel.org,
dhowells@redhat.com, matthew.garrett@nebula.com
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
^ permalink raw reply
* Re: [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even, in confidentiality mode.
From: Matthew Garrett @ 2019-12-02 23:29 UTC (permalink / raw)
To: Jordan Glover
Cc: Matt Parnell, Kees Cook, linux-security-module@vger.kernel.org,
dhowells@redhat.com, matthew.garrett@nebula.com
In-Reply-To: <-uRGQFmc8hMANlmvOpPXEib39VyGsx15MXwgVf-vripxhDcjILDfe5O17fyf5MXoZflmIE4avp7SqW4ijO1kHPqgHJMCqg1fWtXeGylu2uc=@protonmail.ch>
On Mon, Dec 2, 2019 at 2:55 PM Jordan Glover
<Golden_Miller83@protonmail.ch> wrote:
> 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.
The latter.
^ permalink raw reply
* Re: [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even, in confidentiality mode.
From: Matt Parnell @ 2019-12-02 23:31 UTC (permalink / raw)
To: Matthew Garrett, Jordan Glover
Cc: Kees Cook, linux-security-module@vger.kernel.org,
dhowells@redhat.com, matthew.garrett@nebula.com
In-Reply-To: <CACdnJutjZk4r_7oCZTnQdmKGZKay1KvvDA+7goj9fwkMVcfHmQ@mail.gmail.com>
I suppose that turning off the early lockdown functionality, and then
having apparmor or selinux grant intel-undervolt permission to the MSRs
is probably another method of going about this, only slightly less "tight."
On 12/2/19 5:29 PM, Matthew Garrett wrote:
> On Mon, Dec 2, 2019 at 2:55 PM Jordan Glover
> <Golden_Miller83@protonmail.ch> wrote:
>
>> 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.
> The latter.
^ permalink raw reply
* Re: tracefs splats in lockdown=confidentiality mode
From: Matthew Garrett @ 2019-12-02 23:31 UTC (permalink / raw)
To: dann frazier
Cc: Steven Rostedt, Linux Kernel Mailing List, LSM List, Seth Forshee,
James Morris, Linux API, Ben Hutchings, Al Viro, Linus Torvalds
In-Reply-To: <20191101210803.GA9841@xps13.dannf>
On Fri, Nov 1, 2019 at 2:08 PM dann frazier <dann.frazier@canonical.com> wrote:
> [ 1.763630] Lockdown: swapper/0: use of tracefs is restricted; see man kernel_lockdown.7
This is expected.
> [ 2.913934] ------------[ cut here ]------------
> [ 2.918435] Could not register function stat for cpu 0
> [ 2.923717] WARNING: CPU: 1 PID: 1 at kernel/trace/ftrace.c:987 ftrace_init_tracefs_toplevel+0x168/0x1bc
This is not. I'll look into it.
^ permalink raw reply
* Re: tracefs splats in lockdown=confidentiality mode
From: Steven Rostedt @ 2019-12-02 23:54 UTC (permalink / raw)
To: Matthew Garrett
Cc: dann frazier, Linux Kernel Mailing List, LSM List, Seth Forshee,
James Morris, Linux API, Ben Hutchings, Al Viro, Linus Torvalds
In-Reply-To: <CACdnJuuXBQ__Sb8=V7CTZfXH=5LfbiU9SmUKapJov3Cd+aHQcw@mail.gmail.com>
On Mon, 2 Dec 2019 15:31:52 -0800
Matthew Garrett <mjg59@google.com> wrote:
> On Fri, Nov 1, 2019 at 2:08 PM dann frazier <dann.frazier@canonical.com> wrote:
>
> > [ 1.763630] Lockdown: swapper/0: use of tracefs is restricted; see man kernel_lockdown.7
>
> This is expected.
>
> > [ 2.913934] ------------[ cut here ]------------
> > [ 2.918435] Could not register function stat for cpu 0
> > [ 2.923717] WARNING: CPU: 1 PID: 1 at kernel/trace/ftrace.c:987 ftrace_init_tracefs_toplevel+0x168/0x1bc
>
> This is not. I'll look into it.
I think it has to do with ftrace triggering WARN_ON() if it fails to
create files. We don't want this to happen if it fails because of
lockdown.
I'm already looking into it.
Thanks!
-- Steve
^ permalink raw reply
* Re: [GIT PULL] SELinux patches for v5.5
From: Mimi Zohar @ 2019-12-03 2:00 UTC (permalink / raw)
To: Paul Moore; +Cc: selinux, linux-security-module, Roberto Sassu, initramfs
In-Reply-To: <CAHC9VhRkosCVR+4qyf=GPKQuQoJzwjZZJ_z7rhE-qiL-TNbtPw@mail.gmail.com>
On Mon, 2019-12-02 at 15:04 -0500, Paul Moore wrote:
> On Mon, Dec 2, 2019 at 10:58 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > [Truncated Cc list, adding Roberto and the initramfs mailing list]
> >
> > Hi Paul,
> >
> > On Tue, 2019-11-26 at 16:24 -0500, Paul Moore wrote:
> >
> > > - Allow file labeling before the policy is loaded. This should ease
> > > some of the burden when the policy is initially loaded (no need to
> > > relabel files), but it should also help enable some new system
> > > concepts which dynamically create the root filesystem in the initrd.
> >
> > Any chance you're planning on using Roberto's patches for including
> > security xattrs in the initramfs?[1]
> > [1] https://www.spinics.net/lists/linux-initramfs/msg04771.html
>
> I'm assuming you're not asking about me personally? ;)
No, of course not. I was wondering if "help enable some new system
concepts which dynamically create the root filesystem in the initrd"
adds SELinux labels on the root filesystem.
Mimi
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox