Re: (SPDM) Device attestation, secure channels from host to device etc: Discuss at Plumbers?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 22 Jun 2022 12:46:38 +0100
Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote:

> On Mon, 20 Jun 2022 18:52:17 +0200
> Lukas Wunner <lukas@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxx/
> > > > > 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've put this in for now:

"
Device attestation, secure channel setup / SPDM - how to make progress?

In 2021, at the Plumbers VFIO/IOMMU/PCI micro-conference, we introduced
device attestation of PCI devices via Component Measurement and
Authentication (CMA) / Security Protocol and Data Model (DMTF - SPDM). 
https://lpc.events/event/11/contributions/1089/ However, device
attestation and SPDM is not a PCI specific topic and the decisions made
for a Linux implementation need to take into account other transports 
and use cases. Hence this proposal for a BoF rather than session in 
either PCI or CXL uconf. Whilst the 2021 session was productive in 
raising awareness of this important topic and finding others who had 
short term requirements, it was new to many of those attending so 
little progress was made on some of the open questions.

Moving forwards a year, interest in this space has grown with the 
side effect that the list of questions is getting ever longer and 
fundamental disagreements have occurred that would benefit from 
face to face discussion. As such, this BoF will assume the audience 
are at least somewhat familiar with the topic and what has been 
proposed and move rapidly onto plotting a path forwards.

Current status
- RFC for in kernel session establishment. March 2022
https://lore.kernel.org/all/20220303135905.10420-1-Jonathan.Cameron@xxxxxxxxxx/
- Discussion threads:
https://lore.kernel.org/all/CAPcyv4jb7D5AKZsxGE5X0jon5suob5feggotdCZWrO_XNaer3A@xxxxxxxxxxxxxx/
https://lore.kernel.org/all/20220511191345.GA26623@xxxxxxxxx/
https://lore.kernel.org/all/CAPcyv4iWGb7baQSsjjLJFuT1E11X8cHYdZoGXsNd+B9GHtsxLw@xxxxxxxxxxxxxx/

Major Proposed Topics:
- Use models / transports. Need to enumerate these to understand if 
  one solution or several needed.
- Secure channel negotiation in kernel or in user-space (or novel
  solutions). The recent discussions of TLS negotiation are somewhat 
  related, though the necessary flows in SPDM are highly constrained 
  and always host initiated, perhaps leading to a different decision. 
  (TLS coverage on LWN https://lwn.net/Articles/896746/) There is not
  a suitable user-space library / daemon today (discuss adaptation
  of DMTF reference implementation)
- Certificate management. Current proposal is simple but is it fine
  grained enough?
- Policy control. What is fall back if we can’t attest the device? 
  Device driver specific, or more general?
- Emulation requirements before commonly available hardware. QEMU 
  support for the PCI/CMA transport is available, QEMU emulation 
  MCTP over I2C PoC planned.

People likely to be interested:
- Security / attestation specialists
- Those involved in the TLS work who may be able to advise on how to 
  avoid pitfalls they have met.
- PCI driver developers (for attestation and also Link Encryption key 
  exchange)
- CXL developers (attestation and Link Encryption)
- USB? Others. SPDM is used on these transports, but not clear if OS 
  level support needed.
- Anyone who likes reading specifications.
"

I can edit this for a few more weeks - so all comments welcome!

Please express interest in attending / helping to drive this discussion
as we'll need critical mass to make good progress.

Thanks,

Jonathan


> 
> 
> > 
> > (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
> 




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux