On Fri, Feb 16, 2018 at 10:03 PM, Matthew Garrett wrote:
> On Fri, Feb 16, 2018 at 2:02 PM Luck, Tony wrote:
>
>> > If the default is 600 then it makes sense to allow a privileged service
> to
>> > selectively make certain variables world readable at runtime.
>
>> As soon as you make one variable
> 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
On 16 February 2018 at 22:05, Peter Jones wrote:
> On Fri, Feb 16, 2018 at 09:09:30PM +, 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 b
On Fri, Feb 16, 2018 at 09:09:30PM +, 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 wantin
On Fri, Feb 16, 2018 at 2:02 PM Luck, Tony wrote:
> > If the default is 600 then it makes sense to allow a privileged service
to
> > selectively make certain variables world readable at runtime.
> As soon as you make one variable world readable you are vulnerable to
> a local user launching a Do
> If the default is 600 then it makes sense to allow a privileged service to
> selectively make certain variables world readable at runtime.
As soon as you make one variable world readable you are vulnerable to
a local user launching a DoS attack by reading that variable over and over
generating a
On Fri, Feb 16, 2018 at 1:45 PM Andy Lutomirski wrote:
> I'm going to go out on a limb and suggest that the fact that
> unprivileged users can read efi variables at all is a mistake
> regardless of SMI issues.
Why? They should never contain sensitive material.
> Also, chmod() just shouldn't work
On Fri, Feb 16, 2018 at 9:09 PM, 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 t
> 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.
Anot
On Fri, 2018-02-16 at 10:41 +, Ard Biesheuvel wrote:
> On 15 February 2018 at 18:22, Joe Konno
> wrote:
> >
> > From: Joe Konno
> >
> > It was pointed out that normal, unprivileged users reading certain
> > EFI
> > variables (through efivarfs) can generate SMIs. Given these nodes
> > are cr
On Fri, Feb 16, 2018 at 07:32:17PM +, Luck, Tony wrote:
> > tl;dr: I think changing everything to 0600 is probably completely fine,
> > and whitelisting is probably pointless.
>
> But do you speak for all users?
No, I just write their tools :)
> It will just take one person complaining tha
On Fri, Feb 16, 2018 at 11:31 AM Ard Biesheuvel
wrote:
> This is why I was leaning towards applying these patches: not breaking
> userland is an important rule, but it does not imply every aspect of
> behavior observable by userland is set in stone. In other words, I
> agree with Peter that making
On 16 February 2018 at 19:22, Peter Jones wrote:
> On Fri, Feb 16, 2018 at 10:48:32AM -0800, Joe Konno wrote:
>> On Fri, Feb 16, 2018 at 11:18:12AM +, Ard Biesheuvel wrote:
>> > On 16 February 2018 at 11:08, Borislav Petkov wrote:
>> > > On Fri, Feb 16, 2018 at 10:58:47AM +, Ard Biesheuve
> tl;dr: I think changing everything to 0600 is probably completely fine,
> and whitelisting is probably pointless.
But do you speak for all users? It will just take one person complaining
that efibootmgr no longer shows them what it used to show to bring down
the wrath of Linus on our (specific
On Fri, Feb 16, 2018 at 10:48:32AM -0800, Joe Konno wrote:
> On Fri, Feb 16, 2018 at 11:18:12AM +, Ard Biesheuvel wrote:
> > On 16 February 2018 at 11:08, Borislav Petkov wrote:
> > > On Fri, Feb 16, 2018 at 10:58:47AM +, Ard Biesheuvel wrote:
> > >> By your own reasoning above, that's a n
On Fri, Feb 16, 2018 at 10:48:32AM -0800, Joe Konno wrote:
> We may see some other patches or RFCs about caching and/or shadowing
> variable values in efivarfs to reduce the number of direct EFI reads,
> with the goal of reducing how many SMIs are generated.
So if you do the caching scheme, the q
On Fri, Feb 16, 2018 at 11:18:12AM +, Ard Biesheuvel wrote:
> On 16 February 2018 at 11:08, Borislav Petkov wrote:
> > On Fri, Feb 16, 2018 at 10:58:47AM +, Ard Biesheuvel wrote:
> >> By your own reasoning above, that's a no-no as well.
> >
> > I'm sure we can come up with some emulation -
On 16 February 2018 at 11:08, Borislav Petkov wrote:
> On Fri, Feb 16, 2018 at 10:58:47AM +, Ard Biesheuvel wrote:
>> By your own reasoning above, that's a no-no as well.
>
> I'm sure we can come up with some emulation - the same way we did the
> BIOS emulation.
>
>> But thanks for your input.
On Fri, Feb 16, 2018 at 10:58:47AM +, Ard Biesheuvel wrote:
> By your own reasoning above, that's a no-no as well.
I'm sure we can come up with some emulation - the same way we did the
BIOS emulation.
> But thanks for your input. Anyone else got something constructive to
> contribute?
The n
On 16 February 2018 at 10:55, Borislav Petkov wrote:
> On Fri, Feb 16, 2018 at 10:41:45AM +, Ard Biesheuvel wrote:
>> On 15 February 2018 at 18:22, Joe Konno wrote:
>> > From: Joe Konno
>> >
>> > It was pointed out that normal, unprivileged users reading certain EFI
>> > variables (through e
On Fri, Feb 16, 2018 at 10:41:45AM +, Ard Biesheuvel wrote:
> On 15 February 2018 at 18:22, Joe Konno wrote:
> > From: Joe Konno
> >
> > It was pointed out that normal, unprivileged users reading certain EFI
> > variables (through efivarfs) can generate SMIs. Given these nodes are
> > create
On 15 February 2018 at 18:22, Joe Konno wrote:
> From: Joe Konno
>
> It was pointed out that normal, unprivileged users reading certain EFI
> variables (through efivarfs) can generate SMIs. Given these nodes are created
> with 0644 permissions, normal users could generate a lot of SMIs. By
> rest
From: Joe Konno
It was pointed out that normal, unprivileged users reading certain EFI
variables (through efivarfs) can generate SMIs. Given these nodes are created
with 0644 permissions, normal users could generate a lot of SMIs. By
restricting permissions a bit (patch 1), we can make it harder
23 matches
Mail list logo
