Re: [PATCH] efi: move some sysfs files to be read-only by root

2017-12-05 Thread Greg Kroah-Hartman
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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

2017-12-05 Thread Gary Lin
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

Re: [PATCH] efi: move some sysfs files to be read-only by root

2017-12-05 Thread Tobin C. Harding
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,

Re: [PATCH v2] efi: move some sysfs files to be read-only by root

2017-12-05 Thread Ard Biesheuvel
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

Re: efi/esrt: use memunmap rather kfree to free the remapping

2017-12-05 Thread Ard Biesheuvel
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

[PATCH v2] efi: move some sysfs files to be read-only by root

2017-12-05 Thread Greg Kroah-Hartman
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

Re: [PATCH] efi: move some sysfs files to be read-only by root

2017-12-05 Thread Greg Kroah-Hartman
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

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

2017-12-05 Thread Pavel Machek
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

Re: [PATCH] efi: move some sysfs files to be read-only by root

2017-12-05 Thread Ard Biesheuvel
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

Re: [PATCH] efi: add comment to avoid future expanding of sysfs systab

2017-12-05 Thread Greg KH
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

Re: [GIT PULL] hash addresses printed with %p

2017-12-05 Thread Greg Kroah-Hartman
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

[PATCH] efi: move some sysfs files to be read-only by root

2017-12-05 Thread Greg Kroah-Hartman
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

Re: [GIT PULL] hash addresses printed with %p

2017-12-05 Thread Greg Kroah-Hartman
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

[RFC v3 PATCH 2/2] arm64/efi: Introduce Security Version to ARM64

2017-12-05 Thread Gary Lin
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

[RFC v3 PATCH 1/2] x86/efi: Introduce Security Version to x86

2017-12-05 Thread Gary Lin
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

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

2017-12-05 Thread Gary Lin
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

[PATCH] efi: add comment to avoid future expanding of sysfs systab

2017-12-05 Thread Dave Young
/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 ---

Re: [GIT PULL] hash addresses printed with %p

2017-12-05 Thread 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: > > > > >

Re: [GIT PULL] hash addresses printed with %p

2017-12-05 Thread Dave Young
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