| Message ID | 20250114095527.23722-1-zhaoqunqin@loongson.cn |
|---|---|
| Headers | show |
| Series | Drivers for Loongson security engine | expand |
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.
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
在 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
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
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. Best Regards.
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".