linux-cxl.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ira Weiny <ira.weiny@intel.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: "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>,
	"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: Re: (SPDM) Device attestation, secure channels from host to device etc: Discuss at Plumbers?
Date: Thu, 9 Jun 2022 07:22:01 -0700	[thread overview]
Message-ID: <YqICCSd/6Vxidu+v@iweiny-desk3> (raw)
In-Reply-To: <20220609124702.000037b0@Huawei.com>

On Thu, Jun 09, 2022 at 12:47:02PM +0100, Jonathan Cameron wrote:
> 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?

Yes, while this could work as part of the CXL uconf it is probably a more
general topic.

> 
> 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!)

I think this is something which really does need some face to face (or virtual
face) time.  FWIW another idea from Christoph is kernel bundled userspace code.

	https://lore.kernel.org/linux-cxl/YoT4C77Yem37NUUR@infradead.org/

I'm not sure any real implementation would be workable.

> * 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?

I have submitted a non-CXL topic in the arch uconf and was hoping to go in
person but I'm unsure of travel budgets.  I will likely be virtual if I can't
attend in person.

Ira

  reply	other threads:[~2022-06-09 14:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-09 11:47 (SPDM) Device attestation, secure channels from host to device etc: Discuss at Plumbers? Jonathan Cameron
2022-06-09 14:22 ` Ira Weiny [this message]
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=YqICCSd/6Vxidu+v@iweiny-desk3 \
    --to=ira.weiny@intel.com \
    --cc=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=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).