Re: [PATCH] efi: expose TPM event log to userspace via sysfs

On Thu, 2024-04-25 at 15:36 +0200, Lennart Poettering wrote: > On Do, 25.04.24 14:47, Ilias Apalodimas (ilias.apalodi...@linaro.org) > wrote: > > > > Yeah, the physical address is of no interest to us. We just need > > > to > > > know the existance, and that independently of any actualy tpm > > >

Re: [PATCH] efi: expose TPM event log to userspace via sysfs

On Thu, 2024-04-25 at 11:58 +0200, Lennart Poettering wrote: [...] > General purpose distros typically don't build all TPM drivers into > the kernel, but ship some in the initrd instead. Then, udev is > responsible for iterating all buses/devices and auto-loading the > necessary drivers. Each

Re: [PATCH] efi: expose TPM event log to userspace via sysfs

On Mon, 2024-04-22 at 16:54 +0300, Ilias Apalodimas wrote: > Hi James > > On Mon, 22 Apr 2024 at 16:38, James Bottomley > wrote: > > > > On Mon, 2024-04-22 at 16:32 +0300, Ilias Apalodimas wrote: > > > Hi all, > > > > > > On Mon, 22

Re: [PATCH] efi: expose TPM event log to userspace via sysfs

On Mon, 2024-04-22 at 16:32 +0300, Ilias Apalodimas wrote: > Hi all, > > On Mon, 22 Apr 2024 at 16:08, Mikko Rapeli > wrote: > > > > Hi, > > > > On Mon, Apr 22, 2024 at 08:42:41AM -0400, James Bottomley wrote: > > > On Mon, 2024-04-22 at 14:27 +0300

Re: [PATCH 0/6][RFC] Add EFI secure key to key retention service

On Sun, 2018-08-05 at 09:25 +0200, Ard Biesheuvel wrote: > Hello Chun,yi, > > On 5 August 2018 at 05:21, Lee, Chun-Yi > wrote: > > When secure boot is enabled, only signed EFI binary can access > > EFI boot service variable before ExitBootService. Which means that > > the EFI boot service

Re: [PATCH v2] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

On Tue, 2018-04-03 at 18:07 +0200, Daniel Kiper wrote: > On Tue, Apr 03, 2018 at 08:44:41AM -0700, James Bottomley wrote: > > > > On Tue, 2018-04-03 at 16:39 +0200, Daniel Kiper wrote: > > > > > > Initialize UEFI secure boot state during dom0 boot. Otherwise t

Re: [PATCH 4/5] MODSIGN: checking the blacklisted hash before loading a kernel module

On Thu, 2018-03-15 at 14:16 +0800, joeyli wrote: > On Wed, Mar 14, 2018 at 07:19:25AM -0700, James Bottomley wrote: > > > > On Wed, 2018-03-14 at 14:08 +0800, joeyli wrote: > > > > > > On Tue, Mar 13, 2018 at 10:18:35AM -0700, James Bottomley wrote: > > &

Re: [PATCH 4/5] MODSIGN: checking the blacklisted hash before loading a kernel module

On Wed, 2018-03-14 at 14:08 +0800, joeyli wrote: > On Tue, Mar 13, 2018 at 10:18:35AM -0700, James Bottomley wrote: > > > > On Tue, 2018-03-13 at 18:38 +0800, Lee, Chun-Yi wrote: > > > > > > This patch adds the logic for checking the kernel module's hash >

Re: [PATCH 4/5] MODSIGN: checking the blacklisted hash before loading a kernel module

On Tue, 2018-03-13 at 18:38 +0800, Lee, Chun-Yi wrote: > This patch adds the logic for checking the kernel module's hash > base on blacklist. The hash must be generated by sha256 and enrolled > to dbx/mokx. > > For example: > sha256sum sample.ko > mokutil --mokx --import-hash

Re: [PATCH 2/5] MODSIGN: print appropriate status message when getting UEFI certificates list

On Tue, 2018-03-13 at 18:35 +0800, Lee, Chun-Yi wrote: > When getting certificates list from UEFI variable, the original error > message shows the state number from UEFI firmware. It's hard to be > read by human. This patch changed the error message to show the > appropriate string. > > The

Re: Regression from efi: call get_event_log before ExitBootServices

On Fri, 2018-03-09 at 10:29 +0100, Hans de Goede wrote: > Hi, > > On 08-03-18 18:26, Jeremy Cline wrote: > > > > On 03/08/2018 11:50 AM, Hans de Goede wrote: [...] > > > > The UEFI firmware does some measurements and so does shim. So > > > > you should have some event logs. What version of shim

Re: [PATCH 0/2] efivars: reading variables can generate SMIs

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

Re: [PATCH 1/4] MODSIGN: do not load mok when secure boot disabled

On Wed, 2017-11-29 at 22:11 +0800, Lee, Chun-Yi wrote: > The mok can not be trusted when the secure boot is disabled. Which > means that the kernel embedded certificate is the only trusted key. > > Due to db/dbx are authenticated variables, they needs manufacturer's > KEK for update. So db/dbx

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

On Tue, 2017-11-14 at 14:17 -0800, Matthew Garrett wrote: > On Tue, Nov 14, 2017 at 2:14 PM, James Bottomley > <james.bottom...@hansenpartnership.com> wrote: > > > > On Tue, 2017-11-14 at 15:55 -0500, Matthew Garrett wrote: > > > > > > TPM-backed T

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

On Tue, 2017-11-14 at 15:55 -0500, Matthew Garrett wrote: > On Tue, Nov 14, 2017 at 3:50 PM, Luis R. Rodriguez > wrote: > > > > On Tue, Nov 14, 2017 at 12:18:54PM -0800, Linus Torvalds wrote: > > > > > > This is all theoretical security masturbation. The _real_ attacks > > >

Problem with new X.509 is_hash_blacklisted() interface

Added by commit 436529562df2748fd9918f578205b22cf8ced277 Author: David Howells Date: Mon Apr 3 16:07:25 2017 +0100 X.509: Allow X.509 certs to be blacklisted Ironically it duplicates a UEFI bug we've been struggling with for a while in the pkcs11 handlers: namely

Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime

On Wed, 2015-09-30 at 09:43 -0700, Andy Lutomirski wrote: > On Wed, Sep 30, 2015 at 2:30 AM, Ard Biesheuvel > wrote: > > On 29 September 2015 at 23:58, Laszlo Ersek wrote: > >> On 09/28/15 08:41, Matthew Garrett wrote: > >>> On Mon, Sep 28, 2015 at

Re: [PATCH] x86/efi: Map EFI memmap entries in-order at runtime

On Wed, 2015-09-16 at 13:25 +0200, Ard Biesheuvel wrote: > On 16 September 2015 at 12:08, Borislav Petkov wrote: > > On Wed, Sep 09, 2015 at 12:21:23PM +0100, Matt Fleming wrote: > >> On Wed, 09 Sep, at 08:33:07AM, joeyli wrote: > >> > > >> > Yes, the machine on my hand has

Re: [RFC 2/3] firmware_class: split out transaction helpers

On Thu, 2015-08-27 at 15:47 +0100, Matt Fleming wrote: On Wed, 29 Apr, at 04:10:52PM, James Bottomley wrote: From: James Bottomley jbottom...@odin.com The firmware class contains code to manage an arbitrary sized buffer for discrete read and write operations. We need precisely

Re: [PATCH] efi: rtc-efi: use correct EFI 'epoch'

On Mon, 2015-06-08 at 13:27 +0200, Ard Biesheuvel wrote: The rtc-efi driver declares that the EFI 'epoch' is 1/1/1998, but the UEFI spec does not define it at all. It does define a minimum of 1900 for the 'Year' member of the EFI_TIME struct, so let's use 1900 as the minimum year and not 1998.

Re: [PATCH] efi: rtc-efi: use correct EFI 'epoch'

On Mon, 2015-06-08 at 22:15 +0200, Ard Biesheuvel wrote: On 8 June 2015 at 21:26, James Bottomley james.bottom...@hansenpartnership.com wrote: On Mon, 2015-06-08 at 13:27 +0200, Ard Biesheuvel wrote: The rtc-efi driver declares that the EFI 'epoch' is 1/1/1998, but the UEFI spec does

Re: Capsule patches

[adding linux-efi because that's where the experts hang out] On Mon, 2015-05-25 at 16:14 +0530, parmeshwr_pra...@dell.com wrote: Hi James, I am from dell. I was working on Capsule feature. I got some patches from you which supports user space interface for capsule. I have applied those

Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware

On Mon, 2015-04-27 at 14:59 -0700, Andy Lutomirski wrote: On Fri, Apr 24, 2015 at 8:16 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Fri, 2015-04-24 at 02:14 +, Kweh, Hock Leong wrote: -Original Message- From: James Bottomley [mailto:james.bottom

Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware

On Mon, 2015-04-27 at 15:40 -0700, Andy Lutomirski wrote: On Mon, Apr 27, 2015 at 3:35 PM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Mon, 2015-04-27 at 14:59 -0700, Andy Lutomirski wrote: On Fri, Apr 24, 2015 at 8:16 AM, James Bottomley james.bottom

Re: [PATCH] x86/efi: fix potential NULL pointer dereference

On Fri, 2015-04-24 at 14:07 +0800, Firo Yang wrote: In this patch, I add error-handing code for kmalloc() in arch/x86/platform/efi/efi_64.c::efi_call_phys_prolog(). If kmalloc() failed to alloc memroy, save_pgd will be a NULL pointer dereferenced by subsequent codes. Signed-off-by: Firo

Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware

On Fri, 2015-04-24 at 02:14 +, Kweh, Hock Leong wrote: -Original Message- From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] Sent: Thursday, April 23, 2015 10:10 PM On Thu, 2015-04-23 at 08:30 +, Kweh, Hock Leong wrote: -Original Message

Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware

On Thu, 2015-04-23 at 11:50 +0200, Greg Kroah-Hartman wrote: On Wed, Apr 22, 2015 at 09:11:17AM -0700, James Bottomley wrote: On Wed, 2015-04-22 at 17:46 +0200, Greg Kroah-Hartman wrote: On Wed, Apr 22, 2015 at 08:35:54AM -0700, James Bottomley wrote: On Wed, 2015-04-15 at 15:19 +0200

Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware

On Thu, 2015-04-23 at 08:30 +, Kweh, Hock Leong wrote: -Original Message- From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] Sent: Wednesday, April 22, 2015 11:19 PM Yes, I think we've all agreed we can do it ... it's now a question of whether we

Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware

On Wed, 2015-04-22 at 17:46 +0200, Greg Kroah-Hartman wrote: On Wed, Apr 22, 2015 at 08:35:54AM -0700, James Bottomley wrote: On Wed, 2015-04-15 at 15:19 +0200, Greg Kroah-Hartman wrote: On Wed, Apr 15, 2015 at 11:32:29AM +, Kweh, Hock Leong wrote: -Original Message

Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware

On Wed, 2015-04-22 at 09:27 -0400, Peter Jones wrote: On Tue, Apr 21, 2015 at 06:58:58PM -0700, Andy Lutomirski wrote: On Tue, Apr 21, 2015 at 6:21 PM, James Bottomley james.bottom...@hansenpartnership.com wrote: Andy, just on the misc device idea, what about triggering the capsule

Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware

On Wed, 2015-04-15 at 15:19 +0200, Greg Kroah-Hartman wrote: On Wed, Apr 15, 2015 at 11:32:29AM +, Kweh, Hock Leong wrote: -Original Message- From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] Sent: Tuesday, April 14, 2015 10:09 PM On Tue, Apr 14, 2015 at

Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware

On Tue, 2015-04-21 at 09:56 +0200, Greg Kroah-Hartman wrote: On Tue, Apr 21, 2015 at 03:23:55AM +, Kweh, Hock Leong wrote: -Original Message- From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] Sent: Monday, April 20, 2015 10:43 PM On Mon, Apr 20, 2015 at

Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware

On Tue, 2015-04-21 at 18:58 -0700, Andy Lutomirski wrote: On Tue, Apr 21, 2015 at 6:21 PM, James Bottomley james.bottom...@hansenpartnership.com wrote: Andy, just on the misc device idea, what about triggering the capsule update from close()? In theory close returns an error code (not sure

Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware

On Tue, 2015-04-21 at 20:24 -0700, Andy Lutomirski wrote: On Tue, Apr 21, 2015 at 7:20 PM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Tue, 2015-04-21 at 18:58 -0700, Andy Lutomirski wrote: On Tue, Apr 21, 2015 at 6:21 PM, James Bottomley james.bottom

Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware

On Fri, 2015-04-17 at 15:49 +0200, Greg Kroah-Hartman wrote: On Thu, Apr 16, 2015 at 09:42:31AM +, Kweh, Hock Leong wrote: -Original Message- From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] Sent: Wednesday, April 15, 2015 9:19 PM On Wed, Apr 15, 2015 at

Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot

On Thu, 2013-09-26 at 08:24 +0200, Jiri Kosina wrote: On Wed, 25 Sep 2013, James Bottomley wrote: I don't get this. Why is it important that current kernel can't recreate the signature? The thread model is an attack on the saved information (i.e. the suspend image) between it being

Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot

On Wed, 2013-09-25 at 17:25 -0400, Alan Stern wrote: On Wed, 25 Sep 2013, David Howells wrote: I have pushed some keyrings patches that will likely affect this to: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel I intend to ask James to

Re: [PATCH 00/12] One more attempt at useful kernel lockdown

On Mon, 2013-09-09 at 16:20 -0700, Kees Cook wrote: On Mon, Sep 9, 2013 at 4:19 PM, David Lang da...@lang.hm wrote: On Mon, 9 Sep 2013, Matthew Garrett wrote: On Mon, 2013-09-09 at 11:25 -0700, David Lang wrote: 1 lock down modules 2 lock down kexec Having thought about this,

Re: [PATCH V3 08/11] kexec: Disable at runtime if the kernel enforces module loading restrictions

On Sun, 2013-09-08 at 08:51 -0700, Kees Cook wrote: On Sun, Sep 8, 2013 at 12:24 AM, Greg KH gre...@linuxfoundation.org wrote: On Sun, Sep 08, 2013 at 06:44:08AM +, Matthew Garrett wrote: On Sat, 2013-09-07 at 23:40 -0700, Greg KH wrote: If you apply this, you break everyone who is

Re: [PATCH V3 08/11] kexec: Disable at runtime if the kernel enforces module loading restrictions

On Sun, 2013-09-08 at 17:15 +, Matthew Garrett wrote: On Sun, 2013-09-08 at 10:11 -0700, James Bottomley wrote: That's not true if you look at the use cases. Distros use signed modules to taint the kernel: insert an unsigned one and the kernel taints; insert a properly signed one

Re: [PATCH V3 08/11] kexec: Disable at runtime if the kernel enforces module loading restrictions

On Sun, 2013-09-08 at 17:27 +, Matthew Garrett wrote: It's an argument that CAP_SYS_BOOT is too powerful yes, but if you recall, I said I keep that one. In the rather lame analogy, what I do by giving away CAP_SYS_MODULE and enforcing module signing while keeping CAP_SYS_BOOT is allow

Re: EFI mode after running kexec

On Thu, 2013-08-29 at 08:18 -0400, Josh Boyer wrote: On Wed, Aug 28, 2013 at 10:26 PM, Greg KH gre...@linuxfoundation.org wrote: Hi all, I've been messing with UEFI booting a kernel and then later on, using kexec to boot another kernel, and noticed that the kexec'ed kernel is not really

Re: UEFI Plugfest 2013 -- New Orleans

On Mon, 2013-08-19 at 13:55 +0100, Matthew Garrett wrote: On Mon, Aug 19, 2013 at 09:25:35AM +0100, David Woodhouse wrote: Every deviation from the spec (or common sense), however minor, should show up as a clear failure. Even the ones we *have* been able to work around, because we still

Re: UEFI Plugfest 2013 -- New Orleans

On Mon, 2013-08-19 at 17:00 +0100, Matthew Garrett wrote: On Mon, Aug 19, 2013 at 08:22:45AM -0700, James Bottomley wrote: On Mon, 2013-08-19 at 13:55 +0100, Matthew Garrett wrote: On Mon, Aug 19, 2013 at 09:25:35AM +0100, David Woodhouse wrote: Every deviation from the spec

Re: UEFI Plugfest 2013 -- New Orleans

On Mon, 2013-08-19 at 18:21 +0100, Matthew Garrett wrote: On Mon, Aug 19, 2013 at 10:02:55AM -0700, James Bottomley wrote: The object of having a test suite conform to the spec is not to perpetuate the cockups that occurred in round one of the implementation and to force everyone to pay

Re: UEFI Plugfest 2013 -- New Orleans

On Fri, 2013-08-16 at 11:20 -0400, John W. Linville wrote: Participants in this event must join the UEFI at the Adopter level or above (gratis): http://www.uefi.org/join Just a note on doing this. I did it today using the three page form on the uefi web page: you can fill it in on

Re: RFC: default CONFIG_EFI_STUB=y

On Tue, 2013-08-13 at 11:30 -0700, H. Peter Anvin wrote: On 08/09/2013 08:38 AM, H. Peter Anvin wrote: On 08/09/2013 08:32 AM, James Bottomley wrote: On Fri, 2013-08-09 at 08:23 -0700, H. Peter Anvin wrote: I would like to change the defaults for CONFIG_EFI and CONFIG_EFI_STUB to y

Re: RFC: default CONFIG_EFI_STUB=y

On Fri, 2013-08-09 at 08:23 -0700, H. Peter Anvin wrote: I would like to change the defaults for CONFIG_EFI and CONFIG_EFI_STUB to y. There is little reason to omit this since EFI now is a significant percentage of all systems. You didn't actually attach the patch, but I presume this is for

Re: [edk2] Corrupted EFI region

On Mon, 2013-08-05 at 17:15 +0200, Laszlo Ersek wrote: On 08/05/13 16:40, Borislav Petkov wrote: On Mon, Aug 05, 2013 at 04:27:44PM +0200, Laszlo Ersek wrote: I wouldn't call the design of SetVirtualAddressMap() braindead. Ok, I've always wondered and you could probably shed some light

Re: [edk2] Corrupted EFI region

On Mon, 2013-08-05 at 23:55 +0200, Laszlo Ersek wrote: On 08/05/13 23:41, Borislav Petkov wrote: On Mon, Aug 05, 2013 at 02:37:08PM -0700, H. Peter Anvin wrote: All of this would be a non-problem if there weren't buggy implementations which can't run *without* SetVirtualAddressMap().

Re: [PATCH 1/4] Documentation: arm: [U]EFI runtime services

On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote: On Thu, Jun 27, 2013 at 2:32 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Wed, Jun 26, 2013 at 07:38:19AM -0700, James Bottomley wrote: The fixed virtual address scheme currently being looked at for x86_64 to make

Re: [PATCH 1/4] Documentation: arm: [U]EFI runtime services

On Thu, 2013-06-27 at 15:54 +0100, Grant Likely wrote: On Thu, Jun 27, 2013 at 7:33 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote: On Thu, Jun 27, 2013 at 2:32 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Wed

Re: [PATCH 1/4] Documentation: arm: [U]EFI runtime services

On Thu, 2013-06-27 at 15:37 +0100, Matthew Garrett wrote: On Wed, Jun 26, 2013 at 11:33:41PM -0700, James Bottomley wrote: On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote: What is the problem trying to be avoided by not using the virtual map? Is it passing the virtual mapping data

Re: [PATCH 1/4] Documentation: arm: [U]EFI runtime services

On Wed, 2013-06-26 at 14:59 +0100, Matt Fleming wrote: On Wed, 26 Jun, at 03:53:11PM, Leif Lindholm wrote: It's completely feasible, but we'd need to use a different method to do the boot services call with a 1:1 mapping (idmap support is not available until much later in the boot process).

Re: [PATCH -v2 0/4] EFI 1:1 mapping

On Thu, 2013-06-20 at 17:29 +0100, Matthew Garrett wrote: On Thu, Jun 20, 2013 at 07:53:39AM -0700, James Bottomley wrote: Can't we detect Macs from some of the UEFI strings at boot time and do the right thing with the boot switch (which can be overriden from the kernel command line if we

Re: [PATCH -v2 0/4] EFI 1:1 mapping

On Wed, 2013-06-19 at 18:38 +0200, Borislav Petkov wrote: On Wed, Jun 19, 2013 at 05:21:15PM +0100, Matthew Garrett wrote: Yes, kexec needs a different solution. No need. If we say, efi=use_11_map, the 1:1 map will be shoved down SetVirtualAddressMap. Otherwise the high mappings.

Re: [PATCH 0/4] EFI 1:1 mapping

On Mon, 2013-06-03 at 17:24 +0100, Matthew Garrett wrote: On Mon, Jun 03, 2013 at 09:18:06AM -0700, James Bottomley wrote: I don't entirely buy that. All EFI programs run with the physical address map, therefore every API an EFI program uses is also tested, at boot time only, obviously

Re: [PATCH 0/4] EFI 1:1 mapping

On Mon, 2013-06-03 at 17:42 +0100, Matthew Garrett wrote: On Mon, Jun 03, 2013 at 09:35:07AM -0700, James Bottomley wrote: On Mon, 2013-06-03 at 17:24 +0100, Matthew Garrett wrote: That seems optimistic. Windows never calls QueryVariableInfo() during boot services, so what makes you

Re: [PATCH 0/4] EFI 1:1 mapping

On Mon, 2013-06-03 at 19:11 +0100, Matthew Garrett wrote: The problem there is that you're saying In theory. We know that Windows doesn't behave this way, so we have no legitimate expectation that it'll work. We know that it doesn't on some Apple hardware. Fine, you say we need to

Re: [regression, bisected] x86: efi: Pass boot services variable info to runtime code

On Fri, 2013-05-31 at 15:34 +0100, Matthew Garrett wrote: On Fri, May 31, 2013 at 02:43:56PM +0200, Ingo Molnar wrote: 4) The revert is easy, and the functionality the original patch provided was a marginal increase in debug output to begin with... I agree that a revert is probably

Re: [regression, bisected] x86: efi: Pass boot services variable info to runtime code

On Fri, 2013-05-31 at 17:28 +0100, Matthew Garrett wrote: On Fri, May 31, 2013 at 10:43:49AM -0500, Russ Anderson wrote: When did writing EFI variables to nvram become necessary to boot on UEFI? And if it is necessary, why is it that only linux boot loaders that use EFI stubs (generally

Re: [PATCH]Move kzalloc() just before memset() to avoid initializing new sysfs entries wrongly

On Fri, 2013-05-10 at 18:46 +, Seiji Aguchi wrote: When sysfs entries are updated by updated_sysfs_entries(), they are mistakenly initialized by memset(). Then, it causes following oops. ---[ end trace ba4907d5c519d111 ]--- BUG: unable to handle kernel NULL pointer dereference at

Re: [PATCH]Move kzalloc() just before memset() to avoid initializing new sysfs entries wrongly

On Fri, 2013-05-10 at 19:10 +, Seiji Aguchi wrote: This is manifestly wrong: it would leak memory as it circulates around the loop. I don't think the memory leak happens. As you can see below, if a new entry is not created, kfree() is called outside while(1). Ah, I see, entry is

Re: [PATCH] x86/efi: pull NV+BS variables out before we exit boot services

On Tue, 2013-03-19 at 23:17 +, Matthew Garrett wrote: On Tue, Mar 19, 2013 at 11:00:31PM +, James Bottomley wrote: On Tue, 2013-03-19 at 18:50 +, Matthew Garrett wrote: Well, that somewhat complicates implementation - we'd be encrypting the entire contents of memory except

Re: [PATCH] x86/efi: pull NV+BS variables out before we exit boot services

On Tue, 2013-03-19 at 01:48 +, Matthew Garrett wrote: On Mon, Mar 18, 2013 at 08:40:14AM +, James Bottomley wrote: The object here is to make the NV+BS variables accessible (at least read only) at runtime so we can get a full picture of the state of the EFI variables

Re: [PATCH] x86/efi: pull NV+BS variables out before we exit boot services

On Tue, 2013-03-19 at 17:25 +, Matthew Garrett wrote: On Tue, Mar 19, 2013 at 05:17:27PM +, James Bottomley wrote: On Tue, 2013-03-19 at 16:35 +, Matthew Garrett wrote: On Tue, Mar 19, 2013 at 08:14:45AM +, James Bottomley wrote: Any security assumptions that rely

Re: [PATCH] x86/efi: pull NV+BS variables out before we exit boot services

On Tue, 2013-03-19 at 18:28 +, Matthew Garrett wrote: On Tue, Mar 19, 2013 at 06:23:31PM +, James Bottomley wrote: The scheme we discussed, unless something radically changed, was to convey a temporary key pair via a mechanism to later verify the hybernate kernel on a resume

Re: [PATCH] x86/efi: pull NV+BS variables out before we exit boot services

On Tue, 2013-03-19 at 18:50 +, Matthew Garrett wrote: On Tue, Mar 19, 2013 at 06:40:56PM +, James Bottomley wrote: On Tue, 2013-03-19 at 18:28 +, Matthew Garrett wrote: It requires the key to survive the system being entirely powered down, which means it needs to be BS+NV

Curious crash with secure variables

The crash is attached below. The curiosity is that the failing virtual address is actually a physical address inside the EFI runtime. It looks like either SetVirtualAddressMap() failed to relocate something, or there are caching effects on pre-relocated addresses. The way to trigger this is to

[PATCH] efivars: Make efivarfs autoloading on mount request

not efivarfs. Fix this by adding a module alias for efivarfs. Signed-off-by: James Bottomley jbottom...@parallels.com --- diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c index f5596db..62386a0 100644 --- a/drivers/firmware/efivars.c +++ b/drivers/firmware/efivars.c @@ -93,6

Re: [RFC] Second attempt at kernel secure boot support

On Sun, 2012-11-04 at 13:52 +, Matthew Garrett wrote: On Sun, Nov 04, 2012 at 09:14:47AM +, James Bottomley wrote: I've actually had more than enough experience with automated installs over my career: they're either done by paying someone or using a provisioning system. In either

Re: [RFC] Second attempt at kernel secure boot support

On Thu, 2012-11-01 at 10:20 +0100, Jiri Kosina wrote: On Thu, 1 Nov 2012, James Bottomley wrote: The point I'm making is that given that the majority of exploits will already be able to execute arbitrary code in-kernel, there's not much point trying to consider features like

Re: [RFC] Second attempt at kernel secure boot support

On Thu, 2012-11-01 at 13:50 -0400, Eric Paris wrote: On Thu, Nov 1, 2012 at 11:18 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: You're completely confusing two separate goals: 1. Is it possible to use secure boot to implement a security policy on Linux