Re: [PATCH 0/2] efivars: reading variables can generate SMIs

[Ard Biesheuvel]

On 16 February 2018 at 22:05, Peter Jones <pjones@xxxxxxxxxx> wrote:
> On Fri, Feb 16, 2018 at 09:09:30PM +0000, Luck, Tony wrote:
>> > That said, I'm not sure how many non-root users run the toolkit to
>> > extract their EFI certificates or check on the secure boot status of
>> > the system, but I suspect it might be non-zero: I can see the tinfoil
>> > hat people wanting at least to check the secure boot status when they
>> > log in.
>>
>> Another fix option might be to rate limit EFI calls for non-root users (on X86
>> since only we have the SMI problem). That would:
>>
>> 1) Avoid using memory to cache all the variables
>> 2) Catch any other places where non-root users can call EFI
>
> I could get behind that as well.  Currently the things I maintain do
> approximately this many normal accesses with invocations you can do as a
> user:
>
> "efibootmgr -v" - six files we always try to read, plus one per Boot####
>                   entry.
> "fwupdate --info" - one file it always tries to read, one file for each
>                     ESRT entry.
> "dbxtool -l" - one file it always reads.
> "mokutil --sb-state" - reads the same file twice.  I don't maintain
>                        this, but I'll send a patch to Gary to make it
>                        only read it once.  AFAICS all of the other
>                        invocations you can currently do as a user
>                        /legitimately/ read two files, though.
>
> Some systems seem to *love* making a pile of Boot#### entries; I think
> the most I've seen is something like 16.  So on that machine, one
> "efibootmgr -v" invocation is ~22 efivars files read.  I've never seen a
> machine that advertised more than 2 ESRT entries, but maybe we'll get
> there some day.
>

Would rate limiting (but not only for non-root) help mitigate Spectre
v1 issues in UEFI runtime services code as well? I have been looking
into unmapping the entire kernel while such calls are in progress,
because firmware is likely to remain vulnerable long after the OSes
have been fixed, and we may be able to kill two birds with one stone
here (and not break userland in the process)