lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 26 Nov 2020 11:12:03 +0100
From:   Borislav Petkov <>
To:     Sean Christopherson <>,
        Andy Lutomirski <>
Cc:, Thomas Gleixner <>,
        Ingo Molnar <>,
        "H . Peter Anvin" <>,
        Paolo Bonzini <>,
        Vitaly Kuznetsov <>,
        Wanpeng Li <>,
        Jim Mattson <>,
        Joerg Roedel <>,,,,, Zhang Chen <>,
        Kai Huang <>,
        Sean Christopherson <>
Subject: Re: [RFC PATCH 03/67] x86/cpu: Move get_builtin_firmware() common
 code (from microcode only)

On Thu, Nov 26, 2020 at 12:18:12AM +0000, Sean Christopherson wrote:
> The SEAM module needs to be loaded during early boot, it can't be
> deferred to a module, at least not without a lot more blood, sweat,
> and tears.

Are you also planning to support builtin seam or only thru initrd loading?

In any case, this commit message needs to state intentions not me having
to plow all the way up to patch 62.

> The SEAM Loader is an ACM that is invoked via GETSEC[EnterACCS], which
> requires all APs to be in WFS.

Yah, this is the other thing that sprang at me from looking at that
"small" patchset briefly - I'm being killed by abbreviations. Whoever is
sending the next version, pls put a proper documentation as patch 1 of
the patchset just like the CET patchset does.

> SEAM Loader also returns control to the kernel with a null IDT and
> NMIs unblocked, i.e. we're toast if there's a pending NMI. And unlike
> the run-time SEAMCALLs, boot-time SEAMCALLs do not have a strictly
> bounded runtime. Invoking configuration SEAMCALLs after the kernel is
> fully up and running could cause instability as IRQ, NMI, and SMI are
> all blocked in SEAM mode, e.g. a high priority IRQ/NMI/SMI could be
> blocked for 50+ usecs (it might be far more than 50 usecs, I haven't
> seen real numbers for all SEAMCALLs).

Yah, I sure hope people have taken an ample amount of time to think
about all the implications of this thing because it sounds wonky to me.
amluto certainly has already gone deeper and will surely comment. :)



Powered by blists - more mailing lists