Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: Ira Weiny <ira.weiny@intel.com>,
	"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>,
	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: Wed, 22 Jun 2022 12:46:38 +0100	[thread overview]
Message-ID: <20220622124638.00004456@Huawei.com> (raw)
In-Reply-To: <20220620165217.GA18451@wunner.de>

On Mon, 20 Jun 2022 18:52:17 +0200
Lukas Wunner <lukas@wunner.de> wrote:

> On Fri, Jun 17, 2022 at 11:21:24AM +0100, Jonathan Cameron wrote:
> > On Thu, 9 Jun 2022 07:22:01 -0700 Ira Weiny <ira.weiny@intel.com> wrote:  
> > > On Thu, Jun 09, 2022 at 12:47:02PM +0100, Jonathan Cameron wrote:  
> > > > 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.  
> 
> So the SDPM series you posted in March is the latest version?

Hi Lukas,

Yes and the March version is (more or less) a rebase of the proposal
used to drive the conversation at Plumbers PCI uconf last year.
I have some prototype measurement code but probably not a lot of
point in doing anything with that until the basic stuff is in place.

> 
> If you lack bandwidth to carry on with it, I would pick up the baton
> and rework that version based on the review feedback I've posted.
> (Unless someone else is eager to do that.)

I'm always keen to leverage offers of help - I want the end result
and am more than happy if someone else drives it forwards. There is
plenty to keep lots of people busy in this space.

It wasn't so much bandwidth that was restricting my work on this, but
more precursors and open questions. Also 

* DOE is undergoing another rewrite after recent review of v11 from Dan.
* At the moment the in kernel solution is 'competing' with a proposal
  to do stuff in userspace that is currently words only and tied up
  with the somewhat similar stuff for TLS sessions setup.
  I see there is continuing work on inband NVME authentication posted.

Personally I diverted into putting as second transport in place so that
we are sure that layering is correct (MCTP) - however the way MCTP is
handled by the kernel is not that friendly to in kernel use - it might
be doable but there is a userspace part in that path (to configure the
mctp routing etc).

From point of view of the RFC, if you want to take that forwards that
would be fine by me.  Beyond responding to review feedback there are
some missing features we would need.

1) Slot handling - right now it only uses the first slot.
2) SPDM 1.2 support (maybe just move 1.2)
3) Actually doing something useful beyond basic attestation.

For those, perhaps just shout if you are taking one on so that we don't
duplicate and I'll do the same if I get to one of them.

I have a side project to get SPDM over MCTP running as well to see
what that story looks like.  We may want to share infrastructure, but
it won't typically run on the same system so there is probably no
requirement to do so.

> 
> 
> > > Yes, while this could work as part of the CXL uconf it is probably a more
> > > general topic.  
> > 
> > Maybe steal time from PCI given CXL uconf is going to be busy!
> > (lets see if any of the PCI folk are reading this thread.. :)
> > 
> > At the moment I'm not seeing enough interest to put in a proposal for
> > anything 'officially scheduled', but there is a bit more time until
> > the deadline so let's see if we get any other interest in that time.  
> 
> How about a BoF session to discuss the status quo and any open issues?

Ok. I'm not yet clear we have critical mass but I'll put an application
in the system. Can always pull it before the deadline if it looks like
we don't have enough interest to take up a slot.  We can schedule
something at another time if it doesn't work out, but Plumbers hopefully
has a critical mass of right people present to make rapid progress if
we can get some people in a room (with others online).


> 
> (I'm not involved with CXL, hence probably belong to "PCI folk".)

:)

> 
> 
> > > I [...] 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.  
> 
> Same.

Hopefully see you there, space and travel budgets willing.

Jonathan


  reply	other threads:[~2022-06-22 11:46 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
2022-06-17 10:21   ` Jonathan Cameron
2022-06-20 16:52     ` Lukas Wunner
2022-06-22 11:46       ` Jonathan Cameron [this message]
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=20220622124638.00004456@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