lkml.org 
[lkml]   [2023]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux guest kernel threat model for Confidential Computing
    On Thu, Jan 26, 2023 at 11:25:21AM -0500, Michael S. Tsirkin wrote:
    > On Thu, Jan 26, 2023 at 04:44:49PM +0100, Lukas Wunner wrote:
    > > Obviously the host can DoS guest access to the device by modifying
    > > exchanged messages, but there are much simpler ways for it to
    > > do that, say, by clearing Bus Master Enable or Memory Space Enable
    > > bits in the Command Register.
    >
    > There's a single key per guest though, isn't it? Also used
    > for regular memory?

    The current design is to have a global keyring (per kernel, i.e. per
    guest). A device presents a certificate chain and the first certificate
    in that chain needs to be signed by one of the certificates on the keyring.

    This is completely independent from the key used for memory encryption.

    A device can have up to 8 certificate chains (called "slots" in the
    SPDM spec) and I've implemented it such that all slots are iterated
    and validation is considered to be successful as soon as a slot with
    a valid signature is found.

    We can discuss having a per-device keyring if anyone thinks it makes
    sense.

    The PCISIG's idea seems to be that each vendor of PCIe cards publishes
    a trusted root certificate and users would then have to keep all those
    vendor certificates in their global keyring. This follows from the
    last paragraph of PCIe r6.0.1 sec 6.31.3, which says "it is strongly
    recommended that authentication requesters [i.e. the kernel] confirm
    that the information provided in the Subject Alternative Name entry
    [of the device's leaf certificate] is signed by the vendor indicated
    by the Vendor ID."

    The astute reader will notice that for this to work, the Vendor ID
    must be included in the trusted root certificate in a machine-readable
    way. Unfortunately the PCIe Base Spec fails to specify that.
    So I don't know how to associate a trusted root certificate with a
    Vendor ID.

    I'll report this and several other gaps I've found in the spec to the
    editor at the PCISIG so that they can be filled in a future revision.

    Thanks,

    Lukas

    \
     
     \ /
      Last update: 2023-03-26 23:57    [W:5.261 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site