Re: [PATCH] efivarfs: Expose RandomSeed variable but with limited permissions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 25 Jun 2023 at 07:44, Jason A. Donenfeld <Jason@xxxxxxxxx> wrote:
>
> Hm, I'm still not so sure we want to open the pandora's box of having to
> deal with userspaces writing this. Maybe we can keep it in the kernel
> but delay it until a little later in boot so it doesn't cause an
> outright bootup hang?

I don't know a good point to do it at, which would be after the system
is clearly up and running.

The obvious "just delay it by a X amount" might not even work, because
you have things like "the system is still waiting for the user to type
the DM password" or something like that.

That said, it might be enough to at least see if Sami gets more information.

Sami - can you try to revert the revert:

        git revert 69cbeb61ff9093a9155cb19a36d633033f71093a

but then additionally in drivers/firmware/efi/efi.c, just change the

        static DECLARE_WORK(work, refresh_nv_rng_seed);
        schedule_work(&work);

in refresh_nv_rng_seed_notification() to be something like

        static DECLARE_DELAYED_WORK(work, refresh_nv_rng_seed);
        schedule_delayed_work(&work, 120*HZ);

to make the work fire two minutes after boot?

The question then being:

 (a) does that fix the boot for you (maybe it's the schedule_work
itself that confused things, however unlikely that sounds)

 (b) if it does boot, do you notice something happening two minutes
after booting?

But see all the craziness (for example) in efi_query_variable_store()
and the whole 'efi_no_storage_paranoia' thing etc. Messing with EFI
variables has always been painful.

Or just look at efi_crash_gracefully_on_page_fault() and the whole efi
runtime services garbage with efi_rts_work etc.

Yes, those are presumably mostly old EFI setups, but that is kind of
the basic problem here. Many of these EFI calls are much more tested
and reliable in the context of EFI boot services, and *much* less
reliable in the context of "runtime services".

EFI runtime services have been a major PITA over the years. And it's
possible that it's just entirely broken on Sami's laptop.

I'm not entirely sure which laptop it is, with laptop manufacturers
often re-using model names over several years, but "HP 6730b" seems to
be basically from July 2008 (going by the service manual I found). So
we're talking 15 years ago, and yes, EFI was likely *much* less
reliable back then.

              Linus



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux