linux-kernel - Re: [PATCH v1 3/3] misc: ls6000se-sdf: Add driver for Loongson 6000SE SDF

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] [day] [month] [year] [list]

Message-ID: <2025011527-antacid-spilt-cbef@gregkh>
Date: Wed, 15 Jan 2025 08:58:40 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Qunqin Zhao <zhaoqunqin@...ngson.cn>
Cc: Xi Ruoyao <xry111@...111.site>, Arnd Bergmann <arnd@...db.de>,
	Lee Jones <lee@...nel.org>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	linux-kernel@...r.kernel.org, loongarch@...ts.linux.dev,
	"David S . Miller" <davem@...emloft.net>,
	linux-crypto@...r.kernel.org,
	"derek.kiernan@....com" <derek.kiernan@....com>,
	"dragan.cvetic@....com" <dragan.cvetic@....com>,
	Yinggang Gu <guyinggang@...ngson.cn>
Subject: Re: [PATCH v1 3/3] misc: ls6000se-sdf: Add driver for Loongson
 6000SE SDF

On Wed, Jan 15, 2025 at 10:58:52AM +0800, Qunqin Zhao wrote:
> 
> 在 2025/1/14 下午9:21, Greg Kroah-Hartman 写道:
> > On Tue, Jan 14, 2025 at 06:43:24PM +0800, Xi Ruoyao wrote:
> > > On Tue, 2025-01-14 at 11:17 +0100, Arnd Bergmann wrote:
> > > > On Tue, Jan 14, 2025, at 10:55, Qunqin Zhao wrote:
> > > > > Loongson Secure Device Function device supports the functions specified
> > > > > in "GB/T 36322-2018". This driver is only responsible for sending user
> > > > > data to SDF devices or returning SDF device data to users.
> > > > I haven't been able to find a public version of the standard
> > > A public copy is available at
> > > https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=69E793FE1769D120C82F78447802E14F,
> > > pressing the blue "online preview" button, enter a captcha and you can
> > > see it.  But the copy is in Chinese, and there's an explicit notice
> > > saying translating this copy is forbidden, so I cannot translate it for
> > > you either.
> > > 
> > > > but
> > > > from the table of contents it sounds like this is a standard for
> > > > cryptographic functions that would otherwise be implemented by a
> > > > driver in drivers/crypto/ so it can use the normal abstractions
> > > > for both userspace and in-kernel users.
> > > > 
> > > > Is there some reason this doesn't work?
> > > I'm not an lawyer but I guess contributing code for that may have some
> > > "cryptography code export rule compliance" issue.
> > Issue with what?  And why?  It's enabling the functionality of the
> > hardware either way, so the same rules should apply no matter where the
> > driver ends up in or what apis it is written against, right?
> 
> SDF and tpm2.0 are both  "library specifications",  which means that
> 
> it supports a wide variety of functions not only cryptographic functions,
> 
> but unlike tpm2.0, SDF is only used in China.
> 
> You can refer to the tpm2.0 specification:
> https://trustedcomputinggroup.org/resource/tpm-library-specification/

So this is an accelerator device somehow?  If it provides crypto
functions, it must follow the crypto api, you can't just provide a "raw"
char device node for it as that's not going to be portable at all.
Please fit it into the proper kernel subsystem for the proper
user/kernel api needed to drive this hardware.

thanks,

greg k-h