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

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

[Jonathan Cameron]

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

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

[Ira Weiny]

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

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

[Jonathan Cameron]

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:
> > 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.

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.

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

Ah. I remembered to CC Christoph but not to actually link the relevant mail.

That proposal is definitely interesting.

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

Cool. See you there in some fashion.  

Jonathan

> 
> Ira

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

[Lukas Wunner]

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?

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


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

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

Thanks,

Lukas

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

[Jonathan Cameron]

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

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

[Jonathan Cameron]

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

> 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'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@huawei.com/
- Discussion threads:
https://lore.kernel.org/all/CAPcyv4jb7D5AKZsxGE5X0jon5suob5feggotdCZWrO_XNaer3A@mail.gmail.com/
https://lore.kernel.org/all/20220511191345.GA26623@wunner.de/
https://lore.kernel.org/all/CAPcyv4iWGb7baQSsjjLJFuT1E11X8cHYdZoGXsNd+B9GHtsxLw@mail.gmail.com/

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
> 

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

[Lukas Wunner]

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.

> Hence this proposal for a BoF rather than session in 
> either PCI or CXL uconf.

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://lpc.events/event/16/contributions/1143/ )

Thanks,

Lukas

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

[Jonathan Cameron]

On Fri, 24 Jun 2022 16:15:31 +0200
Lukas Wunner <lukas@wunner.de> 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 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://lpc.events/event/16/contributions/1143/ )
> 
> 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://lore.kernel.org/all/20220624120830.00002eef@Huawei.com/
for abstract.

Thanks,

Jonathan

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

[Adam Manzanares]

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@wunner.de> 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@Huawei.com/__;!!EwVzqGoTKBqv-0DWAJBm!UGKGabNBEqfdQU-FrF-bEnhwu9mRW4PRGa1LoMvehedU3XRfsZzuoHGUZUVWHVD3p26pNa-le6OwJPQwMs7wV4kiu68CJwlU$ 
> for abstract.
> 
> Thanks,
> 
> Jonathan
> 

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

[Jonathan Cameron]

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@huawei.com/
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@samsung.com> 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@wunner.de> 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@Huawei.com/__;!!EwVzqGoTKBqv-0DWAJBm!UGKGabNBEqfdQU-FrF-bEnhwu9mRW4PRGa1LoMvehedU3XRfsZzuoHGUZUVWHVD3p26pNa-le6OwJPQwMs7wV4kiu68CJwlU$ 
> > for abstract.
> > 
> > Thanks,
> > 
> > Jonathan
> >