linux-cxl.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "dan.j.williams@intel.com" <dan.j.williams@intel.com>,
	"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
	<linux-pci@vger.kernel.org>, Lukas Wunner <lukas@wunner.de>,
	"Christoph Hellwig" <hch@infradead.org>, <ira.weiny@intel.com>
Cc: "Adam Manzanares" <a.manzanares@samsung.com>,
	"ben@bwidawsk.net" <ben@bwidawsk.net>,
	linuxarm@huawei.com, lorenzo.pieralisi@arm.com, "Box,
	David E" <david.e.box@intel.com>,
	"Chuck Lever" <chuck.lever@oracle.com>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>
Subject: (SPDM) Device attestation, secure channels from host to device etc: Discuss at Plumbers?
Date: Thu, 9 Jun 2022 12:47:02 +0100	[thread overview]
Message-ID: <20220609124702.000037b0@Huawei.com> (raw)

Hi All,

+CC list almost certainly misses people interested in this topic
    so please forward as appropriate.

I'll start by saying I haven't moved forward much with the
SPDM/CMA over Data Object Exchange proposal from the PoC that led to
presenting it last year as part of the PCI etc uconf last year.
https://lpc.events/event/11/contributions/1089/
https://lore.kernel.org/all/20220303135905.10420-1-Jonathan.Cameron@huawei.com/
I'm continuing to carry the QEMU emulation but not posted for a while
as we are slowly working through a backlog of CXL stuff to merge.
https://gitlab.com/jic23/qemu/-/commit/f989c8cf283302c70eb5b0b73625b5357c4eb44f
On the plus side, Ira is driving the DOE support forwards so
that will resolve one missing precursor.

We had a lot of open questions last year and many of them are
still at least somewhat open; perhaps now is time to revisit?

In the meantime there has been discussion[1]:
[1] https://lore.kernel.org/all/CAPcyv4jb7D5AKZsxGE5X0jon5suob5feggotdCZWrO_XNaer3A@mail.gmail.com/
[2] https://lore.kernel.org/all/20220511191345.GA26623@wunner.de/
[3] https://lore.kernel.org/all/CAPcyv4iWGb7baQSsjjLJFuT1E11X8cHYdZoGXsNd+B9GHtsxLw@mail.gmail.com/

Perhaps it is worth putting in a proposal for either a session in an
appropriate uconf at plumbers, or maybe a BoF given it is a
broader topic than either PCI or CXL?

We'll still need to dance around work in various standards bodies
that we can't talk about yet, but it feels like it's worth
some time hammering out a plan of attack on what we can
discuss.

Rough topics:

* Use models. Without those hard to define the rest!
* Policy.  What do we do if we can't establish a secure channel?
* Transports of interest.  Single solution for MCTP vs
  PCI/CMA or not?
* Session setup etc in kernel / userspace / carefully curated hybrid
  of the two (Dan mentioned this last one in one of the links above)
  There may be similarities to the discussion around TLS (much simpler
  though I think!)
* Key management
* Potential to use github.com/dmtf/libSPDM - is it suitable for any solutions
  (it's handy for emulation if nothing else!)
* Measurement and what to do with it.
* No public hardware yet, so what else should we emulate to enable
  work in this area. (SPDM over MCTP over I2C is on my list as easy
  to do in QEMU building on
  https://lore.kernel.org/all/20220520170128.4436-1-Jonathan.Cameron@huawei.com/ 
* Many other things I've forgotten about - please add!

So are people who care going to be at plumbers (in person or virtually)
and if so, do we want to put forward a session proposal?

Thanks,

Jonathan

             reply	other threads:[~2022-06-09 11:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-09 11:47 Jonathan Cameron [this message]
2022-06-09 14:22 ` (SPDM) Device attestation, secure channels from host to device etc: Discuss at Plumbers? Ira Weiny
2022-06-17 10:21   ` Jonathan Cameron
2022-06-20 16:52     ` Lukas Wunner
2022-06-22 11:46       ` Jonathan Cameron
2022-06-24 11:08         ` Jonathan Cameron
2022-06-24 14:15           ` Lukas Wunner
2022-06-24 14:32             ` Jonathan Cameron
2022-06-29 16:01               ` Adam Manzanares
2022-09-06 11:59                 ` Jonathan Cameron

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=20220609124702.000037b0@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=a.manzanares@samsung.com \
    --cc=ben@bwidawsk.net \
    --cc=bhelgaas@google.com \
    --cc=chuck.lever@oracle.com \
    --cc=dan.j.williams@intel.com \
    --cc=david.e.box@intel.com \
    --cc=hch@infradead.org \
    --cc=ira.weiny@intel.com \
    --cc=kw@linux.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=lukas@wunner.de \
    /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).