On Tue, Jun 30, 2020 at 02:23:22PM -0500, Tyler Hicks wrote:
> > > I am all for stringent checks, but this could potentially break
> > > measured boot on systems that are working fine today, right?
> >
> > Seems like in that case our measurement is unreliable and can't really
> > be trusted. That
On Tue, Jun 16, 2020 at 11:08:38AM +0200, Ard Biesheuvel wrote:
> (cc Matthew and Peter)
>
> On Tue, 16 Jun 2020 at 01:28, Tyler Hicks wrote:
> >
> > Require that the TCG_PCR_EVENT2.digests.count value strictly matches the
> > value of TCG_EfiSpecIdEvent.numberOfAlgorithms in the event field of t
The following commit has been merged into the efi/urgent branch of tip:
Commit-ID: 435d1a471598752446a72ad1201b3c980526d869
Gitweb:
https://git.kernel.org/tip/435d1a471598752446a72ad1201b3c980526d869
Author:Peter Jones
AuthorDate:Mon, 15 Jun 2020 16:24:08 -04:00
Committer
.
This patch adds CONFIG_EFI_CUSTOM_SSDT_OVERLAYS, which defaults
disabled, in order to allow enabling or disabling that feature during
the build.
Signed-off-by: Peter Jones
---
drivers/firmware/efi/efi.c | 2 +-
drivers/firmware/efi/Kconfig | 11 +++
2 files changed, 12 insertions(+), 1
g: redraw
> efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
>
> Use the host bridge offset information to convert bus address to
> resource address in the fixup.
>
> Signed-off-by: Sinan Kaya
Looks reasonable to me - Ard, do you want to take this up through the
EFI tr
On Thu, Apr 05, 2018 at 07:43:49AM +0200, Lukas Wunner wrote:
> On Wed, Apr 04, 2018 at 01:18:36PM -0400, Peter Jones wrote:
> > > On Tue, Apr 03, 2018 at 08:07:11PM +0200, Lukas Wunner wrote:
> > > > * Add the EFI Firmware Volume Protocol to include/linux/efi.h:
On Tue, Apr 03, 2018 at 02:51:23PM -0700, Andy Lutomirski wrote:
> On Tue, Apr 3, 2018 at 12:29 PM, Matthew Garrett wrote:
> > On Tue, Apr 3, 2018 at 9:46 AM Andy Lutomirski wrote:
> >> On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett wrote:
> >> > A kernel that allows users arbitrary access to r
On Tue, Apr 03, 2018 at 06:58:48PM +, Luis R. Rodriguez wrote:
> On Tue, Apr 03, 2018 at 08:07:11PM +0200, Lukas Wunner wrote:
> > On Tue, Apr 03, 2018 at 10:33:25AM +0200, Hans de Goede wrote:
> > > I asked Peter Jones for suggestions how to extract this during boot and
return -ENOSPC;
> + }
Doesn't seem like this needs to be pr_err(); after all we have already
found a valid match, so the firmware vendor has done something
moderately stupid, but we have a firmware that will probably work. Of
course it still needs to return != 0, but pr_warn() or even pr_info()
seems more reasonable.
Aside from those nits, looks good to me.
Reviewed-by: Peter Jones
--
Peter
On Thu, Feb 22, 2018 at 06:11:14AM +, Luck, Tony wrote:
>> On Feb 21, 2018, at 21:52, Linus Torvalds wrote:
>>
>> Does the error return actually break real users? Not "I can do did
>> things and it acts differently" things, but actual users...
>
On Tue, Feb 20, 2018 at 02:01:51PM -0800, Linus Torvalds wrote:
> Which variables are actually used by user space tools? It sounds like
> it may be exactly those boot order things that we already have flags
> and special behavior for.
Not that many are really part of a non-root workflow. The big
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 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 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
rite
> combining if they see this until we can figure it out.
Well, that's kind of amazing, given 3c004b4f7eab239e switched us /to/
using ioremap_wc() for the exact same reason. I'm not against letting
the user force one way or the other if it helps, though it sure would be
nice to know why.
Anyway,
Acked-By: Peter Jones
Bartlomiej, do you want to handle this in your devel tree?
--
Peter
r a newly
> > kexec'd kernel to access the same boot services regions that the
> > initial boot kernel had access to unless they are reserved by every
> > kexec kernel in the chain.
> >
> > Tested-by: Dave Young [kexec/kdump]
> > Tested-by: Ard Bieshe
On Mon, Nov 21, 2016 at 08:06:44PM +0100, Ard Biesheuvel wrote:
> On 21 November 2016 at 20:05, Peter Jones wrote:
> > On Mon, Nov 21, 2016 at 04:42:45PM +, Ard Biesheuvel wrote:
> >> On 21 November 2016 at 16:26, Josh Boyer wrote:
> >> > On Mon, Nov 21, 20
On Mon, Nov 21, 2016 at 04:42:45PM +, Ard Biesheuvel wrote:
> On 21 November 2016 at 16:26, Josh Boyer wrote:
> > On Mon, Nov 21, 2016 at 11:18 AM, Ard Biesheuvel
> > wrote:
> >> On 16 November 2016 at 18:11, David Howells wrote:
> >>> From: Josh Boyer
> >>>
> >>> If a user tells shim to no
Commit-ID: 753375a881caa01112b7cec2c796749154e0bb23
Gitweb: http://git.kernel.org/tip/753375a881caa01112b7cec2c796749154e0bb23
Author: Peter Jones
AuthorDate: Tue, 18 Oct 2016 15:33:17 +0100
Committer: Ingo Molnar
CommitDate: Tue, 18 Oct 2016 17:11:19 +0200
efifb: Show framebuffer
Commit-ID: 54fd11fee59e7d05287bc4eebccc8ec9742f2745
Gitweb: http://git.kernel.org/tip/54fd11fee59e7d05287bc4eebccc8ec9742f2745
Author: Peter Jones
AuthorDate: Sat, 25 Jun 2016 08:20:25 +0100
Committer: Ingo Molnar
CommitDate: Mon, 27 Jun 2016 13:06:55 +0200
efi: Document #define
(Sorry for the slow response - it's deadline time over here.)
On Thu, Jun 16, 2016 at 04:56:57PM +0200, Rafael J. Wysocki wrote:
> On Thu, Jun 16, 2016 at 2:12 AM, Rafael J. Wysocki wrote:
> > On Thu, Jun 16, 2016 at 12:15 AM, Peter Jones wrote:
> >> Right now when booti
Right now when booting, on many laptops the firmware manages the PCIe
bus. As a result, when we call the _OSC ACPI method, it returns an
error code. Unfortunately the errors are not very articulate. As a
result, we show:
ACPI: PCI Root Bridge [PCI0] (domain [bus 00-fe])
acpi PNP0A08:00: _O
green >>= 16 - info->var.green.length;
> + blue >>= 16 - info->var.blue.length;
> ((u32 *)(info->pseudo_palette))[regno] =
> (red << info->var.red.offset) |
> (green << info->var.green.offset) |
> --
> 2.6.6
Looks right to me.
Acked-By: Peter Jones
--
Peter
On Wed, May 11, 2016 at 04:57:47PM -0700, Andy Lutomirski wrote:
> The framebuffer mapping virtual address leaks information about the
> kernel memory layout. Stop logging it.
>
> Cc: Peter Jones
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Tomi Valkeinen
> Cc: linux-
Commit-ID: 6c5450ef66816216e574885cf8d3ddb31ef77428
Gitweb: http://git.kernel.org/tip/6c5450ef66816216e574885cf8d3ddb31ef77428
Author: Peter Jones
AuthorDate: Fri, 6 May 2016 22:39:31 +0100
Committer: Ingo Molnar
CommitDate: Sat, 7 May 2016 07:06:13 +0200
efivarfs: Make
; 0(start) <= lfb_base < end
>
> Note: this patch also add a trivial optimization,
> break out after we find the address range
> is valid without test later BARs.
>
> Signed-off-by: Wang YanQing
This looks correct to me:
Reviewed-By: Peter Jones
Cc'ing Ma
On Thu, Apr 21, 2016 at 01:18:27PM +0100, Matt Fleming wrote:
> ( Good Lord, I hate doing string manipulation in C )
(yep)
>
> On Wed, 20 Apr, at 03:25:32PM, Laszlo Ersek wrote:
> >
> > So, "len" does not include the room for the terminating NUL-byte here.
> > When "len" is passed to ucs2_as_ut
Commit-ID: 662b1d890c593673964758fe5b6f22067bffba7a
Gitweb: http://git.kernel.org/tip/662b1d890c593673964758fe5b6f22067bffba7a
Author: Peter Jones
AuthorDate: Wed, 17 Feb 2016 12:35:54 +
Committer: Ingo Molnar
CommitDate: Mon, 22 Feb 2016 08:26:25 +0100
efi: Reformat GUID tables
On Tue, Feb 16, 2016 at 01:49:18PM +, Matt Fleming wrote:
> [ Including Peter, the efifb maintainer. Original email is here,
>
> http://marc.info/?l=linux-kernel&m=145552936131335&w=2
>
> I've snipped some of the quoted text ]
>
> On Tue, 16 Feb, at 08:55:22AM, Ingo Molnar wrote:
> >
Back in 2010, t13 EDD version 4 added a couple of storage types, some
host bridge types (that are pretty much all represented identically),
and a couple of fields on existing storage types.
This change makes the driver expose those to userland.
Signed-off-by: Peter Jones
---
drivers/firmware
On Tue, Sep 01, 2015 at 09:57:08AM +0100, Matt Fleming wrote:
> On Mon, 31 Aug, at 09:52:02AM, Peter Jones wrote:
> > On Wed, Aug 26, 2015 at 06:11:28PM +0100, Matt Fleming wrote:
> > >
> > > Looks good to me. I know Peter is on vacation right now, so I'm still
>
gt; frame buffer address.
>
> Still, it is possible to build firmware that uses a full 64-bit GOP
> frame buffer address. Chad did, which led to him reporting this issue.
>
> Add support in anticipation of GOP devices using 64-bit addresses more
> widely, and so that efifb works
t ordering remains unchanged with this commit.
> >
> > We leave some tags like MODULE_AUTHOR for documentation purposes.
> >
> > We don't replace module.h with init.h since the file already has that.
> >
> > Cc: Matt Fleming
> > Cc: Peter Jones
>
is working correctly at all the places the code
built before. I no longer have any ia64 machines handy to test that the
exclusion actually works there.
Signed-off-by: Peter Jones
Acked-by: Tony Luck
---
drivers/firmware/efi/Kconfig | 5 +
drivers/firmware/efi/Makefile | 3 ++-
inclu
On Fri, Jun 05, 2015 at 02:54:35PM -0400, Peter Jones wrote:
> Note that I've only actually tried to build this patch on x86_64, but
> esrt.o still gets built there, and that would seem to demonstrate that
> the conditional building is working correctly at all the places the code
is working correctly at all the places the code
built before. I no longer have any ia64 machines handy to test that the
exclusion actually works there.
Signed-off-by: Peter Jones
Acked-by: Tony Luck
---
drivers/firmware/efi/Kconfig | 5 +
drivers/firmware/efi/Makefile | 3 ++-
inclu
is working correctly at all the places the code
built before. I no longer have any ia64 machines handy to test that the
exclusion actually works there.
Signed-off-by: Peter Jones
---
drivers/firmware/efi/Makefile | 5 -
include/linux/efi.h | 4
2 files changed, 8 insertions(
On Tue, Jun 02, 2015 at 08:45:57AM +0200, Ingo Molnar wrote:
> @@ -167,7 +167,6 @@ static struct kset *esrt_kset;
>
> static int esre_create_sysfs_entry(void *esre, int entry_num)
> {
> - int rc = 0;
> struct esre_entry *entry;
> char name[20];
>
> @@ -180,13 +179,15 @@
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
> > update from close()? In theory close returns an error code (not sure if
> > most tools actuall
On Tue, Mar 10, 2015 at 08:51:59AM -0700, Andy Lutomirski wrote:
> On Tue, Mar 10, 2015 at 8:40 AM, Peter Jones wrote:
> >
> >> >> So, for the sysfs interface, let's not allow loading from /lib. Let's
> >> >> not require a userland tool. Let's
> >> So, for the sysfs interface, let's not allow loading from /lib. Let's
> >> not require a userland tool. Let's just do,
> >>
> >> # echo /path/to/my/awesome/capsule.bin > /sys/../capsule
> >
> >>
> >> and be done with it.
> >>
> >> Hmmm?
> >
> > I assume you're implying a) the capsule header
On Tue, Mar 10, 2015 at 10:56:32AM -0400, Peter Jones wrote:
> That said, I haven't sent my patch to add the capsule headers to gnu-efi
> yet, so you won't get very far - I'll make sure and send those this
> week, hopefully today.
Slight correction, I did actually do th
On Tue, Mar 10, 2015 at 12:26:52PM +, Matt Fleming wrote:
> On Fri, 06 Mar, at 04:39:12PM, Peter Jones wrote:
> >
> > So again: do we really need or want to do this?
>
> One thing that we totally lose the ability to do is use the capsule
> interface for things *othe
On Mon, Mar 09, 2015 at 06:54:12PM -0700, Roy Franz wrote:
> On Mon, Mar 9, 2015 at 2:23 PM, Borislav Petkov wrote:
> > + pjones.
> >
> > So reportedly, there is already a capsule-loading thing which doesn't
> > need the kernel at all:
> >
> > https://github.com/rhinstaller/fwupdate
> >
> > So why
On Fri, Mar 06, 2015 at 01:49:20PM -0800, Roy Franz wrote:
> On Fri, Mar 6, 2015 at 1:39 PM, Peter Jones wrote:
> > On Tue, Feb 24, 2015 at 12:49:09PM +, Kweh, Hock Leong wrote:
> >> Hi All,
> >>
> >> After some internal discussion and re-design prototypin
On Tue, Feb 24, 2015 at 12:49:09PM +, Kweh, Hock Leong wrote:
> Hi All,
>
> After some internal discussion and re-design prototyping & testing on
> this efi capsule interface kernel module, I would like to start a discussion
> here on the new idea and wish to get input for the implementation a
On Wed, Feb 11, 2015 at 03:55:24PM +, Matt Fleming wrote:
> On Mon, 09 Feb, at 12:23:15PM, Yinghai Lu wrote:
> > On Mon, Feb 9, 2015 at 10:27 AM, Matt Fleming
> > wrote:
> > > On Tue, 03 Feb, at 06:03:20PM, Yinghai Lu wrote:
> > >
> > > The first thing that comes to mind is the issues we expe
On Tue, Oct 22, 2013 at 10:51:40AM -0400, Konrad Rzeszutek Wilk wrote:
> And I still haven't found the module that can launch any PE/COFF
> image from GRUB2. Maybe that is a myth.
"chainload" will do this. In fact, it doesn't do much:
static grub_err_t
grub_chainloader_boot (void)
{
grub_efi_b
On Mon, Oct 21, 2013 at 02:57:56PM +0200, Daniel Kiper wrote:
> Hi,
>
> During work on multiboot2 protocol support for Xen it was discovered
> that memory map passed via relevant tag could not represent wide range
> of memory types available on EFI platforms. Additionally, GRUB2
> implementation c
On Sat, Oct 12, 2013 at 10:14:39AM +0800, Dave Young wrote:
> CCing Peter Jones .., Peter, any idea about the grub related problem?
What grub problem? As Matt was saying, grub2 isn't loading it as
EfiBootServicesCode/Data. grub2 is loading it as EfiLoaderData .
>
> On 10/11
On Thu, Oct 10, 2013 at 07:45:21PM +0200, Ingo Molnar wrote:
>
> * Peter Jones wrote:
>
> > On Thu, Oct 10, 2013 at 07:28:44PM +0200, Ingo Molnar wrote:
> > >
> > > Is a non-32-bit framebuffer a possibility? If yes then it might be nice
> > > to
&
On Thu, Oct 10, 2013 at 07:28:44PM +0200, Ingo Molnar wrote:
>
> Is a non-32-bit framebuffer a possibility? If yes then it might be nice to
> emit an informative printk() here, so that users who try to enable EFI
> early-printk can at least see why it's not working. (Assuming they get to
> look
On Fri, Aug 16, 2013 at 03:51:34PM +0200, David Herrmann wrote:
> Hi
>
> On Thu, Jul 25, 2013 at 5:48 PM, Peter Jones wrote:
> > This was found by Alexandra Kossovsky, who noted this traceback from
> > kmemleak:
> >
> >> unreferenced object 0x880216fcfe0
This was found by Alexandra Kossovsky, who noted this traceback from
kmemleak:
> unreferenced object 0x880216fcfe00 (size 512):
> comm "swapper/0", pid 1, jiffies 4294895429 (age 1415.320s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 aa aa aa aa aa aa aa aa
On Thu, Jul 25, 2013 at 01:18:31PM +0100, Catalin Marinas wrote:
> On 21 July 2013 16:11, Alexandra N. Kossovsky
> wrote:
> > I am running linux-3.10.0 with kmemleak and see following warnings
> > in /sys/kernel/debug/kmemleak:
> >
> > unreferenced object 0x880216fcfe00 (size 512):
> > comm
EFI error numbers are useful, but symbol names are way easier to
understand when you're reading bug reports. And since, for the most
part, we know the names, we should show them.
Signed-off-by: Peter Jones
Reviewed-by: Adam Jackson
---
drivers/firmware/efivars.c | 19 +---
in
ion function that gives us a default release() function.
This fixes the tracback reported at
https://bugzilla.redhat.com/show_bug.cgi?id=840621 , though it does not
fix the actual /problem/ the user is seeing.
Signed-off-by: Peter Jones
---
drivers/video/efifb.c | 15 ---
1 file chan
This should help avoid making the incorrect change in non-compliant
bootloaders.
Signed-off-by: Peter Jones
---
Documentation/x86/boot.txt | 5 +++--
arch/x86/include/asm/bootparam_utils.h | 7 +++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/Documentation/x86
On Wed, Mar 06, 2013 at 09:14:27AM -0800, H. Peter Anvin wrote:
> On 03/06/2013 08:55 AM, Peter Jones wrote:
> >
> > So, the problem here seems to be that there's never been widespread
> > compliance with this paragraph, but this patch assumes there has. A
> >
On Thu, Feb 28, 2013 at 01:12:11PM -0800, H. Peter Anvin wrote:
> Then make it follow the boot spec:
>
> > In 32-bit boot protocol, the first step in loading a Linux kernel
> > should be to setup the boot parameters (struct boot_params,
> > traditionally known as "zero page"). The memory for struc
On Wed, Feb 27, 2013 at 01:32:30PM +0100, Geert Uytterhoeven wrote:
> On Tue, Feb 26, 2013 at 11:06 PM, Peter Jones wrote:
> > On Tue, Feb 26, 2013 at 10:57:38PM +0100, Geert Uytterhoeven wrote:
> >
> >> BTW, I assume UEFI checks itself if enrolled hashes have been revoke
On Tue, Feb 26, 2013 at 10:57:38PM +0100, Geert Uytterhoeven wrote:
> BTW, I assume UEFI checks itself if enrolled hashes have been revoked,
> so it must phone home to some server? That must be disabled as well.
No. Quit fearmongering.
--
Peter
--
To unsubscribe from this list: send the
On Tue, Feb 26, 2013 at 10:30:46PM +0100, Florian Weimer wrote:
> * Linus Torvalds:
>
> > So here's what I would suggest, and it is based on REAL SECURITY and
> > on PUTTING THE USER FIRST instead of your continual "let's please
> > microsoft by doing idiotic crap" approach.
>
> I think the real
On Mon, Feb 25, 2013 at 11:45:21PM -0500, Theodore Ts'o wrote:
> On Tue, Feb 26, 2013 at 02:25:55PM +1000, Dave Airlie wrote:
> >
> > Its a simple argument, MS can revoke our keys for whatever reason,
> > reducing the surface area of reasons for them to do so seems like a
> > good idea. Unless som
On Thu, Feb 21, 2013 at 10:03:20AM -0800, Linus Torvalds wrote:
> Besides, let's face it, Red Hat is going to sign the official nVidia
> and AMD binary modules anyway. Don't even bother to pretend anything
> else.
I just want to make sure this doesn't go unresponded to - Red Hat
will not sign kern
On Thu, Feb 21, 2013 at 10:56:44AM -0800, Linus Torvalds wrote:
> On Thu, Feb 21, 2013 at 10:34 AM, Peter Jones wrote:
> > On Thu, Feb 21, 2013 at 10:25:47AM -0800, Linus Torvalds wrote:
> >> - why do you bother with the MS keysigning of Linux kernel modules to
> >>
On Thu, Feb 21, 2013 at 10:25:47AM -0800, Linus Torvalds wrote:
> - why do you bother with the MS keysigning of Linux kernel modules to
> begin with?
This is not actually what the patchset implements. All it's done here
is using PE files as envelopes for keys. The usage this enables is to
allow
o fix this
issue. Thanks for the patch, though. Andrew, if you'd like you can
just use this instead of replacing my patch with the new one.
Signed-off-by: Peter Jones
>
> Typecast sizeof(gpt_header) to (unsigned long) to avoid such warning on
> 32-bit
> systems.
>
&g
is is that when we verify the checksum, it's possible that
on a malformed header (with header_size of 0), we won't actually verify
any data.
Signed-off-by: Peter Jones
Cc: Matt Fleming
Cc: Jens Axboe
Cc: Stephen Warren
Cc: Andrew Morton
---
block/partitions/efi.c | 12 ++--
1 f
Stephen,
The following email is an updated patch which should fix the warning you're
seeing on architectures where sizeof is unsigned int rather than unsigned
long.
This completely replaces the ef25bb0fa6e2 patch. Andrew, if you'd prefer a
single-line fixup patch, I can send you that instead.
is is that when we verify the checksum, it's possible
that on a malformed header (with header_size of 0), we won't actually
verify any data.
Signed-off-by: Peter Jones
---
block/partitions/efi.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/block/par
is is that when we verify the checksum, it's possible
that on a malformed header (with header_size of 0), we won't actually
verify any data.
(ammended to fix type error in pr_debug())
Signed-off-by: Peter Jones
---
block/partitions/efi.c | 12 ++--
1 file changed, 10 insertions(
On Tue, Feb 05, 2013 at 02:34:50PM +0200, Dmitry Kasatkin wrote:
> +static const char *secmnt = "/root";
> +static const char *initramfs_img = "/initramfs-sig.img";
> +
> +static int __init load_image(const char *from)
> +{
...
> + err = sys_mount("tpmfs", (char *)secmnt, "tmpfs", MS_SILENT, N
On Tue, Feb 05, 2013 at 02:34:50PM +0200, Dmitry Kasatkin wrote:
> Often initramfs is (re)fabricated on the machine on which it runs.
> In such cases it is impossible to sign initramfs image, because
> private key is not supposed to be available.
This doesn't address that problem at all.
> This p
On Tue, Feb 05, 2013 at 02:34:49PM +0200, Dmitry Kasatkin wrote:
> Signed-off-by: Dmitry Kasatkin
> ---
> init/do_mounts.h |2 ++
> init/initramfs.c |2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/init/do_mounts.h b/init/do_mounts.h
> index f5b978a..11829eb 1006
On Tue, Feb 05, 2013 at 03:46:04AM +, Ben Hutchings wrote:
> On Mon, 2013-02-04 at 16:44 +, Matt Fleming wrote:
> > On Sun, 2013-02-03 at 16:15 +0100, Ben Hutchings wrote:
> > > As you can see this needed quite a lot of work to backport, and I
> > > haven't been able to test it yet. So I w
the end of this diff is also a break; there's no further code
in that case.
> Signed-off-by: Dan Carpenter
Acked-by: Peter Jones
>
> diff --git a/drivers/firmware/iscsi_ibft.c b/drivers/firmware/iscsi_ibft.c
> index 3ee852c..c4b187c 100644
> --- a/drivers/firmware/i
o check the memory type of 0xa - whether
> > or not that memory region is EFI_CONVENTIONAL_MEMORY is immaterial -
> > the EFI framebuffer device will still work, and checking the EFI
> > memory type of a memory region on a non-EFI machine is illogical.
> >
> > Cc: H. Peter Anvin
&
On Thu, Oct 04, 2012 at 05:08:48PM +0800, Jeremy Kerr wrote:
> Hi Matt,
>
> >Jeremy, did you want to pick this up as part of your series?
>
> I have this in my series, yes. I'm just working on the authenticated
> delete code, then will send out the next revision.
>
> Speaking of which - Peter: I
On Tue, 2012-09-18 at 19:51 +0100, Alan Cox wrote:
> On Tue, 18 Sep 2012 18:34:12 +0100
> David Howells wrote:
>
> > Alan Cox wrote:
> >
> > > Why do this in the kernel.That appears to be completely insane.
> >
> > A number of reasons:
> >
> > (1) The UEFI signature/key database may contain
On Thu, 2012-09-13 at 16:10 +0800, joeyli wrote:
> Do we have plan to create a new kobject add to /sys/firmware/efi for
> provide a fixed mount point to efivars fs?
> e.g. /sys/firmware/efi/efivars
>
> Or we just direct reuse current /sys/firmeware/efi/vars? But, that means
> we need think for th
Obviously, this went to the wrong list of addresses. Sorry for all the
noise.
On Wed, 2012-08-08 at 10:18 -0400, Peter Jones wrote:
> For UEFI Secure Boot support, we need to install the shim pre-boot
> loader, and use it to load grub2.
> ---
> pyanaconda/bootloader.py | 4 ++
For UEFI Secure Boot support, we need to install the shim pre-boot
loader, and use it to load grub2.
---
pyanaconda/bootloader.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pyanaconda/bootloader.py b/pyanaconda/bootloader.py
index ea4de5e..02d0ea8 100644
--- a/pyanacon
jwboyer's previous commit changes the behavior of module signing when
there's a valid signature but we don't know the public key and are in
permissive mode. This updates the documentation to match.
Signed-off-by: Peter Jones
Acked-by: Josh Boyer
---
Documentation/module-signin
jwboyer's previous commit changes the behavior of module signing when
there's a valid signature but we don't know the public key and are in
permissive mode. This updates the documentation to match.
---
Documentation/module-signing.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
This adds support for appending to all UEFI variables, and also for
deleting authentication variables.
(Updated to address mfleming's concerns on 7/30/2012)
Signed-off-by: Peter Jones
---
drivers/firmware/efivars.c | 99
1 file change
Konrad Rzeszutek wrote:
iBFT is not platform-independent; it only makes sense on platforms with
ACPI (and even then, just barely; ACPI is a poor fit for it and it was
probably "integrated" with ACPI for political reasons.)
The spec just mentions that iBFT table has to be "compatible with an ACP
H. Peter Anvin wrote:
Peter Jones wrote:
It should, presumably, depend on ACPI, rather than on X86...?
Actually no. That /should/ be the correct answer, but none of the
hardware vendors actually provide the table via ACPI yet. Also, if they
did, the support for /sys/firmware/acpi/tables
H. Peter Anvin wrote:
Konrad Rzeszutek wrote:
+config ISCSI_IBFT
+ tristate "iSCSI Boot Firmware Table Attributes"
+ depends on X86
why only on X86?
PowerPC exports this data via the OpenFirmware so it already shows in
the /sysfs entries. I was thinking to combine those sysfs entri
Kay Sievers wrote:
Peter, any idea what it could be, that goes wrong on Andrew's box, or
how to look for what exactly is going wrong?
http://userweb.kernel.org/~akpm/s5000552.jpg
Seems that yellowdog uses RH's nash.
Yeah, but a /really/ old version -- 4.2.11 is from May 2005 :/ . I feel
I
Greg KH wrote:
On Thu, Jun 07, 2007 at 02:48:05PM -0400, Bill Nottingham wrote:
Greg KH ([EMAIL PROTECTED]) said:
There are a number of distros out there right now who can support that
option disabled. I'm pretty sure they are the following right now:
Gentoo unstable (actually stable w
Kay Sievers wrote:
On Thu, 2007-06-07 at 11:41 +0200, Michal Piotrowski wrote:
Kay Sievers pisze:
On Thu, 2007-06-07 at 10:40 +0200, Michal Piotrowski wrote:
Kay Sievers pisze:
On Wed, 2007-06-06 at 20:48 +0200, Michal Piotrowski wrote:
Andrew Morton pisze:
ftp://ftp.kernel.org/pub/linux/ke
Matthew Wilcox wrote:
On Tue, May 15, 2007 at 12:26:29PM +0100, Simon Arlott wrote:
I've already suggested a sysfs attribute - or something equivalent - would
be much better. It's just one function that a user might want to run multiple
times (e.g. after adding scsi devices?) - why should loadin
Dave Jones wrote:
On Thu, May 17, 2007 at 03:30:43PM -0600, Matthew Wilcox wrote:
> On Thu, May 17, 2007 at 03:43:26PM -0400, Benjamin LaHaise wrote:
> > On Thu, May 17, 2007 at 01:39:54PM -0600, Matthew Wilcox wrote:
> > > On Fri, May 18, 2007 at 12:34:40AM +0530, Satyam Sharma wrote:
> > >
On Fri, 2005-09-02 at 21:22 +0100, Alan Cox wrote:
> On Gwe, 2005-09-02 at 15:14 -0400, Peter Jones wrote:
> > Ugh. So some BIOSes use it for legitimate reasons (like thinkpads), and
> > some use it to work around BIOS bugs. Great.
>
> All are legitimate uses. The part
On Fri, 2005-09-02 at 19:59 +0100, Alan Cox wrote:
> On Gwe, 2005-09-02 at 14:09 -0400, Peter Jones wrote:
> > (if there's already a straightforward way, feel free to clue me in --
> > but the default should almost certainly be to assume the HPA is set up
> > correctl
On Fri, 2005-09-02 at 19:44 +0200, Molle Bestefich wrote:
> Related matters:
> If you decide to include the HPA in one of your filesystems, is there
> not a big risk that the BIOS will overwrite something there?
Isn't the bigger risk that if you include the HPA in your block device,
you'll overwr
On Wed, 2005-08-31 at 15:07 -0700, Chris Wedgwood wrote:
> On Wed, Aug 31, 2005 at 03:01:57PM -0700, H. Peter Anvin wrote:
>
> > Maybe not. Another option would simply be to bump it up
> > significantly (2x isn't really that much.) 4096, maybe.
>
> I wonder if we're not at the point where we ne
98 matches
Mail list logo
