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
