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]

 



Hi All,

The BoF has been accepted though not scheduled yet.
https://lpc.events/event/16/contributions/1304/

Updated RFC of kernel based cert handling with SPDM 1.2 support:
https://lore.kernel.org/linux-pci/20220906111556.1544-1-Jonathan.Cameron@xxxxxxxxxx/
Applies cleanly to current mainline.  As it's an RFC I've been lazy
in a few places, but it should convey what an in kernel only solution might
look like.

The old QEMU emulation should work fine with this (against new
spdm-emu). https://gitlab.com/jic23/qemu/-/commits/cxl-next

I might push out a rebased CXL QEMU tree with it on later this week if
I get time and resist hacking too much on another plumbers related PoC :)

Thanks all and look forward to talking to people about this next week.

Jonathan

p.s. Chris / Huai-Cheng Kuo.  I'd completely forgotten you were interested in this
topic from emulation side of things.  Not sure if you care about what Linux does
with it however but your QEMU work is still proving very useful.


On Wed, 29 Jun 2022 16:01:57 +0000
Adam Manzanares <a.manzanares@xxxxxxxxxxx> wrote:

> On Fri, Jun 24, 2022 at 03:32:41PM +0100, Jonathan Cameron wrote:
> > On Fri, 24 Jun 2022 16:15:31 +0200
> > Lukas Wunner <lukas@xxxxxxxxx> wrote:
> >   
> > > On Fri, Jun 24, 2022 at 12:08:30PM +0100, Jonathan Cameron wrote:  
> > > > I've put this in for now:    
> > > 
> > > Perfect!  For me as a non-native English speaker, it would have been
> > > a lot more difficult to write up such an excellent description,
> > > so thanks for doing this.  
> > 
> > It always feels a bit like cheating when you get to write these
> > things in your first language!  
> > >   
> > > > Hence this proposal for a BoF rather than session in 
> > > > either PCI or CXL uconf.    
> > >   
> 
> I am planning to be attending plumbers in person and am quite interested in 
> this BOF.
> 


> 
> > > I think this has overlap with the Confidential Computing uconf as well,
> > > so that might be another potentially interested audience.
> > > 
> > > (Link encryption is by its very nature "confidential computing",
> > > and attestation is explicitly mentioned on the CC uconf page:
> > > https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=10369d39-71bd8872-10371676-74fe485fb305-1ce6f2197c6a68d6&q=1&e=6639a8eb-2d66-432f-a3d9-760b3e8def9f&u=https*3A*2F*2Flpc.events*2Fevent*2F16*2Fcontributions*2F1143*2F__;JSUlJSUlJSU!!EwVzqGoTKBqv-0DWAJBm!UGKGabNBEqfdQU-FrF-bEnhwu9mRW4PRGa1LoMvehedU3XRfsZzuoHGUZUVWHVD3p26pNa-le6OwJPQwMs7wV4kiu9GUb9ld$  )
> > > 
> > > Thanks,
> > > 
> > > Lukas
> > >   
> > 
> > Good point. That is an area in which we need dance around what we
> > can an can't say (i.e. what is public from various standards orgs) but they 
> > may well still be interested.
> > 
> > Added 
> > - Confidential compute community
> > to list of people who might be interested.
> > 
> > +CC Joerg so he knows this proposal exists and can perhaps drag in anyone
> > else who might be interested.
> > 
> > https://urldefense.com/v3/__https://lore.kernel.org/all/20220624120830.00002eef@xxxxxxxxxx/__;!!EwVzqGoTKBqv-0DWAJBm!UGKGabNBEqfdQU-FrF-bEnhwu9mRW4PRGa1LoMvehedU3XRfsZzuoHGUZUVWHVD3p26pNa-le6OwJPQwMs7wV4kiu68CJwlU$ 
> > for abstract.
> > 
> > Thanks,
> > 
> > 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