diff mbox series

[v1,3/3] misc: ls6000se-sdf: Add driver for Loongson 6000SE SDF

Message ID 20250114095527.23722-4-zhaoqunqin@loongson.cn (mailing list archive)
State Under Review
Delegated to: Herbert Xu
Headers show
Series Drivers for Loongson security engine | expand

Commit Message

Qunqin Zhao Jan. 14, 2025, 9:55 a.m. UTC
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.

Co-developed-by: Yinggang Gu <guyinggang@loongson.cn>
Signed-off-by: Yinggang Gu <guyinggang@loongson.cn>
Signed-off-by: Qunqin Zhao <zhaoqunqin@loongson.cn>
---
 MAINTAINERS                 |   1 +
 drivers/misc/Kconfig        |   9 +++
 drivers/misc/Makefile       |   1 +
 drivers/misc/ls6000se-sdf.c | 123 ++++++++++++++++++++++++++++++++++++
 4 files changed, 134 insertions(+)
 create mode 100644 drivers/misc/ls6000se-sdf.c

Comments

Arnd Bergmann Jan. 14, 2025, 10:17 a.m. UTC | #1
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, 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?

     Arnd
Xi Ruoyao Jan. 14, 2025, 10:43 a.m. UTC | #2
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.
Greg Kroah-Hartman Jan. 14, 2025, 1:21 p.m. UTC | #3
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
Qunqin Zhao Jan. 15, 2025, 2:58 a.m. UTC | #4
在 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
Greg Kroah-Hartman Jan. 15, 2025, 7:58 a.m. UTC | #5
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
Zheng, Yaofei Jan. 15, 2025, 10:39 a.m. UTC | #6
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.
Xi Ruoyao Jan. 15, 2025, 11:13 a.m. UTC | #7
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.
diff mbox series

Patch

diff --git a/MAINTAINERS b/MAINTAINERS
index e65a7f4ea4..e313e0daf8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13485,6 +13485,7 @@  M:	Qunqin Zhao <zhaoqunqin@loongson.com>
 L:	linux-crypto@vger.kernel.org
 S:	Maintained
 F:	drivers/crypto/loongson/
+F:	drivers/misc/ls6000se-sdf.c
 
 LOONGSON-2 APB DMA DRIVER
 M:	Binbin Zhou <zhoubinbin@loongson.cn>
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 09cbe3f0ab..10a3ea59a1 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -634,6 +634,15 @@  config MCHP_LAN966X_PCI
 	    - lan966x-miim (MDIO_MSCC_MIIM)
 	    - lan966x-switch (LAN966X_SWITCH)
 
+config LS6000SE_SDF
+	tristate "Loongson Secure Device Function driver"
+	depends on MFD_LS6000SE
+	help
+	  Loongson Secure Device Function device is the child device of Loongson
+	  Security Module device, it supports the functions specified in
+	  GB/T 36322-2018.  This driver will use the interface of Loongson Security
+	  Module driver.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 40bf953185..b273ec7802 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -74,3 +74,4 @@  lan966x-pci-objs		:= lan966x_pci.o
 lan966x-pci-objs		+= lan966x_pci.dtbo.o
 obj-$(CONFIG_MCHP_LAN966X_PCI)	+= lan966x-pci.o
 obj-y				+= keba/
+obj-$(CONFIG_LS6000SE_SDF)	+= ls6000se-sdf.o
diff --git a/drivers/misc/ls6000se-sdf.c b/drivers/misc/ls6000se-sdf.c
new file mode 100644
index 0000000000..646d54b6e4
--- /dev/null
+++ b/drivers/misc/ls6000se-sdf.c
@@ -0,0 +1,123 @@ 
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (C) 2025 Loongson Technology Corporation Limited */
+
+#include <linux/init.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/mfd/ls6000se.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+#include <linux/wait.h>
+
+#define SE_SDF_BUFSIZE	(PAGE_SIZE * 2)
+
+struct sdf_dev {
+	struct miscdevice miscdev;
+	struct lsse_ch *se_ch;
+	struct completion sdf_completion;
+};
+
+struct sdf_msg {
+	u32 cmd;
+	u32 data_off;
+	u32 data_len;
+	u32 pad[5];
+};
+
+static void sdf_complete(struct lsse_ch *ch)
+{
+	struct sdf_dev *sdf = ch->priv;
+
+	complete(&sdf->sdf_completion);
+}
+
+static int send_sdf_cmd(struct sdf_dev *sdf, int len)
+{
+	struct sdf_msg *smsg = sdf->se_ch->smsg;
+
+	smsg->data_len = len;
+
+	return se_send_ch_requeset(sdf->se_ch);
+}
+
+static ssize_t sdf_read(struct file *file, char __user *buf,
+			size_t cnt, loff_t *offt)
+{
+	struct sdf_dev *sdf = container_of(file->private_data,
+					   struct sdf_dev, miscdev);
+	struct sdf_msg *rmsg;
+
+	if (!wait_for_completion_timeout(&sdf->sdf_completion, HZ*5))
+		return -ETIME;
+
+	rmsg = (struct sdf_msg *)sdf->se_ch->rmsg;
+	if (copy_to_user(buf,
+			 sdf->se_ch->data_buffer + rmsg->data_off, rmsg->data_len))
+		return -EFAULT;
+
+	return rmsg->data_len;
+}
+
+static ssize_t sdf_write(struct file *file, const char __user *buf,
+			 size_t cnt, loff_t *offt)
+{
+	struct sdf_dev *sdf = container_of(file->private_data,
+					   struct sdf_dev, miscdev);
+	int ret;
+
+	if (copy_from_user(sdf->se_ch->data_buffer, buf, cnt))
+		return -EFAULT;
+
+	ret = send_sdf_cmd(sdf, cnt);
+
+	return ret ? -EFAULT : cnt;
+}
+
+static const struct file_operations sdf_fops = {
+	.owner = THIS_MODULE,
+	.write = sdf_write,
+	.read = sdf_read,
+};
+
+static int sdf_probe(struct platform_device *pdev)
+{
+	struct sdf_msg *smsg;
+	struct sdf_dev *sdf;
+	static int idx;
+
+	sdf = devm_kzalloc(&pdev->dev, sizeof(*sdf), GFP_KERNEL);
+	if (!sdf)
+		return -ENOMEM;
+	init_completion(&sdf->sdf_completion);
+
+	sdf->se_ch = se_init_ch(pdev->dev.parent, SE_CH_SDF, SE_SDF_BUFSIZE,
+				sizeof(struct sdf_msg) * 2, sdf, sdf_complete);
+	smsg = sdf->se_ch->smsg;
+	smsg->cmd = SE_CMD_SDF;
+	smsg->data_off = sdf->se_ch->off;
+	sdf->miscdev.minor = MISC_DYNAMIC_MINOR;
+	sdf->miscdev.name = devm_kasprintf(&pdev->dev, GFP_KERNEL,
+					   "lsse_sdf%d", idx++);
+	sdf->miscdev.fops = &sdf_fops;
+
+	return misc_register(&sdf->miscdev);
+}
+
+static struct platform_driver loongson_sdf_driver = {
+	.probe	= sdf_probe,
+	.driver  = {
+		.name  = "ls6000se-sdf",
+	},
+};
+module_platform_driver(loongson_sdf_driver);
+
+MODULE_ALIAS("platform:ls6000se-sdf");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Yinggang Gu <guyinggang@loongson.cn>");
+MODULE_AUTHOR("Qunqin Zhao <zhaoqunqin@loongson.cn>");
+MODULE_DESCRIPTION("Loongson Secure Device Function driver");