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]
Message-ID: <94a61858ac82ceaac1ef8ae41067ae7356512d7d.camel@linux.intel.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ