linux-kernel - Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 21 Feb 2018 09:03:00 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "Luck, Tony" <tony.luck@...el.com>,
        Joe Konno <joe.konno@...ux.intel.com>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Matthew Garrett <matthew.garrett@...ula.com>,
        Jeremy Kerr <jk@...abs.org>, Andi Kleen <ak@...ux.intel.com>,
        Matthew Garrett <mjg59@...gle.com>,
        Peter Jones <pjones@...hat.com>,
        Andy Lutomirski <luto@...nel.org>,
        James Bottomley <james.bottomley@...senpartnership.com>
Subject: Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

On 21 February 2018 at 02:16, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Tue, Feb 20, 2018 at 5:05 PM, Luck, Tony <tony.luck@...el.com> wrote:
>>>> EFI[1] stinks. Reading any file in /sys/firmware/efi/efivars/ generates
>>>> 4 (yes FOUR!) SMIs.
>>
>>> Is that actualkly the normal implementation?
>>
>> I don't know if there are other implementations. This is what I see on my
>> lab system.
>
> Ok. I'm not a huge fan of EFI. Over-designed to the hilt. Happily at
> least the loadable drivers are a thing of the past.
>

I don't think there is any disagreement on that aspect of the discussion.

> Do we have a list of things normal users care about? Because one thing
> that would solve it is caching of the values. We don't want to do that
> in general, but maybe we could just do it for the subset that we think
> are "user accessible".
>
> Although maybe just that "rate limit" thing would be simplest.
>

The thing I like about rate limiting (for everyone including root) is
that it does not break anybody's workflow (unless EFI variable access
occurs on a hot path, in which case you're either a) asking for it, or
b) the guy trying to DoS us), and that it can make exploitation of any
potential Spectre v1 vulnerabilities impractical at the same time. At
present, we don't know if this is a concern, but we cannot rule it
out, and what we do know is that those shiny new Spectre-proof kernels
that we will have any day now will be running on systems with UEFI
firmware that may contain vulnerable code paths and may never get
updated. Perhaps I am being overly paranoid here, but if we end up
adding rate limiting, let's just apply it to root as well.

> I don't want to break existing users, although it's not entirely clear
> to me if there are any real use cases that matter to users. If tpmtotp
> is the main case, maybe that can be changed to work around it and just
> cache a value or something?
>
> So I could imagine just applying Joe's / Andy's patch to see if
> anybody even notices. But if somebody does, we'd have to go to the
> alternatives anyway.
>
>                 Linus