linux-kernel - Re: [PATCH 4/8] platform/x86/intel/sdsi: Add netlink SPDM transport

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 01 Feb 2024 08:42:33 -0800
From: "David E. Box" <david.e.box@...ux.intel.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: netdev@...r.kernel.org, ilpo.jarvinen@...ux.intel.com, 
	sathyanarayanan.kuppuswamy@...ux.intel.com, linux-kernel@...r.kernel.org, 
	platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH 4/8] platform/x86/intel/sdsi: Add netlink SPDM transport

Hi Jiro,

Thanks for your comments.

On Thu, 2024-02-01 at 10:26 +0100, Jiri Pirko wrote:
> Thu, Feb 01, 2024 at 02:07:43AM CET, david.e.box@...ux.intel.com wrote:
> 
> [...]
> 
> 
> > +      -
> > +        name: spdm-req
> > +        type: binary
> > +      -
> > +        name: spdm-rsp
> > +        type: binary
> 
> I don't understand the need to use netlink for this. Basically what you
> do is you just use it to pass binary blobs to and from FW.
> Advantages, like well-defined attributes, notifications etc, for which
> it makes sense to use Netlink are not utilized at all.

SPDM supports the setup of a secure channel between the responder and requestor
using TLS based encryption algorthms. While this is just a transport for those
blobs, netlink seemed an appropriate interface for this type of communication.
The binary blobs can instead be broken out into the SPDM protocol messages,
right out of the spec. But for our needs this would still just define the
protocol. The algorithms themselves are not handled by the driver.

> Also, I don't thing it is good idea to have hw-driver-specific genl
> family. I'm not aware of anything like that so far. Leave netlink
> for use of generic and abstracted APIs.

Sounds like an implied rule. If so should it be documented somewhere?

> 
> Can't you just have a simple misc device for this?

It wouldn't be too much work to convert it.

David