From: Andy Lutomirski <luto@kernel.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
"Luck, Tony" <tony.luck@intel.com>,
Andi Kleen <ak@linux.intel.com>,
Joe Konno <joe.konno@linux.intel.com>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jeremy Kerr <jk@ozlabs.org>, Matthew Garrett <mjg59@google.com>,
Peter Jones <pjones@redhat.com>,
Andy Lutomirski <luto@kernel.org>,
James Bottomley <james.bottomley@hansenpartnership.com>
Subject: Re: [PATCH v2] efivarfs: Limit the rate for non-root to read files
Date: Fri, 23 Feb 2018 20:34:15 +0000 [thread overview]
Message-ID: <CALCETrVrJWQNYcXFt4YQ-1EXFqMojiVTZhXR8zFoF+H0ZmfPjw@mail.gmail.com> (raw)
In-Reply-To: <CAKv+Gu8q-9enjK=WLiB5tWvRKQu9+xh=dCqBtB6X9wazKuYiMA@mail.gmail.com>
On Thu, Feb 22, 2018 at 6:08 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 22 February 2018 at 18:07, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> On Thu, Feb 22, 2018 at 9:54 AM, Luck, Tony <tony.luck@intel.com> wrote:
>>> With the new "while/nap" change there would still be one message
>>> per second, but the number of callbacks suppressed should be 1
>>> (unless the user has many threads doing reads).
>>>
>>> Maybe it is good to know that an application is doing something
>>> stupid and we should drop that line from the patch and let the
>>> warnings flow?
>>
>> I think the "one message per second" is fine.
>>
>> Looks good. Do I get this through the EFI tree, or should I just take
>> it directly?
>>
>
> Please take it directly if everybody is happy with it.
>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
I don't like this at all. We're coming up with a bizarre ad-hoc hack
to work around the fact that we're allowing any unprivileged user can
call into firmware. Let's just require privilege. As I understand
it, Windows already requires privilege, and Windows is *right*.
Let's apply the original patch, not my patch. Then, if it causes
problems with sealtotp, either users can chmod the relevant file or we
can add a gross hack in the kernel to make that particular file 0644
*and print a warning* if the file exists. Then users can bug mjg to
fix sealtotp to use a privileged helper or systemd service or whatever
and rename the file at the same time.
But I read the sealtotp manual, and I don't see the point of using an
EFI var for sealtotp in the first place. sealtotp supports TPM NV
storage, EFI vars, and plain old files. I get why TPM NV makes
logical sense (sealtotp is a TPM thing), and using a plain old file
seems entirely reasonable. I don't see why anyone would prefer an EFI
variable.
--Andy
next prev parent reply other threads:[~2018-02-23 20:34 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-15 18:22 [PATCH 0/2] efivars: reading variables can generate SMIs Joe Konno
2018-02-15 18:22 ` [PATCH 1/2] fs/efivarfs: restrict inode permissions Joe Konno
2018-02-20 19:18 ` Andy Lutomirski
2018-02-20 21:18 ` Luck, Tony
2018-02-20 21:22 ` Matthew Garrett
2018-02-20 21:32 ` Luck, Tony
2018-02-20 21:35 ` Matthew Garrett
2018-02-20 22:01 ` Linus Torvalds
2018-02-20 23:30 ` Luck, Tony
2018-02-20 23:39 ` Matthew Garrett
2018-02-20 23:50 ` Luck, Tony
2018-02-21 0:49 ` Linus Torvalds
2018-02-21 1:05 ` Luck, Tony
2018-02-21 2:16 ` Linus Torvalds
2018-02-21 9:03 ` Ard Biesheuvel
2018-02-21 18:02 ` Linus Torvalds
2018-02-21 18:21 ` Andi Kleen
2018-02-21 19:47 ` Luck, Tony
2018-02-21 19:50 ` Linus Torvalds
2018-02-21 19:58 ` Luck, Tony
2018-02-21 20:40 ` Linus Torvalds
2018-02-22 1:45 ` [PATCH] efivarfs: Limit the rate for non-root to read files Luck, Tony
2018-02-22 1:58 ` Linus Torvalds
2018-02-22 5:34 ` Luck, Tony
2018-02-22 17:10 ` Eric W. Biederman
[not found] ` <CA+55aFy0hRexJkLbN7t31LjfGr4Ae0W5g6sBMqHHJi8aYuGKeA@mail.gmail.com>
[not found] ` <612E894E-62C8-4155-AED8-D53702EDC8DC@intel.com>
[not found] ` <CA+55aFxeBaTbwvbWqx1MKYjKKzLUs=1O43Bx2=JaO8qrnY-8HA@mail.gmail.com>
2018-02-22 17:15 ` [PATCH v2] " Luck, Tony
2018-02-22 17:39 ` Linus Torvalds
2018-02-22 17:54 ` Luck, Tony
2018-02-22 18:07 ` Linus Torvalds
2018-02-22 18:08 ` Ard Biesheuvel
2018-02-23 20:34 ` Andy Lutomirski [this message]
2018-02-23 19:47 ` [PATCH] " Peter Jones
2018-02-21 19:52 ` [PATCH 1/2] fs/efivarfs: restrict inode permissions Linus Torvalds
2018-02-24 20:06 ` Alan Cox
2018-02-25 10:56 ` Ard Biesheuvel
2018-02-21 0:49 ` Peter Jones
2018-02-20 23:19 ` Andy Lutomirski
2018-02-15 18:22 ` [PATCH 2/2] efi: restrict top-level attribute permissions Joe Konno
2018-02-16 10:41 ` [PATCH 0/2] efivars: reading variables can generate SMIs Ard Biesheuvel
2018-02-16 10:55 ` Borislav Petkov
2018-02-16 10:58 ` Ard Biesheuvel
2018-02-16 11:08 ` Borislav Petkov
2018-02-16 11:18 ` Ard Biesheuvel
2018-02-16 18:48 ` Joe Konno
2018-02-16 18:58 ` Borislav Petkov
2018-02-16 19:22 ` Peter Jones
2018-02-16 19:31 ` Ard Biesheuvel
2018-02-16 19:51 ` Matthew Garrett
2018-02-16 19:32 ` Luck, Tony
2018-02-16 19:54 ` Peter Jones
2018-02-16 20:51 ` James Bottomley
2018-02-16 21:09 ` Luck, Tony
2018-02-16 21:45 ` Andy Lutomirski
2018-02-16 21:58 ` Matthew Garrett
2018-02-16 22:02 ` Luck, Tony
2018-02-16 22:03 ` Matthew Garrett
2018-02-17 18:12 ` Andy Lutomirski
2018-02-16 22:05 ` Peter Jones
2018-02-17 9:36 ` Ard Biesheuvel
2018-02-17 16:17 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALCETrVrJWQNYcXFt4YQ-1EXFqMojiVTZhXR8zFoF+H0ZmfPjw@mail.gmail.com \
--to=luto@kernel.org \
--cc=ak@linux.intel.com \
--cc=ard.biesheuvel@linaro.org \
--cc=james.bottomley@hansenpartnership.com \
--cc=jk@ozlabs.org \
--cc=joe.konno@linux.intel.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@google.com \
--cc=pjones@redhat.com \
--cc=tony.luck@intel.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).