From: Jason Gunthorpe <jgg@nvidia.com>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>,
Kees Cook <kees@kernel.org>, Lukas Wunner <lukas@wunner.de>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Bjorn Helgaas <helgaas@kernel.org>,
David Howells <dhowells@redhat.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
David Woodhouse <dwmw2@infradead.org>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
linux-pci@vger.kernel.org, linux-cxl@vger.kernel.org,
linux-coco@lists.linux.dev, keyrings@vger.kernel.org,
linux-crypto@vger.kernel.org, linuxarm@huawei.com,
David Box <david.e.box@intel.com>,
"Li, Ming" <ming4.li@intel.com>,
Ilpo Jarvinen <ilpo.jarvinen@linux.intel.com>,
Alistair Francis <alistair.francis@wdc.com>,
Wilfred Mallawa <wilfred.mallawa@wdc.com>,
Alexey Kardashevskiy <aik@amd.com>,
Dhaval Giani <dhaval.giani@amd.com>,
Gobikrishna Dhanuskodi <gdhanuskodi@nvidia.com>,
Peter Gonda <pgonda@google.com>,
Jerome Glisse <jglisse@google.com>,
Sean Christopherson <seanjc@google.com>,
Alexander Graf <graf@amazon.com>,
Samuel Ortiz <sameo@rivosinc.com>, Jann Horn <jannh@google.com>
Subject: Re: [PATCH v2 08/18] PCI/CMA: Authenticate devices on enumeration
Date: Mon, 15 Jul 2024 21:11:42 -0300 [thread overview]
Message-ID: <20240716001142.GB1482543@nvidia.com> (raw)
In-Reply-To: <5f7fca8b-ab74-4fba-8df8-152ad6f94227@kernel.org>
On Tue, Jul 16, 2024 at 08:57:14AM +0900, Damien Le Moal wrote:
> Initially, we can certainly treat them like that. But eventually, we
> may need something more as CC VMs access to storage has to be
> trusted too and so will require both HBA and the device to be
> trusted. For the TDISP handling, I am however not sure how that
> should looks like (is it the HBA or the storage device secrets that
> are used, both ?). As I said, I have not spent any time yet thinking
> about that use case.
My guess for CC VM's is you do both.
From a big picture a CC TVM is going to want encrypted storage,
otherwise it doesn't really make any sense.
If the TVM does the encryption with the CPU then we don't really need to
attest the storage or PCI at all, bounce the encrypted data into
untrusted memory and then CPU copy it while crypting it. This
minimizes the amount of stuff you have to trust.
If the TVM would like to have the storage device do the encryption
with something like OPAL then:
- Attest and trust the PCI function, this lets you load the HBA driver
- Attest and trust the "media"
- Use the media attestation to load an encrypted copy of the media
key from the secure keyserver into the drive
The split view of "media" and PCI function seems appropriate. The
keyserver should only release keys to media that has the correct
attested ID, while a controller may have many different media attached
to it.
Attesting the controller is probably not enough to release the keys?
Jason
next prev parent reply other threads:[~2024-07-16 0:11 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-30 19:35 [PATCH v2 00/18] PCI device authentication Lukas Wunner
2024-06-30 19:36 ` [PATCH v2 01/18] X.509: Make certificate parser public Lukas Wunner
2024-07-10 2:46 ` Alistair Francis
2024-06-30 19:37 ` [PATCH v2 02/18] X.509: Parse Subject Alternative Name in certificates Lukas Wunner
2024-07-10 2:48 ` Alistair Francis
2024-06-30 19:38 ` [PATCH v2 03/18] X.509: Move certificate length retrieval into new helper Lukas Wunner
2024-07-10 2:49 ` Alistair Francis
2024-07-18 11:04 ` Jonathan Cameron
2024-06-30 19:39 ` [PATCH v2 04/18] certs: Create blacklist keyring earlier Lukas Wunner
2024-07-10 2:52 ` Alistair Francis
2024-06-30 19:40 ` [PATCH v2 05/18] crypto: akcipher - Support more than one signature encoding Lukas Wunner
2024-06-30 19:41 ` [PATCH v2 06/18] crypto: ecdsa - Support P1363 " Lukas Wunner
2024-06-30 22:10 ` Herbert Xu
2024-07-29 14:27 ` Lukas Wunner
2024-06-30 19:42 ` [PATCH v2 07/18] spdm: Introduce library to authenticate devices Lukas Wunner
2024-06-30 21:29 ` Jeff Johnson
2024-07-08 9:57 ` Alexey Kardashevskiy
2024-07-08 12:54 ` Lukas Wunner
2024-07-09 0:45 ` Alexey Kardashevskiy
2024-07-09 8:49 ` Lukas Wunner
2024-07-09 5:09 ` Dan Williams
2024-07-18 11:42 ` Jonathan Cameron
2024-07-09 15:00 ` Jeff Johnson
2024-07-18 14:24 ` Jonathan Cameron
2024-06-30 19:43 ` [PATCH v2 08/18] PCI/CMA: Authenticate devices on enumeration Lukas Wunner
2024-07-09 18:10 ` Dan Williams
2024-07-09 19:32 ` Lukas Wunner
2024-07-09 23:31 ` Dan Williams
2024-07-11 15:00 ` Lukas Wunner
2024-07-11 17:50 ` Dan Williams
2024-07-12 0:50 ` Damien Le Moal
2024-07-14 8:42 ` Lukas Wunner
2024-07-15 17:21 ` Kees Cook
2024-07-15 18:12 ` Jason Gunthorpe
2024-07-15 20:36 ` Dan Williams
2024-07-15 22:02 ` Jason Gunthorpe
2024-07-15 22:17 ` Damien Le Moal
2024-07-15 23:03 ` Jason Gunthorpe
2024-07-15 23:26 ` Damien Le Moal
2024-07-15 23:42 ` Jason Gunthorpe
2024-07-15 23:57 ` Damien Le Moal
2024-07-16 0:11 ` Jason Gunthorpe [this message]
2024-07-16 1:23 ` Dan Williams
2024-07-15 22:50 ` Dan Williams
2024-07-15 23:21 ` Jason Gunthorpe
2024-07-15 23:37 ` Dan Williams
2024-07-15 23:55 ` Jason Gunthorpe
2024-07-16 1:35 ` Dan Williams
2024-07-22 10:19 ` Alexey Kardashevskiy
2024-07-22 12:06 ` Jason Gunthorpe
2024-07-23 4:26 ` Alexey Kardashevskiy
2024-07-23 12:58 ` Jason Gunthorpe
2024-07-15 20:19 ` Dan Williams
2024-07-15 20:08 ` Dan Williams
2024-06-30 19:44 ` [PATCH v2 09/18] PCI/CMA: Validate Subject Alternative Name in certificates Lukas Wunner
2024-07-10 20:35 ` Dan Williams
2024-06-30 19:45 ` [PATCH v2 10/18] PCI/CMA: Reauthenticate devices on reset and resume Lukas Wunner
2024-07-10 3:40 ` Alistair Francis
2024-07-10 23:23 ` Dan Williams
2024-07-18 15:01 ` Jonathan Cameron
2024-06-30 19:46 ` [PATCH v2 11/18] PCI/CMA: Expose in sysfs whether devices are authenticated Lukas Wunner
2024-07-17 23:17 ` Dan Williams
2024-07-18 15:11 ` Jonathan Cameron
2024-06-30 19:47 ` [PATCH v2 12/18] PCI/CMA: Expose certificates in sysfs Lukas Wunner
2024-07-18 2:43 ` Dan Williams
2024-07-18 15:16 ` Jonathan Cameron
2024-07-18 15:19 ` Jonathan Cameron
2024-06-30 19:48 ` [PATCH v2 13/18] sysfs: Allow bin_attributes to be added to groups Lukas Wunner
2024-07-04 10:13 ` Greg Kroah-Hartman
2024-07-12 3:49 ` Alistair Francis
2024-07-18 15:22 ` Jonathan Cameron
2024-06-30 19:49 ` [PATCH v2 14/18] sysfs: Allow symlinks to be added between sibling groups Lukas Wunner
2024-07-04 10:14 ` Greg Kroah-Hartman
2024-07-18 15:36 ` Jonathan Cameron
2024-06-30 19:50 ` [PATCH v2 15/18] PCI/CMA: Expose a log of received signatures in sysfs Lukas Wunner
2024-07-18 15:56 ` Jonathan Cameron
2024-06-30 19:51 ` [PATCH v2 16/18] spdm: Limit memory consumed by log of received signatures Lukas Wunner
2024-07-18 16:03 ` Jonathan Cameron
2024-06-30 19:52 ` [PATCH v2 17/18] spdm: Authenticate devices despite invalid certificate chain Lukas Wunner
2024-07-18 16:08 ` Jonathan Cameron
2024-06-30 19:53 ` [PATCH v2 18/18] spdm: Allow control of next requester nonce through sysfs Lukas Wunner
2024-07-18 16:11 ` Jonathan Cameron
2024-07-08 9:47 ` [PATCH v2 00/18] PCI device authentication Alexey Kardashevskiy
2024-07-08 13:35 ` Lukas Wunner
2025-02-11 1:30 ` Alexey Kardashevskiy
2025-02-12 16:36 ` Lukas Wunner
2025-05-20 8:35 ` Alexey Kardashevskiy
2025-05-29 5:29 ` Alexey Kardashevskiy
2025-05-29 9:40 ` Lukas Wunner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240716001142.GB1482543@nvidia.com \
--to=jgg@nvidia.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=aik@amd.com \
--cc=alistair.francis@wdc.com \
--cc=dan.j.williams@intel.com \
--cc=davem@davemloft.net \
--cc=david.e.box@intel.com \
--cc=dhaval.giani@amd.com \
--cc=dhowells@redhat.com \
--cc=dlemoal@kernel.org \
--cc=dwmw2@infradead.org \
--cc=gdhanuskodi@nvidia.com \
--cc=graf@amazon.com \
--cc=helgaas@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jannh@google.com \
--cc=jglisse@google.com \
--cc=kees@kernel.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=lukas@wunner.de \
--cc=ming4.li@intel.com \
--cc=pgonda@google.com \
--cc=sameo@rivosinc.com \
--cc=seanjc@google.com \
--cc=wilfred.mallawa@wdc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).