On Wed, Dec 06, 2017 at 07:50:41AM +1100, Tobin C. Harding wrote:
> On Tue, Dec 05, 2017 at 11:13:43AM +0100, Greg Kroah-Hartman wrote:
> > Thanks to the scripts/leaking_addresses.pl script, it was found that
> > some EFI values should not be readable by non-root users.
> >
> > So make them
On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin wrote:
> > The series of patches introduce Security Version to EFI stub.
> >
> > Security Version is a monotonically increasing number and designed to
> > prevent the user from
On Tue, Dec 05, 2017 at 11:13:43AM +0100, Greg Kroah-Hartman wrote:
> Thanks to the scripts/leaking_addresses.pl script, it was found that
> some EFI values should not be readable by non-root users.
>
> So make them root-only, and to do that, add a __ATTR_RO_MODE() macro to
> make this easier,
On 5 December 2017 at 10:41, Greg Kroah-Hartman
wrote:
> Thanks to the scripts/leaking_addresses.pl script, it was found that
> some EFI values should not be readable by non-root users.
>
> So make them root-only, and to do that, add a __ATTR_RO_MODE() macro to
> make
On 29 October 2017 at 14:51, Pan Bian wrote:
> The remapping result of memremap should be freed with memunmap, not
> kfree.
>
> Signed-off-by: Pan Bian
> ---
> drivers/firmware/efi/esrt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
Thanks to the scripts/leaking_addresses.pl script, it was found that
some EFI values should not be readable by non-root users.
So make them root-only, and to do that, add a __ATTR_RO_MODE() macro to
make this easier, and use it in other places at the same time.
Reported-by: Linus Torvalds
On Tue, Dec 05, 2017 at 10:16:56AM +, Ard Biesheuvel wrote:
> On 5 December 2017 at 10:13, Greg Kroah-Hartman
> wrote:
> > Thanks to the scripts/leaking_addresses.pl script, it was found that
> > some EFI values should not be readable by non-root users.
> >
> > So
Hi!
> > Our ability to determine that userland hasn't been tampered with
> > depends on the kernel being trustworthy. If userland can upload
> > arbitrary firmware to DMA-capable devices then we can no longer trust
> > the kernel. So yes, firmware is special.
>
> You're ignoring the whole
On 5 December 2017 at 10:13, Greg Kroah-Hartman
wrote:
> Thanks to the scripts/leaking_addresses.pl script, it was found that
> some EFI values should not be readable by non-root users.
>
> So make them root-only, and to do that, add a __ATTR_RO_MODE() macro to
> make
On Tue, Dec 05, 2017 at 05:42:27PM +0800, Dave Young wrote:
> /sys/firmware/efi/systab shows several different values, it breaks sysfs
> one file one value design. But since there are already userspace tools
> depend on it eg. kexec-tools so add code comment to alert future expanding
> of this
On Tue, Dec 05, 2017 at 09:25:07AM +, Ard Biesheuvel wrote:
> On 5 December 2017 at 08:52, Greg Kroah-Hartman
> wrote:
> > On Tue, Dec 05, 2017 at 04:45:37PM +0800, Dave Young wrote:
> >> On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote:
> >> > On Tue, Dec 05, 2017
Thanks to the scripts/leaking_addresses.pl script, it was found that
some EFI values should not be readable by non-root users.
So make them root-only, and to do that, add a __ATTR_RO_MODE() macro to
make this easier, and use it in other places at the same time.
Reported-by: Linus Torvalds
On Tue, Dec 05, 2017 at 05:24:10PM +0800, Dave Young wrote:
> On 12/05/17 at 04:45pm, Dave Young wrote:
> > On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote:
> > > On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote:
> > > > On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote:
> > > > > On
This commit introduces Security Version for ARM64. As in x86, it
utilizes the resource section defined in the PE/COFF format(*) to locate
the struct of Security Version.
Similar to the debug table, the resource table is stored in .init.rodata
section while the struct of Security Version is in the
Security Version is a mechanism based on UEFI Secure Boot to keep the
user from loading an insecure kernel accidentally. It's a monotonically
increasing number representing how "secure" the kernel is. The distro
kernel maintainer has to specify the distro name (signer) and the distro
version to
The series of patches introduce Security Version to EFI stub.
Security Version is a monotonically increasing number and designed to
prevent the user from loading an insecure kernel accidentally. The
bootloader maintains a list of security versions corresponding to
different distributions. After
/sys/firmware/efi/systab shows several different values, it breaks sysfs
one file one value design. But since there are already userspace tools
depend on it eg. kexec-tools so add code comment to alert future expanding
of this file.
Signed-off-by: Dave Young
---
On 12/05/17 at 04:45pm, Dave Young wrote:
> On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote:
> > On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote:
> > > On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote:
> > > > On Mon, Dec 04, 2017 at 12:51:13PM +, David Laight wrote:
> > > > >
On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote:
> On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote:
> > On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote:
> > > On Mon, Dec 04, 2017 at 12:51:13PM +, David Laight wrote:
> > > > From: Ard Biesheuvel
> > > > > Sent: 04 December 2017
19 matches
Mail list logo