IMX8-QXP-C0: tamper

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

IMX8-QXP-C0: tamper

5,968 Views
PBR
Contributor IV

Hello,

Using a IMX8QXP-C0, I want to use a tamper (SC_P_CSI_D05_SNVS_TAMPER_IN0).

I saw I could use imx_sc_seco_secvio_config() in order to configure SVNS registers from Linux.
Unfortunately (and strangely!!), this function can access to some SNVS registers (as HPSVCR, LPSR, LPTDSR...) but not at all of them.
Especially, I can not read/write LPTDC2R which is used to configure tampers.

So here is my questions:
- Why could not I read/write some SVNS registers (as LPTDC2R) with imx_sc_seco_secvio_config() function?

- Is there any other way to use tampers?

 

Thank you for your help.

0 Kudos
Reply
34 Replies

1,529 Views
Rita_Wang
NXP TechSupport
NXP TechSupport

@PBR Please help to check one more thing. Customer use i.MX8QXP C0, do they use FIPS part or non-FIPS part? There are some differences between the two parts on ZMK. Thank you.

0 Kudos
Reply

1,525 Views
PBR
Contributor IV

@Rita_Wang 

Hello, I am not sure what FIPS.

Anyway, if you give me an example where a key is automatically deleted when there is a violation in the easiest case (with or without FIPS, it is up to you), it will answer my need.

 

0 Kudos
Reply

1,476 Views
Rita_Wang
NXP TechSupport
NXP TechSupport

@PBR I have updated some information from our expert team. Please have check.

Requirement: A secrete data (a key) is written somewhere, when there is a violation, the data is automatically destroyed.

(1) GPR: The data was not automatically cleared — GPR_Z_DIS is set during SNVS init.  At the moment this bit is set by default in the code. No API exists to clear it.

(2) ZMK: The data cannot be read back — The W1 limitation on ZMK on i.MX8QXP.

The W1 limitation is by SECO FW.

Changing this behavior is possible but would be a non backward-compatible change – so would likely need to go through some kind of CCB.

In summary, there is no such place by default in this moment.  For next step, we will sync with internal team on CCB.

0 Kudos
Reply

1,493 Views
Rita_Wang
NXP TechSupport
NXP TechSupport

@PBR We are confirming about the reason why ZMK cannot be read. When I have update I will tell you as soon as possible.

0 Kudos
Reply

1,593 Views
Rita_Wang
NXP TechSupport
NXP TechSupport

This is update from our design team, I will try to confirm again.

0 Kudos
Reply

1,632 Views
Rita_Wang
NXP TechSupport
NXP TechSupport

By now no update, due to the COID-19 we have to stay at home, so some test maybe hard to do on our board. I am still wait for the update from our design team, when I have update from them I will tell you as soon as possible.

0 Kudos
Reply

1,602 Views
PBR
Contributor IV
0 Kudos
Reply

1,803 Views
Rita_Wang
NXP TechSupport
NXP TechSupport

Good news it works. Other question I will help confirm.

0 Kudos
Reply

1,847 Views
Rita_Wang
NXP TechSupport
NXP TechSupport

Can you provide the steps and configuration? We can try if we can reproduce on our side.

0 Kudos
Reply

1,842 Views
PBR
Contributor IV

Here is my u-boot/linux DTS configuration:
fsl,pins = <
IMX8QXP_CSI_D05 3 0x00000060
>;
(as IMX8QXP_CSI_D05_SNVS_TAMPER_IN0 is not defined in pads-imx8qxp.h, I have to define "IMX8QXP_CSI_D05 3")

1) u-boot steps
If I do the configuration with u-boot, I tried 3 different commands in 3 different tests:
snvs_cfg 1f0703ff 8000003f 3000007f 1f0003ff 36 00800000 276 0 0 0 84001111 0 0 0 0 00010001 0 1 0
snvs_cfg 1f0703ff 8000003f 3000007f 1f0003ff 36 00800000 276 ff 0 0 84001111 0 0 0 0 001f001f 0 1 0
snvs_cfg 00000000 8000003f 3000007f 00000000 3f 00000000 776 ff 0 0 84001111 0 0 0 0 001f001f 0 1 0

But when I modify the tamper (with just removing a jumper on the board), it does not modify any SNVS registers (I used snvs_sec_status, you can see the result of this command in my last post)

So which snvs_cfg parameters do I need to use?
How to see any modification when I put/remove the tamper jumper?

2) linux steps
Now I tried on linux.
I am using imx-secvio-sc.c file.

I add at the beginning of the imx_secvio_sc_ioctl() function:
u32 val0=0;
u32 val1=0;
ret = call_secvio_config(dev, 0x18, SECVIO_CONFIG_WRITE, &val0, NULL, NULL, NULL, NULL, 1);
if (ret) {
printk("1-Error Reg 18: %d\n", ret);
}
ret = call_secvio_config(dev, 0x48, SECVIO_CONFIG_WRITE, &val0, &val1, NULL, NULL, NULL, 2);
if (ret) {
printk("2-Error Reg 48+A0: %d\n", ret);
}
ret = call_secvio_config(dev, 0x48, SECVIO_CONFIG_WRITE, &val0, NULL, NULL, NULL, NULL, 1);
if (ret) {
printk("3-Error Reg 48: %d\n", ret);
}
ret = call_secvio_config(dev, 0xA0, SECVIO_CONFIG_WRITE, &val0, NULL, NULL, NULL, NULL, 1);
if (ret) {
printk("4-Error Reg A0: %d\n", ret);
}
ret = call_secvio_config(dev, 0x18, SECVIO_CONFIG_WRITE, &val0, NULL, NULL, NULL, NULL, 1);
if (ret) {
printk("5-Error Reg 18: %d\n", ret);
}
return 0;// So I ignore the code after this

I launch this command on my target:
./ioctl /dev/secvio-sc 1

And here is the result:
[ 27.953802] 2-Error Reg 48+A0: -32
[ 27.957344] 3-Error Reg 48: -22
[ 27.965539] 4-Error Reg A0: -22

So I can modify Reg 18 but not 48, A0.
How can I modify Reg A0?
If I succeed, which C function which can tell me the tamper has detected something?

Just note I had to modfy imx-secvio-sc.c file as I had another issue: when opening /dev/secvio-sc, node->i_private was null and not equal to 'dev' structure.
So I did some patch.
I created :
struct device *mydev=0;
In call_secvio_config(), I add this instruction:
if (mydev==0) mydev=dev;
In imx_secvio_sc_open(), I replace this instruction:
filp->private_data = mydev;//node->i_private;

0 Kudos
Reply

1,884 Views
Rita_Wang
NXP TechSupport
NXP TechSupport

I will confirm it for you.

0 Kudos
Reply

1,916 Views
PBR
Contributor IV

Unfortunately no.

0 Kudos
Reply

1,920 Views
josephzhou1
Contributor V

u solved it already ?

Best Regards,
Joseph Zhou Jianhui / Senior Embedded Software Engineer, Singapore
0 Kudos
Reply

1,931 Views
PBR
Contributor IV

Any help ??

0 Kudos
Reply