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

Message-ID: <2025011407-muppet-hurricane-196f@gregkh>
Date: Tue, 14 Jan 2025 14:21:57 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Xi Ruoyao <xry111@...111.site>
Cc: Arnd Bergmann <arnd@...db.de>, Qunqin Zhao <zhaoqunqin@...ngson.cn>,
	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 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?

thanks,

greg k-h