Intermitted EFI firmware splats on SoftIron

[Mark Brown]

On Thu, Apr 27, 2023 at 06:15:33PM +0100, Ard Biesheuvel wrote:
> On Thu, 27 Apr 2023 at 17:42, Mark Brown <broonie at kernel.org> wrote:

> > [    9.195519] [Firmware Bug]: Unable to handle write to read-only memory in EFI runtime service

> OK, so there are two separate issues here:

> #1 - the firmware faults on a write to read-only memory (the line
> above, and everything after the 'end trace' below)
> #2 - the exception is taken while the firmware was running with
> interrupts disabled, and so we return to the caller with interrupts
> disabled, which is caught by efi_call_virt_check_flags()

Yup.

> If this is a new failure, it appears to be caused by the early
> non-volatile RNG seed stuff that Jason Donenfeld added recerntly.

I think they've both been triggering for a while, though like I say
they're intermittent so the frequency and exact paths triggering has
been variable.

> I'm not sure if there is anything we might do about this except
> disabling EFI runtime services altogether - these boxes and their
> firmware are ancient, and it doesn't look like the kernel code is
> doing anything wrong so we're not going to work around it. Disabling
> EFI runtime services would mean losing access to the RTC, so that may
> be problematic for testing, I imagine.

Looking later in the logs it appears that we already decide to disable
runtime services breaking the RTC:

[   12.343222] efi: EFI Runtime Services are disabled!
[   12.348096] rtc-efi rtc-efi.0: can't read time

when this triggers so it'd just be a question of silencing the splats.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230427/b4e6a717/attachment-0001.sig>