From: "Luck, Tony" <tony.luck@intel.com>
To: Matthew Garrett <mjg59@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
joe.konno@linux.intel.com, linux-efi <linux-efi@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
matthew.garrett@nebula.com, Jeremy Kerr <jk@ozlabs.org>,
ak@linux.intel.com, pjones@redhat.com, luto@kernel.org,
James Bottomley <james.bottomley@hansenpartnership.com>
Subject: Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
Date: Tue, 20 Feb 2018 13:32:47 -0800 [thread overview]
Message-ID: <20180220213246.43y2vbiiikqyx2ys@agluck-desk> (raw)
In-Reply-To: <CACdnJusL1Vj_rvhZY+0_KZkrk=fwnQcr1y+vxOBmUXa4xdHHsg@mail.gmail.com>
On Tue, Feb 20, 2018 at 09:22:29PM +0000, Matthew Garrett wrote:
> On Tue, Feb 20, 2018 at 1:18 PM Luck, Tony <tony.luck@intel.com> wrote:
>
> > Does this rate an exception to the "don't break userspace" for a security
> issue?
>
> To be clear, when you say "security" is this in reference to it being a
> denial of service, or are you worried about other interactions that may
> cause wider security issues?
The immediate problem is the denial of service attack. I have
a nagging worry that allowing a user to cause an SMI at a precise
time might also be a problem. But I don't know how that could be
leveraged in some other attack.
Making the efivar files 0600 would stop the user from causing the
SMIs. The rate limit solution could include a random delay to make
it tricky to use any attack that relies on an SMI during some specific
code sequence.
-Tony
next prev parent reply other threads:[~2018-02-20 21:32 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 [this message]
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
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=20180220213246.43y2vbiiikqyx2ys@agluck-desk \
--to=tony.luck@intel.com \
--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=luto@kernel.org \
--cc=matthew.garrett@nebula.com \
--cc=mjg59@google.com \
--cc=pjones@redhat.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).