linuxefi: Invalidate i-cache before starting the kernel

[dannf]

We need to flush the memory range of the code we are about to execute
from the instruction cache before we can safely execute it. Not doing
so appears to be the source of rare synchronous exceptions a user
is seeing on a Cortex-A72-based platform while executing the Linux EFI
stub. Notably they seem to correlate with an instruction on a cache
line boundary.

Signed-off-by: dann frazier dann.frazier@canonical.com

[dannf]

Related: rhboot/shim#504

[frozencemetery]

Thanks for the patch. In the shim case, we only flush on aa64, while this seems to always be flushing. Is there a particular reason for that, or was it just easier?

[dannf]

Thanks for the patch. In the shim case, we only flush on aa64, while this seems to always be flushing. Is there a particular reason for that, or was it just easier?

Well noticed. In GRUB, grub_arch_sync_caches() is a no-op on x86. A google search tells me that x86 automatically invalidates cached instructions when those addresses are written. Does shim support arches other than x86 & aarch64?

Hm.. gcc appears to optimize out calls to __builtin___clear_cache() on x86. Maybe we just skip the arch guard altogether in shim to future proof it?

[jlinton]

Just stumbled on this, and it makes sense. The grub_cmd_linux() is just loading the kernel as normal data, I don't see anything in that path that is going to force the I-D cache to be coherent (most older Arm machines aren't I/D coherent), so anything that has been prefetched or is stale in the icache will remain there before the code is executed. Alternatively, one could just do this on arm64, path, or maybe we should start considering switching to back to using the bootservices as upstream grub is still doing (AFAIK after looking at it). X86/etc should not have this issue.