qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH 3/3] hw/nvme: Add SPDM over DOE support


From: Yao, Jiewen
Subject: RE: [PATCH 3/3] hw/nvme: Add SPDM over DOE support
Date: Mon, 2 Oct 2023 11:36:25 +0000

Comment on subjectAltName.

PCI-SIG realized that it may cause problem for certain device and decided to 
remove such requirement in future ECN.
I don't think that is absolutely needed.



> -----Original Message-----
> From: Lukas Wunner <lukas@wunner.de>
> Sent: Monday, October 2, 2023 4:48 PM
> To: Alistair Francis <alistair23@gmail.com>
> Cc: wilfred.mallawa@wdc.com; Jonathan.Cameron@Huawei.com; Yao, Jiewen
> <jiewen.yao@intel.com>; qemu-devel@nongnu.org; kbusch@kernel.org;
> its@irrelevant.dk; mst@redhat.com; marcel.apfelbaum@gmail.com;
> hchkuo@avery-design.com.tw; Browy, Chris <cbrowy@avery-design.com>; qemu-
> block@nongnu.org; Alistair Francis <alistair.francis@wdc.com>
> Subject: Re: [PATCH 3/3] hw/nvme: Add SPDM over DOE support
> 
> On Fri, Sep 15, 2023 at 09:27:23PM +1000, Alistair Francis wrote:
> > --- /dev/null
> > +++ b/docs/specs/spdm.rst
> > @@ -0,0 +1,56 @@
> > +======================================================
> > +QEMU Security Protocols and Data Models (SPDM) Support
> > +======================================================
> > +
> > +SPDM enables authentication, attestation and key exchange to assist in
> > +providing infrastructure security enablement. It's a standard published
> > +by the DMTF https://www.dmtf.org/standards/SPDM.
> > +
> > +Setting up a SPDM server
> [...]
> > +    $ cd spdm-emu
> > +    $ git submodule init; git submodule update --recursive
> > +    $ mkdir build; cd build
> > +    $ cmake -DARCH=x64 -DTOOLCHAIN=GCC -DTARGET=Debug -
> DCRYPTO=openssl ..
> > +    $ make -j32
> > +    $ make copy_sample_key # Build certificates, required for SPDM
> authentication.
> 
> Might be worth pointing out that certificates need to have a
> Subject Alternative Name in compliance with PCIe r6.1 sec 6.31.3,
> what to add to openssl.cnf to get one, e.g. ...
> 
>     subjectAltName =
> otherName:2.23.147;UTF8:Vendor=1b36:Device=0010:CC=010802:REV=02:SSVI
> D=1af4:SSID=1100
>     2.23.147 = ASN1:OID:2.23.147
> 
> ... and how to regenerate certificates after modifying openssl.cnf, e.g. ...
> 
>     $ openssl req -nodes -newkey ec:param.pem -keyout end_responder.key -out
> end_responder.req -sha384 -batch -subj "/CN=DMTF libspdm ECP384 responder
> cert"
>     $ openssl x509 -req -in end_responder.req -out end_responder.cert -CA
> inter.cert -CAkey inter.key -sha384 -days 3650 -set_serial 3 -extensions 
> v3_end -
> extfile ../openssl.cnf
>     $ openssl asn1parse -in end_responder.cert -out end_responder.cert.der
>     $ cat ca.cert.der inter.cert.der end_responder.cert.der >
> bundle_responder.certchain.der
> 
> Or preferably modify upstream libspdm to automate this process,
> make it less cumbersome and error-prone.
> 
> 
> > +static bool pcie_doe_spdm_rsp(DOECap *doe_cap)
> > +{
> > +    void *req = pcie_doe_get_write_mbox_ptr(doe_cap);
> > +    uint32_t req_len = pcie_doe_get_obj_len(req) * 4;
> > +    void *rsp = doe_cap->read_mbox;
> > +    uint32_t rsp_len = SPDM_SOCKET_MAX_MESSAGE_BUFFER_SIZE;
> > +    uint32_t recvd;
> 
> Might be worth mentioning somewhere that this only implements the
> responder role.
> 
> CPUs are coming to market which contain a Trusted Security Module.
> Some of those TSMs are capable of the SPDM requester role.  Should
> qemu ever have the need to emulate a CPU containing a TSM, it may
> become necessary to add SPDM requester support.
> 
> Thanks,
> 
> Lukas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]