RE: [PATCH v2 0/8] Decode IA32/X64 CPER

[Luck, Tony]

> One much more important thing I forgot about yesterday: how is
> this thing playing into our RAS reporting, x86 decoding chain, etc
> infrastructure?
>
> Is CPER bypassing it completely and the firmware is doing everything
> now? I sure hope not.

Intel gives OEMs lots of options to catch and tweak the error path in
BIOS SMM code.  So it is possible that some systems may go into
BIOS which would do platform level analysis and create a CPER to
feed to the OS. Hopefully anyone doing that would clear the machine
check bank and suppress CMCI to avoid double reporting the same
error.

> If not, it needs to tie into our infrastructure and the errors need
> to go into the decoding chain where different things look at them and
> filter them.

Good point.

> Tony, what are your plans here?

Nothing solid yet.

> Perhaps we can finally get MCE decoding on Intel too :-)

It's on a mental list ... I should probably add it to our internal
trackers so that we actually do it sooner rather than in some
distant future.

-Tony 
N�r��yb�X��ǧv�^�)޺{.n�+{�y^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

Re: linux-next: UEFI Secure boot lockdown patchset

[Stephen Rothwell]

Hi David,

On Thu, 01 Mar 2018 11:06:55 + David Howells  wrote:
>
> Can you pull the following branch into linux-next please?  It does three
> things:
> 
>  (1) It restricts various accesses userspace may make upon the kernel when the
>  kernel is locked down.
> 
>  (2) It engages the lockdown if UEFI Secure Boot mode is detected.
> 
>  (3) It passes the UEFI Secure Boot mode indication across kexec.
> 
> The restrictions include:
> 
>  - Enforcing the use of module signatures
>  - Enforcing the use of kexec image signatures
>  - Requring IMA to use secure boot rules
>  - Disabling:
>- The kexec_load() syscall
>- Use of /dev/{mem,kmem,port,kcore}
>- Hibernation
>- PCI BAR access
>- Direct I/O port access
>  - Preventing direct port specification in drivers:
>- SCSI EATA
>- TIOCSSERIAL
>- Module parameters
>  - Restricting:
>- MSR access
>- Certain ACPI features
>- kprobes
>- BPF
>- Perf
>- Debugfs
> 
> The aim of the restrictions is twofold:
> 
>   (1) Prevent userspace from altering the kernel image directly (eg. by
>   /dev/mem) or indirectly (eg. by manipulating a device to do DMA);
> 
>   (2) Prevent userspace from accessing crypto data stored in the kernel
>   (eg. filesystem keys).
> 
> A warning is logged if a restriction is triggered for which I've written a
> manpage that is referenced in the message (see attached).

Added from tomorrow.  I actually used this url:

  
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git#efi-lock-down

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgement of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
 * submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
 * posted to the relevant mailing list,
 * reviewed by you (or another maintainer of your subsystem tree),
 * successfully unit tested, and 
 * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
s...@canb.auug.org.au


pgpu75CunMh3J.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 0/8] Decode IA32/X64 CPER

[Borislav Petkov]

On Wed, Feb 28, 2018 at 08:58:15PM +, Ghannam, Yazen wrote:
> 1) We keep this set mostly as-is. This would be our fallback if we don't have
> anything better.

Yes, sounds good. We try to decode it as MCE and if we cannot, we dump
the raw CPER record.

> 2) I add the MCA decoding to this set. I was thinking to do this in a separate
> set but maybe it's better to do it all together.

I'm fine if you do it separately, as long as you do it so that we have
user-friendly decoding in the end.

> Number 2 would mean we do a quick check on the CPER to see if it contains
> MCA info. There's no spec-defined way to do this, but we can make a good
> guess by seeing if we have an "MSR register" context and that context has
> an "MSR address" that is an MCA register.

Yap.

> If we think we have MCA info, then we pull as much out of the CPER as we
> can and put it in a struct mce which we then pass to the notifier chain.
> 
> If we don't think we have MCA info, then we fallback to number 1.

Ack.

> At the moment, it seems we'll be using x86 CPER to represent MCA errors
> in BERT since there's no other option in BERT. So I think having number 2
> would catch most, if not all, errors reported with x86 CPER.

Yeah, if you think about it, CPER is a clumsy and totally useless
indirection layer between MCA and the OS. And if the error is of
different type (AER, PCI, whatever), then it wraps around it too with
some dumb table. And that doesn't bring anything - just the need for
more support added to the OS and tools around it. Basically what you're
doing now.

I don't mind the aspect of firmware seeing the errors first and even
attempting to fix them as the firmware knows the platform intimately but
doing everything in firmware just because some misguided souls think
this gives added value but in reality ends up becoming a worse problem,
is simply the wrong wrong thing to do.

Thx.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: UEFI Secure boot lockdown patchset

[David Howells]

I forgot to include the branch URL:


https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lock-down

Thanks for spotting that, Ard!

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: UEFI Secure boot lockdown patchset

[Ard Biesheuvel]

Hi David,

On 1 March 2018 at 11:06, David Howells  wrote:
>
> Hi Stephen,
>
> Can you pull the following branch into linux-next please?

Could you please include a URL?

>  It does three
> things:
>
>  (1) It restricts various accesses userspace may make upon the kernel when the
>  kernel is locked down.
>
>  (2) It engages the lockdown if UEFI Secure Boot mode is detected.
>
>  (3) It passes the UEFI Secure Boot mode indication across kexec.
>
> The restrictions include:
>
>  - Enforcing the use of module signatures
>  - Enforcing the use of kexec image signatures
>  - Requring IMA to use secure boot rules
>  - Disabling:
>- The kexec_load() syscall
>- Use of /dev/{mem,kmem,port,kcore}
>- Hibernation
>- PCI BAR access
>- Direct I/O port access
>  - Preventing direct port specification in drivers:
>- SCSI EATA
>- TIOCSSERIAL
>- Module parameters
>  - Restricting:
>- MSR access
>- Certain ACPI features
>- kprobes
>- BPF
>- Perf
>- Debugfs
>
> The aim of the restrictions is twofold:
>
>   (1) Prevent userspace from altering the kernel image directly (eg. by
>   /dev/mem) or indirectly (eg. by manipulating a device to do DMA);
>
>   (2) Prevent userspace from accessing crypto data stored in the kernel
>   (eg. filesystem keys).
>
> A warning is logged if a restriction is triggered for which I've written a
> manpage that is referenced in the message (see attached).
>
> David
>
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

linux-next: UEFI Secure boot lockdown patchset

[David Howells]

Hi Stephen,

Can you pull the following branch into linux-next please?  It does three
things:

 (1) It restricts various accesses userspace may make upon the kernel when the
 kernel is locked down.

 (2) It engages the lockdown if UEFI Secure Boot mode is detected.

 (3) It passes the UEFI Secure Boot mode indication across kexec.

The restrictions include:

 - Enforcing the use of module signatures
 - Enforcing the use of kexec image signatures
 - Requring IMA to use secure boot rules
 - Disabling:
   - The kexec_load() syscall
   - Use of /dev/{mem,kmem,port,kcore}
   - Hibernation
   - PCI BAR access
   - Direct I/O port access
 - Preventing direct port specification in drivers:
   - SCSI EATA
   - TIOCSSERIAL
   - Module parameters
 - Restricting:
   - MSR access
   - Certain ACPI features
   - kprobes
   - BPF
   - Perf
   - Debugfs

The aim of the restrictions is twofold:

  (1) Prevent userspace from altering the kernel image directly (eg. by
  /dev/mem) or indirectly (eg. by manipulating a device to do DMA);

  (2) Prevent userspace from accessing crypto data stored in the kernel
  (eg. filesystem keys).

A warning is logged if a restriction is triggered for which I've written a
manpage that is referenced in the message (see attached).

David

.\"
.\" Copyright (C) 2017 Red Hat, Inc. All Rights Reserved.
.\" Written by David Howells (dhowe...@redhat.com)
.\"
.\" %%%LICENSE_START(GPLv2+_SW_ONEPARA)
.\" This program is free software; you can redistribute it and/or
.\" modify it under the terms of the GNU General Public License
.\" as published by the Free Software Foundation; either version
.\" 2 of the License, or (at your option) any later version.
.\" %%%LICENSE_END
.\"
.TH "KERNEL LOCKDOWN" 7 2017-10-05 Linux "Linux Programmer's Manual"
.SH NAME
Kernel Lockdown \- Kernel image access prevention feature
.SH DESCRIPTION
The Kernel Lockdown feature is designed to prevent both direct and indirect
access to a running kernel image, attempting to protect against unauthorised
modification of the kernel image and to prevent access to security and
cryptographic data located in kernel memory, whilst still permitting driver
modules to be loaded.
.P
Lockdown is typically enabled during boot and may be terminated, if configured,
by typing a special key combination on a directly attached physical keyboard.
.P
If a prohibited or restricted feature is accessed or used, the kernel will emit
a message that looks like:
.P
.RS
	Lockdown: X: Y is restricted, see man kernel_lockdown.7
.RE
.P
where X indicates the process name and Y indicates what is restricted.
.P
On an EFI-enabled x86 or arm64 machine, lockdown will be automatically enabled
if the system boots in EFI Secure Boot mode.
.P
If the kernel is appropriately configured, lockdown may be lifted by typing the
appropriate sequence on a directly attached physical keyboard.  For x86
machines, this is
.IR SysRq+x .
.\"
.SH COVERAGE
When lockdown is in effect, a number of features are disabled or have their use
restricted.  This includes special device files and kernel services that allow
direct access of the kernel image:
.P
.RS
/dev/mem
.br
/dev/kmem
.br
/dev/kcore
.br
/dev/ioports
.br
BPF
.br
kprobes
.RE
.P
and the ability to directly configure and control devices, so as to prevent the
use of a device to access or modify a kernel image:
.P
.RS
The use of module parameters that directly specify hardware parameters to
drivers through the kernel command line or when loading a module.
.P
The use of direct PCI BAR access.
.P
The use of the ioperm and iopl instructions on x86.
.P
The use of the KD*IO console ioctls.
.P
The use of the TIOCSSERIAL serial ioctl.
.P
The alteration of MSR registers on x86.
.P
The replacement of the PCMCIA CIS.
.P
The overriding of ACPI tables.
.P
The use of ACPI error injection.
.P
The specification of the ACPI RDSP address.
.P
The use of ACPI custom methods.
.RE
.P
Certain facilities are restricted:
.P
.RS
Only validly signed modules may be loaded (waived if the module file being
loaded is vouched for by IMA appraisal).
.P
Only validly signed binaries may be kexec'd (waived if the binary image file to
be executed is vouched for by IMA appraisal).
.P
Unencrypted hibernation/suspend to swap are disallowed as the kernel image is
saved to a medium that can then be accessed.
.P
Use of debugfs is not permitted as this allows a whole range of actions
including direct configuration of, access to and driving of hardware.
.P
IMA requires the addition of the "secure_boot" rules to the policy, whether or
not they are specified on the command line, for both the builtin and custom
policies in secure boot lockdown mode.
.RE