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: <122aab11-f657-a48e-6b83-0e01ddd20ed3@loongson.cn>
Date: Wed, 15 Jan 2025 10:58:52 +0800
From: Qunqin Zhao <zhaoqunqin@...ngson.cn>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Xi Ruoyao <xry111@...111.site>, Arnd Bergmann <arnd@...db.de>
Cc: 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


在 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/


Best regards,

Qunqin.

>
> thanks,
>
> greg k-h