Hi,
On 1/15/25 19:13, Xi Ruoyao wrote:
On Wed, 2025-01-15 at 10:39 +0000, Zheng, Yaofei wrote:
Internal Use - Confidential
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/ne
wGbInfo?hcno=69E793FE1769D120C82F78447802E14F__;!!LpKI!g7kUt84vOxl
65EbgAJzXoupsM5Bx3FjUDPnKHaEw5RUoyUouS6IwCerRSZ7MIWi0Bw5WHaM2YP7pZ
IcYiDQOLf3F$ [openstd[.]samr[.]gov[.]cn], 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/__;!!LpKI!g7kUt84vOxl65EbgAJzXoupsM5Bx3FjUD
PnKHaEw5RUoyUouS6IwCerRSZ7MIWi0Bw5WHaM2YP7pZIcYiCFoP-hu$
[trustedcomputinggroup[.]org]
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
Hi Qunqin and Ruoyao,
"GB/T 36322-2018" is just a chinese national standard, not ISO standard, not an
enforced one, "T" repensts "推荐" which means "recommend". From what I understand
it defined series of C API for cryptography devices after reading the standard.
Linux kernel have user space socket interface using type AF_ALG, and out of tree
driver "Cryptodev". From my view: "GB/T 36322-2018" can be user space library
using socket interface, just like openssl, if must do it char dev way, do it out
of tree, and reuse kernel space crypto API.
Figure 1 of the section 6.1 says the GB/T 36322 interface is between
"cryptography device" and "generic cryptography service and cryptography
device management." IMO in a Linux (or any monolithic-kernel) system at
least "cryptography device management" is the job of the kernel, thus
exposing the GB/T 36322 interface directly to the userspace seems not a
good idea.
I've also taken a look at the standard text. The majority of it is the
SDF API definition which is in C and with all identifiers in English, so
even non-speakers of Chinese can probably understand much of it.
But I tend to agree that the SDF API is abstract enough that it does not
matter whether it's directly exposed by kernel UAPI or not; while I'm
not familiar with the Linux crypto subsystem either, it seems entirely
appropriate for the kernel driver to expose the standard crypto API, and
for the SDF API to reside in a user-space shim. This way we could have
non-SDF-aware applications transparently make use of the Loongson HW
capability, and also have non-Loongson crypto HW available through the
same SDF interface (should some board designer choose to do so).
--
WANG "xen0n" Xuerui
Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
