aarch64_cpu::asm::ret is impossible to use without causing UB

[bjorn3]

It is implemented as asm!("ret"); hint::unreachable_unchecked(), which is unconditionally UB to execute. It is completely valid for the codegen backend to outline the inline asm into another function (causing the unreachable_unchecked() to be hit which is UB and possibly have a corrupt stack due to missing stack pointer adjustments before returning. An example of a codegen backend that does this is cg_clif as Cranelift doesn't have a builtin assembler) or to ignore the #[inline(always)] on fn ret(), causing a regular return from a diverging function, which is UB too.

And aarch64_cpu::asm::eret should probably be marked as unsafe. And unless the exception/interrupt entrypoint resets the EL1 stack pointer back to the original value, there is no guarantee that you won't get a stack overflow eventually due to stack pointer adjustments being skipped.

[pitust]

aarch64_cpu::asm::eret is also impossible to meaningfully use in a correct manner as well, I believe, because it doesn't place any bounds on any of the registers which makes it kinda useless even if it is sound.

[andre-richter]

I wouldn’t say impossible for the eret case. Here is an example of where it’s being used as part of an initial drop from EL2 down to EL1: https://github.com/rust-embedded/rust-raspberrypi-OS-tutorials/blob/master/19_kernel_heap/kernel/src/_arch/aarch64/cpu/boot.rs.
Although I would probably write this in asm these days if I had to do it again.

In the past, specifically in the context of tock-registers, we had recurring discussions about marking functions unsafe that operate on CPU registers.
The consensus mostly was that manipulating CPU register values is in itself a safe operation if it’s not something as strange as randomly changing GPRs, for example, which have some rust-allocated addresses/variables cached.

Of course there are numerous situations where second order effects of manipulating CPU registers can cause memory safety issues (random example: change translation table base registers to point to tables which cause memory aliasing of rust objects in memory).

But we deemed changing machine state like that is outside of what Rust memory safety mechanisms (including the unsafe keyword) are supposed cover.
Executing eret isn’t even changing a register value, but potential memory issues arising from it would also go into the „second order effects“ category here I‘d say.