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. -- Xi Ruoyao <xry111@xxxxxxxxxxx> School of Aerospace Science and Technology, Xidian University
