> 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 twe
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 lockd
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
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.o
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 l
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 Sec
