Skip to content

Conversation

@a3f
Copy link

@a3f a3f commented Jun 11, 2025

We once again stumbled over errata fixups that were applied twice, first in the barebox bootloader and then in the Linux kernel. This went unnoticed at first, but with OP-TEE enabled as a secure monitor, the system hangs very early before regular console output is available.

The Linux kernel errata fixes for non-ARCH_MULTIPLATFORM will likely never go away, because bootloaders may not be updatable in the field and sometimes don't even suffer from the consequences, e.g. because they affect only SMP.

Therefore, let's add at least a way for the bootloader to tell the OS about whether it's running in the secure world or not.

We once again stumbled over errata fixups that were applied twice, first in
the barebox bootloader and then in the Linux kernel.
This went unnoticed at first, but with OP-TEE enabled as a secure
monitor, the system hangs very early before regular console output is
available.

The Linux kernel errata fixes for non-ARCH_MULTIPLATFORM will likely never
go away, because bootloaders may not be updatable in the field and sometimes
don't even suffer from the consequences, e.g. because they affect only SMP.

Therefore, let's add at least a way for the bootloader to tell the OS about
whether it's running in the secure world or not.

Signed-off-by: Ahmad Fatoum <[email protected]>
@a3f
Copy link
Author

a3f commented Jun 11, 2025

The enumeration is not exhaustive even for ARMv7, but I think it doesn't need to be. If bootloader starts the kernel in hypervisor state, it can still say non-secure IMO. On ARMv8, one shouldn't need this property anyway, but if it's there, it would reflect whether it's S-EL2 or regular EL2.

@robherring
Copy link
Member

What platforms and errata fixes are we talking about specifically. I'd like to see what the response is to adding this to the kernel.


arm,security-state:
$ref: types.yaml#/definitions/string
enum: [ non-secure, secure ]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"non-secure" is the default for what's expected, so I don't think we should have a value for it. Then it becomes a question of whether we'd ever need something beyond "secure" and this could just be a boolean.

Copy link
Author

@a3f a3f Jun 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From my experience, the default for ARMv7 is the kernel first starting in secure mode, because there's no OP-TEE or TF-A that switches to normal world.

@a3f
Copy link
Author

a3f commented Jun 27, 2025

What platforms and errata fixes are we talking about specifically.

@bith3ad had inherited a kernel that enabled ARM_ERRATA_751472 on an i.MX6Q.
When OP-TEE was added, the kernel now booted in non-secure mode, which led to a very early hang that was annoying to debug. The kernel config now enables ARCH_MULTIPLATFORM, which disables ARM_ERRATA_751472, but we feel it's prudent for the kernel to know what security state it starts in, so such issues can't happen in the first place.

I'd like to see what the response is to adding this to the kernel.

I did not start the discussion upstream yet. I wanted to test waters with the property and then take the discussion to linux-arm-kernel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants