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
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 2
On Tue, 2015-04-21 at 18:58 -0700, Andy Lutomirski wrote:
> On Tue, Apr 21, 2015 at 6:21 PM, James Bottomley
> 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 if
>
On Tue, 2015-04-21 at 20:24 -0700, Andy Lutomirski wrote:
> On Tue, Apr 21, 2015 at 7:20 PM, James Bottomley
> wrote:
> > On Tue, 2015-04-21 at 18:58 -0700, Andy Lutomirski wrote:
> >> On Tue, Apr 21, 2015 at 6:21 PM, James Bottomley
> >> wrote:
> >> >
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
> > wrote:
> > > Andy, just on the misc device idea, what about triggering the capsule
> &
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
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:
> > >
On Wed, 2015-04-22 at 09:50 -0700, Andy Lutomirski wrote:
> On Apr 21, 2015 9:51 PM, "James Bottomley"
> wrote:
> >
> > On Tue, 2015-04-21 at 20:24 -0700, Andy Lutomirski wrote:
> > > On Tue, Apr 21, 2015 at 7:20 PM, James Bottomley
> > > wrote:
&
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 agree
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 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 Leon
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:
On Mon, 2015-04-27 at 14:59 -0700, Andy Lutomirski wrote:
> On Fri, Apr 24, 2015 at 8:16 AM, James Bottomley
> wrote:
> > On Fri, 2015-04-24 at 02:14 +, Kweh, Hock Leong wrote:
> >> > -Original Message-
> >> > From: James Bottomley [mailto:j
On Mon, 2015-04-27 at 15:40 -0700, Andy Lutomirski wrote:
> On Mon, Apr 27, 2015 at 3:35 PM, James Bottomley
> wrote:
> > On Mon, 2015-04-27 at 14:59 -0700, Andy Lutomirski wrote:
> >> On Fri, Apr 24, 2015 at 8:16 AM, James Bottomley
> >> wrote:
> >> &g
From: James Bottomley
The firmware class contains code to manage an arbitrary sized buffer for
discrete read and write operations. We need precisely this ability to update
firmware capsule files (and likely for other transactions as well), so split
out the capability into a library helper
[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
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 19
On Mon, 2015-06-08 at 22:15 +0200, Ard Biesheuvel wrote:
> On 8 June 2015 at 21:26, James Bottomley
> 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
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
> >
> > The firmware class contains code to manage an arbitrary sized buffer for
> > discrete read and write operations. We nee
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 EFI_PROPERTIES_TABLE en
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 08:16:46AM +0200, Ingo Molnar wrote:
> >>>
> >>>
On Wed, 2012-10-31 at 23:19 +0100, Oliver Neukum wrote:
> On Wednesday 31 October 2012 15:58:05 Chris Friesen wrote:
> > On 10/31/2012 02:14 PM, Oliver Neukum wrote:
>
> > > That would do it on my system.
> > > Maybe in theory you could solve this by the kernel invalidating images
> > > it hasn't
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
> > poin
On Thu, 2012-11-01 at 10:45 +0100, Jiri Kosina wrote:
> On Thu, 1 Nov 2012, James Bottomley wrote:
>
> > I'm actually just struggling to understand the use case for these more
> > esoteric protections.
>
> I believe the real point is drawing a clear line between t
On Thu, 2012-11-01 at 10:29 -0400, Eric Paris wrote:
> On Thu, Nov 1, 2012 at 5:59 AM, James Bottomley
> wrote:
>
> > But that doesn't really help me: untrusted root is an oxymoron.
>
> Imagine you run windows and you've never heard of Linux. You like
> tha
On Thu, 2012-11-01 at 14:49 +, Matthew Garrett wrote:
> On Thu, Nov 01, 2012 at 02:42:15PM +0000, James Bottomley wrote:
> > On Thu, 2012-11-01 at 10:29 -0400, Eric Paris wrote:
> > > Imagine you run windows and you've never heard of Linux. You like
> > > that
On Thu, 2012-11-01 at 10:59 -0400, Eric Paris wrote:
> On Thu, Nov 1, 2012 at 10:42 AM, James Bottomley
> wrote:
> > On Thu, 2012-11-01 at 10:29 -0400, Eric Paris wrote:
> >> On Thu, Nov 1, 2012 at 5:59 AM, James Bottomley
> >> wrote:
> >>
> >> &
On Thu, 2012-11-01 at 13:50 -0400, Eric Paris wrote:
> On Thu, Nov 1, 2012 at 11:18 AM, James Bottomley
> wrote:
>
> > You're completely confusing two separate goals:
> >
> > 1. Is it possible to use secure boot to implement a security policy
> >
On Thu, 2012-11-01 at 21:06 +, Matthew Garrett wrote:
> On Thu, Nov 01, 2012 at 09:03:20PM +0000, James Bottomley wrote:
> > On Thu, 2012-11-01 at 13:50 -0400, Eric Paris wrote:
> > > What do we have to do to prevent Linux being used to attack Linux
> > > which ma
On Fri, 2012-11-02 at 17:33 +0100, Pavel Machek wrote:
> On Thu 2012-11-01 15:02:25, Chris Friesen wrote:
> > On 11/01/2012 02:27 PM, Pavel Machek wrote:
> >
> > >Could someone write down exact requirements for Linux kernel to be signed
> > >by Microsoft?
> > >Because thats apparently what you wa
On Fri, 2012-11-02 at 16:54 +, Matthew Garrett wrote:
> On Fri, Nov 02, 2012 at 04:52:44PM +0000, James Bottomley wrote:
>
> > The first question is how many compromises do you need. Without
> > co-operation from windows, you don't get to install something in the
On Fri, 2012-11-02 at 17:54 +, Matthew Garrett wrote:
> On Fri, Nov 02, 2012 at 05:48:31PM +0000, James Bottomley wrote:
> > On Fri, 2012-11-02 at 16:54 +, Matthew Garrett wrote:
> > > On Fri, Nov 02, 2012 at 04:52:44PM +0000, James Bottomley wrote:
> > >
> &
On Fri, 2012-11-02 at 18:04 +, Matthew Garrett wrote:
> On Fri, Nov 02, 2012 at 05:57:38PM +0000, James Bottomley wrote:
> > On Fri, 2012-11-02 at 17:54 +, Matthew Garrett wrote:
> > > ? That's the message generated by the Windows access control mechanism
> >
On Sat, 2012-11-03 at 00:22 +, Matthew Garrett wrote:
> On Fri, Nov 02, 2012 at 11:38:23PM +0000, James Bottomley wrote:
> > On Fri, 2012-11-02 at 18:04 +, Matthew Garrett wrote:
> > > A user runs a binary that elevates itself to admin. Absent any flaws in
> >
On Sat, 2012-11-03 at 13:46 +, Matthew Garrett wrote:
> On Sat, Nov 03, 2012 at 12:03:56PM +0000, James Bottomley wrote:
> > On Sat, 2012-11-03 at 00:22 +, Matthew Garrett wrote:
> > > Why would an attacker use one of those Linux systems? There's going to
> &g
On Sun, 2012-11-04 at 04:28 +, Matthew Garrett wrote:
> On Sat, Nov 03, 2012 at 10:56:40PM +0000, James Bottomley wrote:
> > On Sat, 2012-11-03 at 13:46 +, Matthew Garrett wrote:
> > > I... what? Our signed bootloader will boot our signed kernel without any
> >
On Sun, 2012-11-04 at 13:52 +, Matthew Garrett wrote:
> On Sun, Nov 04, 2012 at 09:14:47AM +0000, 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 usi
[SCSI and USB lists added, message quoted in entirety]
On Sat, 2013-01-19 at 21:40 +, Ellwood Blues wrote:
> Hi.
>
> I've had this problem for so long that today after compiling kernel
> 3.7.3 and not getting any improvements I decided to let you know that
> some of us still only able to use o
On Tue, 2013-01-22 at 12:49 +0100, Oliver Neukum wrote:
> On Tuesday 22 January 2013 11:05:35 James Bottomley wrote:
> > > May 3 18:19:06 relampago3 kernel: [ 3948.472796] sd 7:0:0:0: [sdf]
> > > 1565565872 512-byte logical blocks: (801 GB/746 GiB)
> >
> > This
On Tue, 2013-01-22 at 11:05 -0600, H. Peter Anvin wrote:
> On 01/22/2013 09:43 AM, Alan Stern wrote:
> > On Tue, 22 Jan 2013, Oliver Neukum wrote:
> >
> >> On Tuesday 22 January 2013 11:05:35 James Bottomley wrote:
> >>>> May 3 18:19:06 relampago3
ed
efivars not efivarfs. Fix this by adding a module alias for efivarfs.
Signed-off-by: James Bottomley
---
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 +93,7 @@ MOD
On Thu, 2013-02-28 at 12:38 +0100, Tom Gundersen wrote:
> Hi James,
>
> On Thu, Feb 28, 2013 at 11:26 AM, James Bottomley
> wrote:
> > Currently you can't mount efivarfs unless the efivar module is already
> > inserted. This is contrary to the usual way in lin
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
From: James Bottomley
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 for
debugging and secure boot purposes.
The way this is done is to get the efi stub to pull all the NV+BS
(i.e
On Mon, 2013-03-18 at 11:49 +, Matt Fleming wrote:
> On Mon, 2013-03-18 at 08:01 +0000, James Bottomley wrote:
> > The crash is attached below. The curiosity is that the failing
> > "virtual" address is actually a physical address inside the EFI runtime.
On Tue, 2013-03-19 at 01:48 +, Matthew Garrett wrote:
> On Mon, Mar 18, 2013 at 08:40:14AM +0000, 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 st
On Tue, 2013-03-19 at 16:35 +, Matthew Garrett wrote:
> On Tue, Mar 19, 2013 at 08:14:45AM +0000, James Bottomley wrote:
>
> > Any security assumptions that rely on inability to read certain
> > information aren't really going to be that secure. Inability to modify,
On Tue, 2013-03-19 at 17:25 +, Matthew Garrett wrote:
> On Tue, Mar 19, 2013 at 05:17:27PM +0000, James Bottomley wrote:
> > On Tue, 2013-03-19 at 16:35 +, Matthew Garrett wrote:
> > > On Tue, Mar 19, 2013 at 08:14:45AM +0000, James Bottomley wrote:
> > >
>
On Tue, 2013-03-19 at 18:28 +, Matthew Garrett wrote:
> On Tue, Mar 19, 2013 at 06:23:31PM +0000, 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
> &g
On Tue, 2013-03-19 at 18:50 +, Matthew Garrett wrote:
> On Tue, Mar 19, 2013 at 06:40:56PM +0000, 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,
> > >
On Tue, 2013-03-19 at 23:17 +, Matthew Garrett wrote:
> On Tue, Mar 19, 2013 at 11:00:31PM +0000, James Bottomley wrote:
> > On Tue, 2013-03-19 at 18:50 +, Matthew Garrett wrote:
> > > Well, that somewhat complicates implementation - we'd be encrypting the
> >
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
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, entr
I really think the description is wrong. the problem isn't anything to
do with memset, it's because we're not getting a new allocation each
time we call efivar_create_sysfs_entries(). How about this?
---
Subject: [PATCH] efivar: fix oops in efivar_update_sysfs_entries() caused by
memory reuse
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 prob
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 (ge
On Mon, 2013-06-03 at 10:11 +0200, Borislav Petkov wrote:
> On Sun, Jun 02, 2013 at 11:56:20PM +0100, Matthew Garrett wrote:
> > I've just run Windows 8 under a hacked up copy of OVMF that dumps
> > the data passed to SetVirtualAddressMap. It seems that Windows *is*
> > mapping the runtime services
On Mon, 2013-06-03 at 15:30 +0100, Matthew Garrett wrote:
> On Mon, Jun 03, 2013 at 07:27:22AM -0700, James Bottomley wrote:
>
> > That's correct. I think not calling SetVirtualAddressMap() and just
> > using a 1:1 mapping is far safer (having looked at what
On Mon, 2013-06-03 at 16:21 +0100, Matthew Garrett wrote:
> On Mon, Jun 03, 2013 at 07:38:02AM -0700, James Bottomley wrote:
> > On Mon, 2013-06-03 at 15:30 +0100, Matthew Garrett wrote:
> > > Windows calls SetVirtualAddressMap(), so the only way these systems have
> &g
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
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
> > > b
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 s
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.
>
On Thu, 2013-06-20 at 10:44 +0100, Matthew Garrett wrote:
> On Thu, Jun 20, 2013 at 11:33:37AM +0200, Borislav Petkov wrote:
> > This will break the Macs so maybe we can do
> >
> > efi=no_11_map
> >
> > so the Macs can still boot but use the 1:1 map by default.
>
> I'm going to guess that there
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
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 pro
On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote:
> On Thu, Jun 27, 2013 at 2:32 AM, Matthew Garrett 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
> >>
On Thu, 2013-06-27 at 15:54 +0100, Grant Likely wrote:
> On Thu, Jun 27, 2013 at 7:33 AM, James Bottomley
> wrote:
> > On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote:
> >> On Thu, Jun 27, 2013 at 2:32 AM, Matthew Garrett
> >> wrote:
> >> > On We
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?
> > >
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 som
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()
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
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
On Tue, 2013-08-13 at 11:52 -0700, H. Peter Anvin wrote:
> On 08/13/2013 11:43 AM, James Bottomley wrote:
> > Can we actually boot a 32 bit kernel on an EFI64 system? The last time
> > I tried on my Secure Boot SDV it wouldn't work; the problem is getting
> > someting
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
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
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:
> > >
>
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
> &g
On Thu, 2013-08-29 at 08:18 -0400, Josh Boyer wrote:
> On Wed, Aug 28, 2013 at 10:26 PM, Greg KH 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 in EFI mode, al
On Sun, 2013-09-08 at 08:51 -0700, Kees Cook wrote:
> On Sun, Sep 8, 2013 at 12:24 AM, Greg KH 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 currently relying on
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
> &
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 i
On Mon, 2013-09-09 at 16:20 -0700, Kees Cook wrote:
> On Mon, Sep 9, 2013 at 4:19 PM, David Lang 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
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
On Thu, 2013-09-26 at 02:27 +0200, Pavel Machek wrote:
> On Wed 2013-09-25 15:16:54, James Bottomley wrote:
> > 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
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
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
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
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 loade
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
> > >
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 if you have a blacklist
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
> > > have been elsewhere.
On Tue, 2017-11-14 at 14:17 -0800, Matthew Garrett wrote:
> On Tue, Nov 14, 2017 at 2:14 PM, James Bottomley
> wrote:
> >
> > On Tue, 2017-11-14 at 15:55 -0500, Matthew Garrett wrote:
> > >
> > > TPM-backed Trusted Boot means you don't /need/ to sign
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 are
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 Wed, 2018-03-07 at 08:18 -0500, Mimi Zohar wrote:
> On Tue, 2018-03-06 at 15:05 +0100, Jiri Slaby wrote:
> > what's the status of this please? Distributors (I checked SUSE,
> > RedHat and Ubuntu) have to carry these patches and every of them
> > have to forward-port the patches to new kernels. S
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 a
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 messag
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 $HASH_RES
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
>
1 - 100 of 104 matches
Mail list logo
