public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Nicolas Bouchinet <nicolas.bouchinet@oss.cyber.gouv.fr>
Cc: Luc Bonnafoux <luc.bonnafoux@ssi.gouv.fr>,
	Alan Stern <stern@rowland.harvard.edu>,
	Kannappan R <r.kannappan@intel.com>,
	Sabyrzhan Tasbolatov <snovitoll@gmail.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Stefan Eichenberger <stefan.eichenberger@toradex.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Pawel Laszczak <pawell@cadence.com>, Ma Ke <make_ruc2021@163.com>,
	Jeff Johnson <jeff.johnson@oss.qualcomm.com>,
	Luc Bonnafoux <luc.bonnafoux@oss.cyber.gouv.fr>,
	Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	Lukas Wunner <lukas@wunner.de>,
	Alistair Francis <alistair@alistair23.me>,
	Oliver Neukum <oneukum@suse.com>
Subject: Re: [RFC PATCH v2 0/4] Support for usb authentication
Date: Fri, 25 Jul 2025 10:54:41 +0200	[thread overview]
Message-ID: <2025072555-praying-shakiness-121f@gregkh> (raw)
In-Reply-To: <d2ghp3qafwrxiwkrizzxqayzkhu36ke4dolxaloksmz4z5fzpn@paxcer43kru3>

Hi,

Let me focus right now on only one thing here:

On Mon, Jul 21, 2025 at 04:51:52PM +0200, Nicolas Bouchinet wrote:
> > > Limitations
> > > ===========
> > > 
> > > The USB authentication protocol come with some inherent limitations, [3]
> > 
> > That's a 2018 reference!  Are you saying that the newly designed
> > protocol was already discussed in 2018 and found lacking?
> > 
> As far as we are aware, the last version of the specification [1] is the
> last is the last version that includes errata from 2019. [3] is a
> research paper that explored the limitation of the protocol. We are not
> aware of any evolution since. We saw that SPDM reuses some of the USB
> specification fields but we are not entirely sure yet if can be used in
> place of the USB specification and if it fixes the limitations.

So, this spec has been out since 2019, and it's "broken", AND there are
no actual devices using this?

If there is no hardware out there, I really do not want to be adding new
features to the kernel for this.  We ripped out wireless usb because the
thing never actually shipped and was dropped by the vendors.  Let's not
do that again here.

So if there is no hardware, there's no need for this at all, right?
Where are the vendors that wrote this spec, and why did they not
actually add support for this to their devices already?

And, most importantly, is Windows going to support this?  Because if it
is not, then there is no need for us to support it either as no vendor
is going to only be building a USB device just for Linux systems, right?

So, where are the vendors?  Without that, this is not going to actually
go very far at all, and just bit-rot in our tree :(

thanks,

greg k-h

      reply	other threads:[~2025-07-25  8:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-11  8:41 [RFC PATCH v2 0/4] Support for usb authentication nicolas.bouchinet
2025-07-11  8:41 ` [RFC PATCH v2 1/4] usb: core: Introduce netlink usb authentication policy engine nicolas.bouchinet
2025-07-11  8:41 ` [RFC PATCH v2 2/4] usb: core: Introduce usb authentication feature nicolas.bouchinet
2025-07-11  8:41 ` [RFC PATCH v2 3/4] usb: core: Plug the usb authentication capability nicolas.bouchinet
2025-07-11  8:41 ` [RFC PATCH v2 4/4] usb: core: Add sysctl to configure authentication timeouts nicolas.bouchinet
2025-07-11 11:08 ` [RFC PATCH v2 0/4] Support for usb authentication Greg Kroah-Hartman
2025-07-13 15:25 ` Greg Kroah-Hartman
2025-07-21 14:51   ` Nicolas Bouchinet
2025-07-25  8:54     ` Greg Kroah-Hartman [this message]

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=2025072555-praying-shakiness-121f@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=alistair@alistair23.me \
    --cc=jeff.johnson@oss.qualcomm.com \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=luc.bonnafoux@oss.cyber.gouv.fr \
    --cc=luc.bonnafoux@ssi.gouv.fr \
    --cc=lukas@wunner.de \
    --cc=make_ruc2021@163.com \
    --cc=nicolas.bouchinet@oss.cyber.gouv.fr \
    --cc=nicolas.bouchinet@ssi.gouv.fr \
    --cc=oneukum@suse.com \
    --cc=pawell@cadence.com \
    --cc=r.kannappan@intel.com \
    --cc=snovitoll@gmail.com \
    --cc=stefan.eichenberger@toradex.com \
    --cc=stern@rowland.harvard.edu \
    --cc=tglx@linutronix.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