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 <lu...@wunner.de> > Sent: Monday, October 2, 2023 4:48 PM > To: Alistair Francis <alistai...@gmail.com> > Cc: wilfred.mall...@wdc.com; jonathan.came...@huawei.com; Yao, Jiewen > <jiewen....@intel.com>; qemu-devel@nongnu.org; kbu...@kernel.org; > i...@irrelevant.dk; m...@redhat.com; marcel.apfelb...@gmail.com; > hch...@avery-design.com.tw; Browy, Chris <cbr...@avery-design.com>; qemu- > bl...@nongnu.org; Alistair Francis <alistair.fran...@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
