1. Background
SNVS is a companion module to the CAAM module and serves as the SOC's central reporting point for security-relevant events such as the success or failure of boot software validation and the detection of security threat events. This security event information determines whether the SoC (hardware and software) is in the proper state to allow the
CAAM to use persistent and ephemeral secrets. Based on configuration fuses and configured bits within registers, SNVS is able to detect a variety of security violation
inputs and perform the configured policy enforcement actions. SNVS incorporates both security and non-security functionality.
In correlation with HAB states, the SNVS is in charge also with the global SSM (Security State Machine) of the chip.
By default, HPCOMR[NPSWA_EN] is enabled which means than any software can access privileged registers (e.g.: the SNVS LP / setting the RTC).
In a secure closed configuration, HAB sets HPCOMR[NPSWA_EN] on zero, so will let the access to privileged registers only to privileged software.
2. Issue description
In a secured device (HAB closed), any access from non-secure world (aka the normal world) to privileged (TZ) world will fail.
- If NPSWA_EN bit is 1, the privileged registers can be read and written
- If NPSWA_EN bit is 0, the privileged registers can be read but can't be written
- If Linux is running in TZ secure world, the privileged register can be read and written in Linux kernel and Linux userspace
From the experiments, the privileged software is the software running in TZ mode, i.e. AXI Port [NS] bit is used.
NPSWA_EN bit enables only write rights to privileged registers because read is always enabled.
Some examples:
1. RTC is failing in probe on secure boot fused devices. RTC driver fails to probe at Linux booting time.
dmesg | grep rtc
[ 1.468738] imx-drm display-subsystem: bound imx-dcss-crtc.0 (ops dcss_crtc_ops)
[ 1.793324] snvs_rtc 30370000.snvs:snvs-rtc-lp: failed to enable rtc -110
[ 1.800219] snvs_rtc: probe of 30370000.snvs:snvs-rtc-lp failed with error -110
[ 3.414458] hctosys: unable to open rtc device (rtc0)
2.1. Conditions to Reproduce
- Secure boot enabled (Chip is closed - Security Configuration Enabled) - mandatory condition
- i.MX 8MQ - Boot Linux OS and the RTC driver will fail to probe in the kernel during kernel boot up
- i.MX 6/7 - Boot Linux OS with TEE enabled (this will make Linux OS booting in the non-secure world) and the rootfs will fail to be mounted (the same reason - configuring the SNVS LP privileged registers will fail).
By default, i.MX 6/7 u-boot and Linux are considered booting in secure world by default. So accessing the SNVS privileged registers in HAB closed mode it's ok.
By default, i.MX 8M/MN/Mini u-boot and Linux are considered booting in non-secure world by default. So accessing the SNVS privileged registers in HAB closed mode will fail. The difference comparing with legacy i.MX6/7 is introduced by ATF (Arm-Trusted-Firmware) from ARM which is used for booting the arm64 bits SoCs making the accesses from secure world (bootROM) to non-secure world (u-boot/Linux).
3. Impacted devices
- i.MX 6/7
- i.MX 8M/MM/Nano
Not impacted:
- i.MX 8/8X - SNVS handling is made via SECO API (SECO is considered secured every time because of the NXP Closed LC by default).
4. Workarounds
From security access reasons, we didn't set NPSWA_EN=1 in SPL/u-boot when HAB is enabled but seems we have drivers in Linux that's requesting access to SNVS even when HAB is enabled.
For all i.MX impacted families, the suggested patch below is recommended to be used in SPL/u-boot:
+#define SNVS_HPCOMR 0x04
+#define SNVS_HPCOMR_NPSWA_EN BIT(31)
+
+void init_snvs(void)
+{
+ u32 val;
+
+ /* Ensure SNVS HPCOMR sets NPSWA_EN to allow unpriv access to SNVS LP */
+ val = readl(SNVS_BASE_ADDR + SNVS_HPCOMR);
+ val |= SNVS_HPCOMR_NPSWA_EN;
+ writel(val, SNVS_BASE_ADDR + SNVS_HPCOMR);
+}
5. Conclusion
Adopting the suggested patch in the u-boot/Linux will fix the issue identified in this document.
This issue does not impact the Secure Boot flow.
