Re: [PATCH 29/44] staging: nvec: Register with kernel poweroff handler

[Greg Kroah-Hartman]

On Mon, Oct 06, 2014 at 10:28:31PM -0700, Guenter Roeck wrote:
> Register with kernel poweroff handler instead of setting pm_power_off
> directly. Register with default priority value of 128 since we don't know
> any better.
> 
> Cc: Julian Andres Klode 
> Cc: Marc Dietrich 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Guenter Roeck 
> ---
>  drivers/staging/nvec/nvec.c | 24 +++-
>  drivers/staging/nvec/nvec.h |  2 ++
>  2 files changed, 17 insertions(+), 9 deletions(-)

Acked-by: Greg Kroah-Hartman 
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] Enable user helper interface for efi capsule update

[Greg Kroah-Hartman]

On Mon, Nov 03, 2014 at 11:33:23AM -0800, Andy Lutomirski wrote:
> On 11/02/2014 07:07 PM, Kweh Hock Leong wrote:
> > From: "Kweh, Hock Leong" 
> > 
> > 
> > Hi Guys,
> > 
> > This patchset is created on top of "efi: Capsule update support" patch:
> > http://permalink.gmane.org/gmane.linux.kernel.efi/4837
> > 
> > It leverages the request_firmware_nowait() to expose the user helper 
> > interface for user to upload the capsule binary and calling the
> > efi_capsule_update() API to pass the binary to EFI firmware.
> 
> I don't get it.  Why is the firmware interface at all reasonable for
> uploading capsules?

Tradition dictates that BIOS updates go through the firmware interface,
that way you don't have to write a new userspace tool, which is a good
thing.

> The firmware interface makes sense for nonvolatile firmware where
> hotplugging something or otherwise loading a driver needs a blob.

Or BIOS data.  We've been doing it this way for a long time now.

> But uploading an EFI capsule is an *action*, not something that should
> happen transparently.  If there's an EFI firmware update available and
> the user wants to install it, then the userspace tool should install it,
> and it shouldn't hang around in /lib/firmware.  In fact, you shouldn't
> even need /lib to be on writable media to use this.

What does /lib have to do with this?

> And you most certainly don't want the EFI capsule hanging around so that
> it might be accidentally installed again if the hard disk is moved.
> 
> ISTM there should be some file in sysfs to which you can write a
> capsule, or perhaps a chardev and an ioctl.

No, just use the firmware interface please.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] Enable user helper interface for efi capsule update

[Greg Kroah-Hartman]

On Mon, Nov 03, 2014 at 01:32:46PM -0800, Andy Lutomirski wrote:
> On Mon, Nov 3, 2014 at 1:27 PM, Greg Kroah-Hartman
>  wrote:
> > On Mon, Nov 03, 2014 at 11:33:23AM -0800, Andy Lutomirski wrote:
> >> On 11/02/2014 07:07 PM, Kweh Hock Leong wrote:
> >> > From: "Kweh, Hock Leong" 
> >> > 
> >> >
> >> > Hi Guys,
> >> >
> >> > This patchset is created on top of "efi: Capsule update support" patch:
> >> > http://permalink.gmane.org/gmane.linux.kernel.efi/4837
> >> >
> >> > It leverages the request_firmware_nowait() to expose the user helper 
> >> > interface for user to upload the capsule binary and calling the
> >> > efi_capsule_update() API to pass the binary to EFI firmware.
> >>
> >> I don't get it.  Why is the firmware interface at all reasonable for
> >> uploading capsules?
> >
> > Tradition dictates that BIOS updates go through the firmware interface,
> > that way you don't have to write a new userspace tool, which is a good
> > thing.
> >
> >> The firmware interface makes sense for nonvolatile firmware where
> >> hotplugging something or otherwise loading a driver needs a blob.
> >
> > Or BIOS data.  We've been doing it this way for a long time now.
> 
> On what system?  Dell?

Yes.

> IMO this sucks from a UI point of view.  When I install wifi firmware,
> I expect to stick it somewhere and have the driver find it, because
> the driver knows exactly when it needs the firmware.  When I update my
> BIOS, I want to click a button or type a command and update my bios.

I agree, it should be "triggered" by something, not just automagically
loaded whenever the kernel randomly looks for it.

> >> But uploading an EFI capsule is an *action*, not something that should
> >> happen transparently.  If there's an EFI firmware update available and
> >> the user wants to install it, then the userspace tool should install it,
> >> and it shouldn't hang around in /lib/firmware.  In fact, you shouldn't
> >> even need /lib to be on writable media to use this.
> >
> > What does /lib have to do with this?
> 
> Where else does the file come from, given that udev no longer supports
> userspace firmware loading?  Is there really some pre-existing tool
> that pokes it into the sysfs firmware class thing?

Well, you can specify other locations than /lib/firmware/ for firmware
updates, but yes, you are right, it should be in /lib somewhere.  But
/lib doesn't need to be writable, it's a read-only file.

> Since EFI capsules are apparently on their way to becoming a
> ubiquitous mechanism, I think it might be time to rethink
> request_firmware for this.

What do you suggest instead?  A "custom" sysfs file?  What is going to
trigger it to be loaded?  A userspace script that someone else has to
write?  :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] Enable user helper interface for efi capsule update

[Greg Kroah-Hartman]

On Mon, Nov 03, 2014 at 03:08:08PM -0800, Andy Lutomirski wrote:
> On Mon, Nov 3, 2014 at 3:02 PM, Greg Kroah-Hartman
>  wrote:
> > On Mon, Nov 03, 2014 at 01:32:46PM -0800, Andy Lutomirski wrote:
> >> On Mon, Nov 3, 2014 at 1:27 PM, Greg Kroah-Hartman
> >>  wrote:
> >> > On Mon, Nov 03, 2014 at 11:33:23AM -0800, Andy Lutomirski wrote:
> >> >> On 11/02/2014 07:07 PM, Kweh Hock Leong wrote:
> >> >> > From: "Kweh, Hock Leong" 
> >> >> > 
> >> >> >
> >> >> > Hi Guys,
> >> >> >
> >> >> > This patchset is created on top of "efi: Capsule update support" 
> >> >> > patch:
> >> >> > http://permalink.gmane.org/gmane.linux.kernel.efi/4837
> >> >> >
> >> >> > It leverages the request_firmware_nowait() to expose the user helper 
> >> >> > interface for user to upload the capsule binary and calling the
> >> >> > efi_capsule_update() API to pass the binary to EFI firmware.
> >> >>
> >> >> I don't get it.  Why is the firmware interface at all reasonable for
> >> >> uploading capsules?
> >> >
> >> > Tradition dictates that BIOS updates go through the firmware interface,
> >> > that way you don't have to write a new userspace tool, which is a good
> >> > thing.
> >> >
> >> >> The firmware interface makes sense for nonvolatile firmware where
> >> >> hotplugging something or otherwise loading a driver needs a blob.
> >> >
> >> > Or BIOS data.  We've been doing it this way for a long time now.
> >>
> >> On what system?  Dell?
> >
> > Yes.
> >
> >> IMO this sucks from a UI point of view.  When I install wifi firmware,
> >> I expect to stick it somewhere and have the driver find it, because
> >> the driver knows exactly when it needs the firmware.  When I update my
> >> BIOS, I want to click a button or type a command and update my bios.
> >
> > I agree, it should be "triggered" by something, not just automagically
> > loaded whenever the kernel randomly looks for it.
> >
> >> >> But uploading an EFI capsule is an *action*, not something that should
> >> >> happen transparently.  If there's an EFI firmware update available and
> >> >> the user wants to install it, then the userspace tool should install it,
> >> >> and it shouldn't hang around in /lib/firmware.  In fact, you shouldn't
> >> >> even need /lib to be on writable media to use this.
> >> >
> >> > What does /lib have to do with this?
> >>
> >> Where else does the file come from, given that udev no longer supports
> >> userspace firmware loading?  Is there really some pre-existing tool
> >> that pokes it into the sysfs firmware class thing?
> >
> > Well, you can specify other locations than /lib/firmware/ for firmware
> > updates, but yes, you are right, it should be in /lib somewhere.  But
> > /lib doesn't need to be writable, it's a read-only file.
> >
> 
> I assume that whoever downloaded the firmware update will want to
> install it, right?  I don't really expect distros to ship EFI capsules
> in packages that install to /lib/firmware.  Won't there be userspace
> code that either installs a capsule from some URL or uses some future
> magical find-my-firmware service?

Good point, I don't know.

Who ever wrote this code should know this, can someone please provide a
use-case for how this is all supposed to work?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

[Greg Kroah-Hartman]

On Mon, Nov 03, 2014 at 11:07:10AM +0800, Kweh Hock Leong wrote:
> From: "Kweh, Hock Leong" 
> 
> Introducing a kernel module to expose user helper interface for
> user to upload capsule binaries. This module leverage the
> request_firmware_nowait() to expose an interface to user.
> 
> Example steps to load the capsule binary:
> 1.) echo 1 > /sys/class/firmware/efi-capsule-file/loading
> 2.) cat capsule.bin > /sys/class/firmware/efi-capsule-file/data
> 3.) echo 0 > /sys/class/firmware/efi-capsule-file/loading
> 
> Whereas, this module does not allow the capsule binaries to be
> obtained from the request_firmware library search path. If any
> capsule binary loaded from firmware seach path, the module will
> stop functioning.
> 
> Besides the request_firmware user helper interface, this module
> also expose a 'capsule_loaded' file note for user to verify
> the number of successfully uploaded capsule binaries. This
> file note has the read only attribute.

Andy, here's the steps to load a capsule.  I don't have a problem with
this, it's userspace driven, no "autoloading" of files in /lib/, and
works with sysfs.

Have any objection to it, I don't.

Full patch left below...

> 
> Cc: Matt Fleming 
> Signed-off-by: Kweh, Hock Leong 
> ---
>  drivers/firmware/efi/Kconfig   |   13 ++
>  drivers/firmware/efi/Makefile  |1 +
>  drivers/firmware/efi/efi-capsule-user-helper.c |  246 
> 
>  3 files changed, 260 insertions(+)
>  create mode 100644 drivers/firmware/efi/efi-capsule-user-helper.c
> 
> diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
> index f712d47..7dc814e 100644
> --- a/drivers/firmware/efi/Kconfig
> +++ b/drivers/firmware/efi/Kconfig
> @@ -60,6 +60,19 @@ config EFI_RUNTIME_WRAPPERS
>  config EFI_ARMSTUB
>   bool
>  
> +config EFI_CAPSULE_USER_HELPER
> + tristate "EFI capsule user mode helper"
> + depends on EFI
> + select FW_LOADER
> + select FW_LOADER_USER_HELPER
> + help
> +   This option exposes the user mode helper interface for user to load
> +   EFI capsule binary and update the EFI firmware after system reboot.
> +   This feature does not support auto locating capsule binaries at the
> +   firmware lib search path.
> +
> +   If unsure, say N.
> +
>  endmenu
>  
>  config UEFI_CPER
> diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
> index 698846e..63f6910 100644
> --- a/drivers/firmware/efi/Makefile
> +++ b/drivers/firmware/efi/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_UEFI_CPER)   += cper.o
>  obj-$(CONFIG_EFI_RUNTIME_MAP)+= runtime-map.o
>  obj-$(CONFIG_EFI_RUNTIME_WRAPPERS)   += runtime-wrappers.o
>  obj-$(CONFIG_EFI_STUB)   += libstub/
> +obj-$(CONFIG_EFI_CAPSULE_USER_HELPER)+= efi-capsule-user-helper.o
> diff --git a/drivers/firmware/efi/efi-capsule-user-helper.c 
> b/drivers/firmware/efi/efi-capsule-user-helper.c
> new file mode 100644
> index 000..84a1628
> --- /dev/null
> +++ b/drivers/firmware/efi/efi-capsule-user-helper.c
> @@ -0,0 +1,246 @@
> +/*
> + * EFI capsule user mode helper interface driver.
> + *
> + * Copyright 2014 Intel Corporation
> + *
> + * This file is part of the Linux kernel, and is made available under
> + * the terms of the GNU General Public License version 2.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define CAPSULE_NAME "efi-capsule-file"
> +#define DEV_NAME "efi_capsule_user_helper"
> +#define STRING_INTEGER_MAX_LENGTH 13
> +
> +static DEFINE_MUTEX(user_helper_lock);
> +static int capsule_count;
> +static int stop_request;
> +static struct platform_device *efi_capsule_pdev;
> +
> +/*
> + * This function will store the capsule binary and pass it to
> + * efi_capsule_update() API in capsule.c
> + */
> +static int efi_capsule_store(const struct firmware *fw)
> +{
> + int i;
> + int ret;
> + int count = fw->size;
> + int copy_size = (fw->size > PAGE_SIZE) ? PAGE_SIZE : fw->size;
> + int pages_needed = ALIGN(fw->size, PAGE_SIZE) >> PAGE_SHIFT;
> + struct page **pages;
> + void *page_data;
> + efi_capsule_header_t *capsule = NULL;
> +
> + pages = kmalloc_array(pages_needed, sizeof(void *), GFP_KERNEL);
> + if (!pages) {
> + pr_err("%s: kmalloc_array() failed\n", __func__);
> + return -ENOMEM;
> + }
> +
> + for (i = 0; i < pages_needed; i++) {
> + pages[i] = alloc_page(GFP_KERNEL);
> + if (!pages[i]) {
> + pr_err("%s: alloc_page() failed\n", __func__);
> + --i;
> + ret = -ENOMEM;
> + goto failed;
> + }
> + }
> +
> + for (i = 0; i < pages_needed; i++) {
> + page_data = kmap(pages[i]);
> +  

Re: [PATCH v2 1/3] firmware loader: Introduce new API - request_firmware_abort()

[Greg Kroah-Hartman]

On Mon, Nov 03, 2014 at 11:07:08AM +0800, Kweh Hock Leong wrote:
> From: "Kweh, Hock Leong" 
> 
> Besides aborting through user helper interface, a new API
> request_firmware_abort() allows kernel driver module to abort the
> request_firmware() / request_firmware_nowait() when they are no
> longer needed. It is useful for cancelling an outstanding firmware
> load if initiated from inside a module where that module is in the
> process of being unloaded, since the unload function may not have
> a handle to the struct firmware_buf.
> 
> Note for people who use request_firmware_nowait():
> You are required to do your own synchronization after you call
> request_firmware_abort() in order to continue unloading the
> module. The example synchronization code shows below:
> 
> while (THIS_MODULE && module_refcount(THIS_MODULE))
>   msleep(20);

As others have pointed out, this isn't ok, and is totally racy and
should never end up in a driver.  Never mess with THIS_MODULE from
within the same module, otherwise it's racy and broken code.

So can you please rework this to not require this?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] firmware loader: fix hung task warning dump

[Greg Kroah-Hartman]

On Mon, Nov 03, 2014 at 11:07:09AM +0800, Kweh Hock Leong wrote:
> From: "Kweh, Hock Leong" 
> 
> When using request_firmware_nowait() with FW_ACTION_NOHOTPLUG param to
> expose user helper interface, if the user do not react immediately, after
> 120 seconds there will be a hung task warning message dumped as below:
> 
> [ 3000.784235] INFO: task kworker/0:0:8259 blocked for more than 120 seconds.
> [ 3000.791281]   Tainted: GE 3.16.0-rc1-yocto-standard #41
> [ 3000.798082] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [ 3000.806072] kworker/0:0 D cd0075c8 0  8259  2 0x
> [ 3000.812765] Workqueue: events request_firmware_work_func
> [ 3000.818253]  cd375e18 0046 000e cd0075c8 00f0 cd40ea00 
> cd375fec 1b883e89
> [ 3000.826374]  026b cd40ea00 8000 0001 cd0075c8  
> cd375de4 c119917f
> [ 3000.834492]  cd563360 cd375df4 c119a0ab cd563360  cd375e24 
> c119a1d6 
> [ 3000.842616] Call Trace:
> [ 3000.845252]  [] ? kernfs_next_descendant_post+0x3f/0x50
> [ 3000.851543]  [] ? kernfs_activate+0x6b/0xc0
> [ 3000.856790]  [] ? kernfs_add_one+0xd6/0x130
> [ 3000.862047]  [] schedule+0x22/0x60
> [ 3000.866548]  [] schedule_timeout+0x175/0x1d0
> [ 3000.871887]  [] ? __kernfs_create_file+0x71/0xa0
> [ 3000.877574]  [] ? sysfs_add_file_mode_ns+0xaa/0x180
> [ 3000.883533]  [] wait_for_completion+0x6f/0xb0
> [ 3000.888961]  [] ? wake_up_process+0x40/0x40
> [ 3000.894219]  [] _request_firmware+0x750/0x9f0
> [ 3000.899666]  [] ? n_tty_receive_buf2+0x1f/0x30
> [ 3000.905200]  [] request_firmware_work_func+0x22/0x50
> [ 3000.911235]  [] process_one_work+0x122/0x380
> [ 3000.916571]  [] worker_thread+0xf9/0x470
> [ 3000.921555]  [] ? create_and_start_worker+0x50/0x50
> [ 3000.927497]  [] ? create_and_start_worker+0x50/0x50
> [ 3000.933448]  [] kthread+0x9f/0xc0
> [ 3000.937850]  [] ret_from_kernel_thread+0x20/0x30
> [ 3000.943548]  [] ? kthread_worker_fn+0x100/0x100
> 
> This patch change the wait_for_completion() function call to
> wait_for_completion_interruptible() function call for solving the issue.
> 
> Cc: Matt Fleming 
> Signed-off-by: Kweh, Hock Leong 

Acked-by: Greg Kroah-Hartman 
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] firmware loader: Introduce new API - request_firmware_abort()

[Greg Kroah-Hartman]

On Tue, Nov 18, 2014 at 06:31:38AM +, Kweh, Hock Leong wrote:
> > -Original Message-
> > From: Matt Fleming [mailto:m...@console-pimps.org]
> > Sent: Monday, November 17, 2014 11:12 PM
> > >
> > > - Only doing module unload is required to be aware of this synchronization
> > >   -> Ensuring the call back does not fall into unloaded code which may
> > cause
> > >undefined behavior.
> > >   -> Ensuring the put_device() & module_put() code have finished in
> > firmware_class.c
> > >function request_firmware_work_func() before the device is
> > unregistered
> > >and module unloaded happen.
> > 
> > Shouldn't the existing module_{put,get}() and {put,get}_device() calls
> > provide all the necessary synchronisation?
> > 
> > Module unload should not be possible while other code is using the
> > module (and the module refcnt has been incremented accordindly).
> > 
> > Right?
> > 
> > --
> > Matt Fleming, Intel Open Source Technology Center
> 
> Hi Matt,
> 
> Yes, you are right. If the module refcount is not zero, you will get error
> message and returned while you do "rmmod". But I strongly believe if we
> have the capability in our code to take care of it by doing synchronization,
> we should take care of it in case people are doing "rmmod -f". Don't
> you think so?

If you do 'rmmod -f' you get to keep all of the broken pieces of your
kernel, no need to try to help out with crazy things like that.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

[Greg Kroah-Hartman]

On Thu, Mar 12, 2015 at 10:47:54PM +, Matt Fleming wrote:
> On Tue, 10 Mar, at 08:51:59AM, Andy Lutomirski wrote:
> > 
> > I'm not 100% happy with write(2) (which is all we have in sysfs) for
> > two reasons:
> > 
> > 1. If we write a file name, eww.  That's more complicated, requires
> > temporary files, has annoying mount namespace issues, etc.
> > 
> > 2. If we write the full contents, we need to do it in a single call to
> > write.  That means that we can't use cat, which mostly defeats the
> > purpose.  In fact, using cat could be actively harmful.
> 
> At this point I'd really like Greg to chime in.
> 
> In principal, I'm not stricly opposed to using a simple char device
> provided that it's not essentially a copy and paste of code from
> drivers/base/firmware_class.c.
> 
> Greg?

Yes, I don't want a character driver here for this if at all possible.
Just stick with the firmware download code, it's there and should work
"as-is" for your stuff.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/2] firmware_loader: introduce new API - request_firmware_direct_full_path()

[Greg Kroah-Hartman]

On Tue, Apr 14, 2015 at 05:44:55PM +0800, Kweh, Hock Leong wrote:
> From: "Kweh, Hock Leong" 
> 
> Introduce this new API for loading firmware from a specific location
> instead of /lib/firmware/ by providing a full path to the firmware
> file.

Ick, why would we want this?

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Greg Kroah-Hartman]

On Tue, Apr 14, 2015 at 05:44:56PM +0800, Kweh, Hock Leong wrote:
> From: "Kweh, Hock Leong" 
> 
> Introducing a kernel module to expose capsule loader interface
> for user to upload capsule binaries. This module leverage the
> request_firmware_direct_full_path() to obtain the binary at a
> specific path input by user.
> 
> Example method to load the capsule binary:
> echo -n "/path/to/capsule/binary" > 
> /sys/devices/platform/efi_capsule_loader/capsule_loader

Ick, why not just have the firmware file location present, and copy it
to the sysfs file directly from userspace, instead of this two-step
process?

> +/*
> + * To remove this kernel module, just perform:
> + * rmmod efi_capsule_loader.ko

This comment is not needed.


> + */
> +static void __exit efi_capsule_loader_exit(void)
> +{
> + platform_device_unregister(efi_capsule_pdev);

This is not a platform device, don't abuse that interface please.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/2] firmware_loader: introduce new API - request_firmware_direct_full_path()

[Greg Kroah-Hartman]

On Tue, Apr 14, 2015 at 11:56:26AM -0400, Andy Lutomirski wrote:
> On Tue, Apr 14, 2015 at 10:08 AM, Greg Kroah-Hartman
>  wrote:
> > On Tue, Apr 14, 2015 at 05:44:55PM +0800, Kweh, Hock Leong wrote:
> >> From: "Kweh, Hock Leong" 
> >>
> >> Introduce this new API for loading firmware from a specific location
> >> instead of /lib/firmware/ by providing a full path to the firmware
> >> file.
> >
> > Ick, why would we want this?
> >
> 
> Because this mechanism should still work even if /lib is unwriteable
> (e.g it's on squashfs or a read-only NFS root).

Why would a filesystem need to be writable to read a firmware blob from?

> In this regard, UEFI capsules are very much unlike firmware_class
> firmware.  firmware_class firmwise is kind of like device drivers; it
> generally comes from the same vendor as your kernel image and
> /lib/modules, and it can be updated by the same mechanism.  UEFI
> capsules, on the other hand, are one-time things that should be loaded
> at the explicit request of the admin.

Just like BIOS updates, which use the firmware interface.

> There is no reason whatsoever
> that they should exist on persistent storage, and, in fact, there's a
> very good reason that they should not.  On little embedded devices,
> which will apparently be the initial users of this code, keeping the
> capsules around is a waste of valuable space.
> 
> This is why I think that the right approach would be to avoid using
> firmware_class entirely for this.  IMO a simple_char device would be
> the way to go (hint hint...) but other simple approaches are certainly
> possible.

A char device would be present all the time, like a sysfs file to write
the firmware to, so I don't see the difference here.  For a char device,
you would just do the normal open/write/close, just like for the
firmware interface, what is the difference?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Greg Kroah-Hartman]

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 05:44:56PM +0800, Kweh, Hock Leong wrote:
> > > From: "Kweh, Hock Leong" 
> > >
> > > Introducing a kernel module to expose capsule loader interface
> > > for user to upload capsule binaries. This module leverage the
> > > request_firmware_direct_full_path() to obtain the binary at a
> > > specific path input by user.
> > >
> > > Example method to load the capsule binary:
> > > echo -n "/path/to/capsule/binary" >
> > /sys/devices/platform/efi_capsule_loader/capsule_loader
> > 
> > Ick, why not just have the firmware file location present, and copy it
> > to the sysfs file directly from userspace, instead of this two-step
> > process?
> 
> Err  I may not catch your meaning correctly. Are you trying to say
> that you would prefer the user to perform:
> 
> cat file.bin > /sys/.../capsule_loader
> 
> instead of
> 
> echo -n "/path/to/binary" > /sys//capsule_laoder

Yes.  What's the namespace of your /path/to/binary/ and how do you know
the kernel has the same one when it does the firmware load call?  By
just copying the data with 'cat', you don't have to worry about
namespace issues at all.

> The reason we stick with the firmware_class is because we don't
> want to replicate a code which already mature and has open API
> for developer to use.

That's fine, but adding a new api to the firmware interface seems odd to
me, just because you don't like using /lib/ or any of the other
"standard" locations for firmware blobs.  And note, that path is
configurable.

> > > + */
> > > +static void __exit efi_capsule_loader_exit(void)
> > > +{
> > > + platform_device_unregister(efi_capsule_pdev);
> > 
> > This is not a platform device, don't abuse that interface please.
> > 
> > greg k-h
> 
> Okay, so you would recommend to use device_register() for this case?
> Or you would think that this is more suitable to use class_register()?

A class isn't needed, you just want a device right?  So just use a
device, but not a platform device, as that isn't what you have here.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Greg Kroah-Hartman]

On Tue, Apr 14, 2015 at 11:52:48AM -0400, Andy Lutomirski wrote:
> On Tue, Apr 14, 2015 at 10:09 AM, Greg Kroah-Hartman
>  wrote:
> > On Tue, Apr 14, 2015 at 05:44:56PM +0800, Kweh, Hock Leong wrote:
> >> From: "Kweh, Hock Leong" 
> >>
> >> Introducing a kernel module to expose capsule loader interface
> >> for user to upload capsule binaries. This module leverage the
> >> request_firmware_direct_full_path() to obtain the binary at a
> >> specific path input by user.
> >>
> >> Example method to load the capsule binary:
> >> echo -n "/path/to/capsule/binary" > 
> >> /sys/devices/platform/efi_capsule_loader/capsule_loader
> >
> > Ick, why not just have the firmware file location present, and copy it
> > to the sysfs file directly from userspace, instead of this two-step
> > process?
> 
> Because it's not at all obvious how error handling should work in that case.

I don't understand how the error handling is any different.  The kernel
ends up copying the data in through the firmware interface both ways, we
just aren't creating yet-another-firmware-path in the system.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Greg Kroah-Hartman]

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 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 05:44:56PM +0800, Kweh, Hock Leong wrote:
> > > > > From: "Kweh, Hock Leong" 
> > > > >
> > > > > Introducing a kernel module to expose capsule loader interface
> > > > > for user to upload capsule binaries. This module leverage the
> > > > > request_firmware_direct_full_path() to obtain the binary at a
> > > > > specific path input by user.
> > > > >
> > > > > Example method to load the capsule binary:
> > > > > echo -n "/path/to/capsule/binary" >
> > > > /sys/devices/platform/efi_capsule_loader/capsule_loader
> > > >
> > > > Ick, why not just have the firmware file location present, and copy it
> > > > to the sysfs file directly from userspace, instead of this two-step
> > > > process?
> > >
> > > Err  I may not catch your meaning correctly. Are you trying to say
> > > that you would prefer the user to perform:
> > >
> > > cat file.bin > /sys/.../capsule_loader
> > >
> > > instead of
> > >
> > > echo -n "/path/to/binary" > /sys//capsule_laoder
> > 
> > Yes.  What's the namespace of your /path/to/binary/ and how do you know
> > the kernel has the same one when it does the firmware load call?  By
> > just copying the data with 'cat', you don't have to worry about
> > namespace issues at all.
> 
> Hi Greg,
> 
> Let me double confirm that I understand your concern correctly. You are
> trying to tell that some others module may use a 'same' namespace to
> request the firmware but never release it. Then when our module trying
> to request the firmware by passing in the 'same' namespace, I will get the
> previous data instead of the current binary data from the path I want.

Yes.

> Hmm  I believe this concern also apply to all the current request_firmware
> APIs right? And I believe the coincidence to have 'same' file name namespace
> would be higher than full path namespace.

Not really, the kernel namespace is what matters at that point in time.

And maybe it does matter, I haven't thought through all of the issues.
But passing a path from userspace, to the kernel, to have the kernel
turn around again and use that path is full of nasty consequences at
times due to namespaces, let's avoid all of that please.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Greg Kroah-Hartman]

On Mon, Apr 20, 2015 at 03:28:32AM +, Kweh, Hock Leong wrote:
> Regarding the 'reboot require' status, is it critical to have a 1 to 1 status 
> match
> with the capsule upload binary? Is it okay to have one sysfs file note to 
> tell the
> overall status (for example: 10 capsule binaries uploaded but one require
> reboot, so the status shows reboot require is yes)? I am not here trying to 
> argue
> anything. I am just trying to find out what kind of info is needed but the 
> sysfs
> could not provide. 
> 
> Please imagine if your whole Linux system (kernel + rootfs) has to fit into 
> 6MB
> space and you don't even have the gcc compiler included into the package.
> I believe in this environment, kernel interface + shell command is the only
> interaction that user could work with.

Why would you have to have gcc on such a system?  Why is that a
requirement for having an ioctl/char interface?

And if you only have 6Mb of space, you don't have UEFI, sorry, there's
no way that firmware can get that small.

> Btw, just to make sure I get it correctly, is misc device refer to the device
> that created by misc_register() from drivers/char/misc.c and not asked to
> put this kernel module under drivers/misc/* location, right?

Yes, use misc_register()

> And Matt mentioned including the source into tools/* in kernel tree. I have
> a question: Is this tool can be compiled during kernel compilation and
> eventually auto included into the rootfs package? Sorry, I am new to OS
> creation and maybe this is stupid question.

If you ask to build it as part of the configuration, yes, it can be
built.  See how the tools are build as part of the kernel tree for more
information about this.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Greg Kroah-Hartman]

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 03:28:32AM +, Kweh, Hock Leong wrote:
> > > Regarding the 'reboot require' status, is it critical to have a 1 to 1 
> > > status
> > match
> > > with the capsule upload binary? Is it okay to have one sysfs file note to 
> > > tell
> > the
> > > overall status (for example: 10 capsule binaries uploaded but one require
> > > reboot, so the status shows reboot require is yes)? I am not here trying 
> > > to
> > argue
> > > anything. I am just trying to find out what kind of info is needed but the
> > sysfs
> > > could not provide.
> > >
> > > Please imagine if your whole Linux system (kernel + rootfs) has to fit 
> > > into
> > 6MB
> > > space and you don't even have the gcc compiler included into the package.
> > > I believe in this environment, kernel interface + shell command is the 
> > > only
> > > interaction that user could work with.
> > 
> > Why would you have to have gcc on such a system?  Why is that a
> > requirement for having an ioctl/char interface?
> 
> This is my logic:
> - Besides writing a C program (for example), I am not aware any shell script
>   could perform an ioctl function call. This led me to if I don't have an 
> execution
>   binary then I need a compiler to compile the source to execution binary.

You would have built it on a separate machine, like the one you used to
build your kernel and other binary packages you are running.

> - For embedded product as mentioned above, not all vendors willing to carry
>   the userland tool when they are struggling to fit into small memory space.
>   Yet, you may say this tool would not eat up a lot of space compare to 
> others.
>   But when the source of this tool being upstream-ed to the tools/ kernel 
> tree,
>   we cannot stop people to contribute and make the tool more features support,
>   eventually the embedded product may need to drop the tool.

So because someday in the future someone might make the code that is
open source too big for us to use, we are going to reject the idea
today?  That really doesn't make any sense.

> > And if you only have 6Mb of space, you don't have UEFI, sorry, there's
> > no way that firmware can get that small.
> 
> Actually there is. Quark is one of the examples. The kernel + rootfs take
> up 6MB and the UEFI consume only 2MB, so total size 8MB in the spi chip.
> If you have an Intel Galileo board, you don't need any mass storage (SD & 
> USB),
> you are able to boot to Linux console.

Does Galieleo support this UEFI feature?  If so, great, how big is a
binary that can read a file and write the data using an ioctl?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Greg Kroah-Hartman]

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-----
> > > > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> > > > Sent: Tuesday, April 14, 2015 10:09 PM
> > > > 
> > > > On Tue, Apr 14, 2015 at 05:44:56PM +0800, Kweh, Hock Leong wrote:
> > > > > + */
> > > > > +static void __exit efi_capsule_loader_exit(void)
> > > > > +{
> > > > > + platform_device_unregister(efi_capsule_pdev);
> > > > 
> > > > This is not a platform device, don't abuse that interface please.
> > > > 
> > > > greg k-h
> > > 
> > > Okay, so you would recommend to use device_register() for this case?
> > > Or you would think that this is more suitable to use class_register()?
> > 
> > A class isn't needed, you just want a device right?  So just use a
> > device, but not a platform device, as that isn't what you have here.
> 
> Coming back to this, am I the only one confused here?  What is a
> 'platform device' then?  Because if it doesn't fit a direct channel to
> the platform firmware, which seems to be one of the definitions covered
> in driver-model/platform.txt under devices with minimal infrastructure
> then perhaps the documentation needs updating.

I don't remember the original code here at all, sorry.  I'm guessing
that they were using a class, and a platform device together, which is
not a good idea.  Just make a "virtual" device, as you don't need/want
any of the platform device infrastructure here, you just wanted a device
node and/or a way to show up in sysfs somewhere.

If you have some kind of "platform resource", then you can be a platform
device, otherwise please don't use that api just because it seems simple
to use.  Use the ones the driver core provides for you that really are
just as simple (i.e. device_create()).

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Greg Kroah-Hartman]

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, 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 05:44:56PM +0800, Kweh, Hock Leong wrote:
> > > > > > > + */
> > > > > > > +static void __exit efi_capsule_loader_exit(void)
> > > > > > > +{
> > > > > > > + platform_device_unregister(efi_capsule_pdev);
> > > > > > 
> > > > > > This is not a platform device, don't abuse that interface please.
> > > > > > 
> > > > > > greg k-h
> > > > > 
> > > > > Okay, so you would recommend to use device_register() for this case?
> > > > > Or you would think that this is more suitable to use class_register()?
> > > > 
> > > > A class isn't needed, you just want a device right?  So just use a
> > > > device, but not a platform device, as that isn't what you have here.
> > > 
> > > Coming back to this, am I the only one confused here?  What is a
> > > 'platform device' then?  Because if it doesn't fit a direct channel to
> > > the platform firmware, which seems to be one of the definitions covered
> > > in driver-model/platform.txt under devices with minimal infrastructure
> > > then perhaps the documentation needs updating.
> > 
> > I don't remember the original code here at all, sorry.  I'm guessing
> > that they were using a class, and a platform device together, which is
> > not a good idea.  Just make a "virtual" device, as you don't need/want
> > any of the platform device infrastructure here, you just wanted a device
> > node and/or a way to show up in sysfs somewhere.
> 
> It was a platform device called efi_platform_loader and a single
> attribute file in that device called  capsule_load.  I agree that if
> we're going to use this for other things, we should probably have a uefi
> directory somewhere (under firmware?) to collect everything together
> rather than spraying random devices around.
> 
> > If you have some kind of "platform resource", then you can be a platform
> > device, otherwise please don't use that api just because it seems simple
> > to use.  Use the ones the driver core provides for you that really are
> > just as simple (i.e. device_create()).
> 
> OK, so this is what I'm trying to understand.  Why isn't a pipe to
> firmware for something a "platform resource"?  I think UEFI is in the
> same class as ACPI which uses platform devices all over.

And I hate the fact that ACPI did that, but that ship has sailed a long
time ago.  It "should" have been it's own bus and device type, but oh
well.

For a "simple" bus-less device, that has no platform resources needed
(i.e from acpi or device tree), so you don't need the infrastructure
from the platform core, just use a simple device_create() call, that's
what it is there for.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Greg Kroah-Hartman]

On Thu, Apr 23, 2015 at 09:14:18AM -0700, James Bottomley wrote:
> > > OK, so this is what I'm trying to understand.  Why isn't a pipe to
> > > firmware for something a "platform resource"?  I think UEFI is in the
> > > same class as ACPI which uses platform devices all over.
> > 
> > And I hate the fact that ACPI did that, but that ship has sailed a long
> > time ago.  It "should" have been it's own bus and device type, but oh
> > well.
> > 
> > For a "simple" bus-less device, that has no platform resources needed
> > (i.e from acpi or device tree), so you don't need the infrastructure
> > from the platform core, just use a simple device_create() call, that's
> > what it is there for.
> 
> That's not confusing: ACPI shouldn't be a platform device, but something
> that is should have a platform resource provided by ACPI (or device tree).
> 
> So I think the problem is that the documentation is wrong?  Platform
> device isn't for "platform resources" like you said initially?
> 
> Or do we have a more fundamental problem: You don't use the word
> "platform" the same way we do?  A "platform" to most people on this
> thread is something designed to be delivered with the box that's not
> amenable to user modification.  That's why we think of UEFI (and ACPI)
> as platform technologies: they come with the box (often they were
> specially crafted for it) and we use their services to discover stuff
> and correctly configure the OS.  In this definition, almost everything
> we do via UEFI manipulates "platform resources".

Maybe we aren't using the word "platform" the same way.

Platform devices were originally created to handle all of the "cruft"
that a system has that used to be only at fixed locations on the
CPU/chipset, and were not on any real "bus".  Things like timers,
keyboard controllers, and all of the odd embedded things that we just
"knew" where in memory they were located.

Then we got platform data structures, to help know "where" in memory
devices were to be able to write to, and board files interacted with
them that way.

Because of this, and how they were just so easy to create, lots of
developers were "lazy" and just put a platform device into their driver
instead of having to hook it up to an existing system, or actually write
a bus for it (I had an Intel laptop that shipped 1 year ago come with a
driver that used a platform device instead of a "real" i2c device like
the touchpad really was.

Then came device tree, which leveraged platform devices because that's
what they needed to control (replacing the board files.)  Somewhere in
there ACPI also decided to use platform devices and it makes sense now,
as drivers just need to get a resource as to how to talk to the
hardware, and it doesn't matter if it comes from ACPI or device tree.

But for devices that are just "virtual", like this firmware loader, use
the virtual bus, which happens automatically when you don't provide a
parent to device_create().  That's what it is there for, your device
doesn't have to deal with any "resources" that it needs to read from
board files, device tree, or acpi, so it shouldn't be a platform device.

Hope that helps explain things better.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/3] sysfs,kernfs: add flush operation

[Greg Kroah-Hartman]

On Wed, Apr 29, 2015 at 04:09:45PM -0700, James Bottomley wrote:
> From: James Bottomley 
> 
> This is necessary to allow sysfs operations to return error in close (we are
> using close to initiate and return a possible error from a transaction).
> 
> Signed-off-by: James Bottomley 

Are there any side-affects now that we have a flush() call for binary
files that the vfs will act differently from not defining one at all?

if not, no objection to me for this change.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4.10 19/48] efi/arm: Fix boot crash with CONFIG_CPUMASK_OFFSTACK=y

[Greg Kroah-Hartman]

4.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Ard Biesheuvel 

commit d1eb98143c56f24fef125f5bbed49ae0b52fb7d6 upstream.

On ARM and arm64, we use a dedicated mm_struct to map the UEFI
Runtime Services regions, which allows us to map those regions
on demand, and in a way that is guaranteed to be compatible
with incoming kernels across kexec.

As it turns out, we don't fully initialize the mm_struct in the
same way as process mm_structs are initialized on fork(), which
results in the following crash on ARM if CONFIG_CPUMASK_OFFSTACK=y
is enabled:

  ...
  EFI Variables Facility v0.08 2004-May-17
  Unable to handle kernel NULL pointer dereference at virtual address 
  [...]
  Process swapper/0 (pid: 1)
  ...
  __memzero()
  check_and_switch_context()
  virt_efi_get_next_variable()
  efivar_init()
  efivars_sysfs_init()
  do_one_initcall()
  ...

This is due to a missing call to mm_init_cpumask(), so add it.

Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1488395154-29786-1-git-send-email-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/firmware/efi/arm-runtime.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -65,6 +65,7 @@ static bool __init efi_virtmap_init(void
bool systab_found;
 
efi_mm.pgd = pgd_alloc(&efi_mm);
+   mm_init_cpumask(&efi_mm);
init_new_context(NULL, &efi_mm);
 
systab_found = false;


--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4.9 18/44] efi/arm: Fix boot crash with CONFIG_CPUMASK_OFFSTACK=y

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Ard Biesheuvel 

commit d1eb98143c56f24fef125f5bbed49ae0b52fb7d6 upstream.

On ARM and arm64, we use a dedicated mm_struct to map the UEFI
Runtime Services regions, which allows us to map those regions
on demand, and in a way that is guaranteed to be compatible
with incoming kernels across kexec.

As it turns out, we don't fully initialize the mm_struct in the
same way as process mm_structs are initialized on fork(), which
results in the following crash on ARM if CONFIG_CPUMASK_OFFSTACK=y
is enabled:

  ...
  EFI Variables Facility v0.08 2004-May-17
  Unable to handle kernel NULL pointer dereference at virtual address 
  [...]
  Process swapper/0 (pid: 1)
  ...
  __memzero()
  check_and_switch_context()
  virt_efi_get_next_variable()
  efivar_init()
  efivars_sysfs_init()
  do_one_initcall()
  ...

This is due to a missing call to mm_init_cpumask(), so add it.

Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1488395154-29786-1-git-send-email-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/firmware/efi/arm-runtime.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -65,6 +65,7 @@ static bool __init efi_virtmap_init(void
bool systab_found;
 
efi_mm.pgd = pgd_alloc(&efi_mm);
+   mm_init_cpumask(&efi_mm);
init_new_context(NULL, &efi_mm);
 
systab_found = false;


--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4.10 65/81] x86/mm/KASLR: Exclude EFI region from KASLR VA space randomization

[Greg Kroah-Hartman]

4.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Baoquan He 

commit a46f60d76004965e5669dbf3fc21ef3bc3632eb4 upstream.

Currently KASLR is enabled on three regions: the direct mapping of physical
memory, vamlloc and vmemmap. However the EFI region is also mistakenly
included for VA space randomization because of misusing EFI_VA_START macro
and assuming EFI_VA_START < EFI_VA_END.

(This breaks kexec and possibly other things that rely on stable addresses.)

The EFI region is reserved for EFI runtime services virtual mapping which
should not be included in KASLR ranges. In Documentation/x86/x86_64/mm.txt,
we can see:

  ffef - fffe (=64 GB) EFI region mapping space

EFI uses the space from -4G to -64G thus EFI_VA_START > EFI_VA_END,
Here EFI_VA_START = -4G, and EFI_VA_END = -64G.

Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this problem.

Signed-off-by: Baoquan He 
Reviewed-by: Bhupesh Sharma 
Acked-by: Dave Young 
Acked-by: Thomas Garnier 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Ard Biesheuvel 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Masahiro Yamada 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1490331592-31860-1-git-send-email-...@redhat.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/mm/kaslr.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -48,7 +48,7 @@ static const unsigned long vaddr_start =
 #if defined(CONFIG_X86_ESPFIX64)
 static const unsigned long vaddr_end = ESPFIX_BASE_ADDR;
 #elif defined(CONFIG_EFI)
-static const unsigned long vaddr_end = EFI_VA_START;
+static const unsigned long vaddr_end = EFI_VA_END;
 #else
 static const unsigned long vaddr_end = __START_KERNEL_map;
 #endif
@@ -105,7 +105,7 @@ void __init kernel_randomize_memory(void
 */
BUILD_BUG_ON(vaddr_start >= vaddr_end);
BUILD_BUG_ON(IS_ENABLED(CONFIG_X86_ESPFIX64) &&
-vaddr_end >= EFI_VA_START);
+vaddr_end >= EFI_VA_END);
BUILD_BUG_ON((IS_ENABLED(CONFIG_X86_ESPFIX64) ||
  IS_ENABLED(CONFIG_EFI)) &&
 vaddr_end >= __START_KERNEL_map);


--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4.9 58/72] x86/mm/KASLR: Exclude EFI region from KASLR VA space randomization

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Baoquan He 

commit a46f60d76004965e5669dbf3fc21ef3bc3632eb4 upstream.

Currently KASLR is enabled on three regions: the direct mapping of physical
memory, vamlloc and vmemmap. However the EFI region is also mistakenly
included for VA space randomization because of misusing EFI_VA_START macro
and assuming EFI_VA_START < EFI_VA_END.

(This breaks kexec and possibly other things that rely on stable addresses.)

The EFI region is reserved for EFI runtime services virtual mapping which
should not be included in KASLR ranges. In Documentation/x86/x86_64/mm.txt,
we can see:

  ffef - fffe (=64 GB) EFI region mapping space

EFI uses the space from -4G to -64G thus EFI_VA_START > EFI_VA_END,
Here EFI_VA_START = -4G, and EFI_VA_END = -64G.

Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this problem.

Signed-off-by: Baoquan He 
Reviewed-by: Bhupesh Sharma 
Acked-by: Dave Young 
Acked-by: Thomas Garnier 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Ard Biesheuvel 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Masahiro Yamada 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1490331592-31860-1-git-send-email-...@redhat.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/mm/kaslr.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -48,7 +48,7 @@ static const unsigned long vaddr_start =
 #if defined(CONFIG_X86_ESPFIX64)
 static const unsigned long vaddr_end = ESPFIX_BASE_ADDR;
 #elif defined(CONFIG_EFI)
-static const unsigned long vaddr_end = EFI_VA_START;
+static const unsigned long vaddr_end = EFI_VA_END;
 #else
 static const unsigned long vaddr_end = __START_KERNEL_map;
 #endif
@@ -105,7 +105,7 @@ void __init kernel_randomize_memory(void
 */
BUILD_BUG_ON(vaddr_start >= vaddr_end);
BUILD_BUG_ON(IS_ENABLED(CONFIG_X86_ESPFIX64) &&
-vaddr_end >= EFI_VA_START);
+vaddr_end >= EFI_VA_END);
BUILD_BUG_ON((IS_ENABLED(CONFIG_X86_ESPFIX64) ||
  IS_ENABLED(CONFIG_EFI)) &&
 vaddr_end >= __START_KERNEL_map);


--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4.9 24/69] efi/libstub: Skip GOP with PIXEL_BLT_ONLY format

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Cohen, Eugene 

commit 540f4c0e894f7e46a66dfa424b16424cbdc12c38 upstream.

The UEFI Specification permits Graphics Output Protocol (GOP) instances
without direct framebuffer access. This is indicated in the Mode structure
with a PixelFormat enumeration value of PIXEL_BLT_ONLY. Given that the
kernel does not know how to drive a Blt() only framebuffer (which is only
permitted before ExitBootServices() anyway), we should disregard such
framebuffers when looking for a GOP instance that is suitable for use as
the boot console.

So modify the EFI GOP initialization to not use a PIXEL_BLT_ONLY instance,
preventing attempts later in boot to use an invalid screen_info.lfb_base
address.

Signed-off-by: Eugene Cohen 
[ Moved the Blt() only check into the loop and clarified that Blt() only GOPs 
are unusable by the kernel. ]
Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: leif.lindh...@linaro.org
Cc: linux-efi@vger.kernel.org
Cc: lorenzo.pieral...@arm.com
Fixes: 9822504c1fa5 ("efifb: Enable the efi-framebuffer platform driver ...")
Link: http://lkml.kernel.org/r/20170404152744.26687-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/firmware/efi/libstub/gop.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/firmware/efi/libstub/gop.c
+++ b/drivers/firmware/efi/libstub/gop.c
@@ -149,7 +149,8 @@ setup_gop32(efi_system_table_t *sys_tabl
 
status = __gop_query32(sys_table_arg, gop32, &info, &size,
   ¤t_fb_base);
-   if (status == EFI_SUCCESS && (!first_gop || conout_found)) {
+   if (status == EFI_SUCCESS && (!first_gop || conout_found) &&
+   info->pixel_format != PIXEL_BLT_ONLY) {
/*
 * Systems that use the UEFI Console Splitter may
 * provide multiple GOP devices, not all of which are
@@ -266,7 +267,8 @@ setup_gop64(efi_system_table_t *sys_tabl
 
status = __gop_query64(sys_table_arg, gop64, &info, &size,
   ¤t_fb_base);
-   if (status == EFI_SUCCESS && (!first_gop || conout_found)) {
+   if (status == EFI_SUCCESS && (!first_gop || conout_found) &&
+   info->pixel_format != PIXEL_BLT_ONLY) {
/*
 * Systems that use the UEFI Console Splitter may
 * provide multiple GOP devices, not all of which are


--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4.9 25/69] efi/fb: Avoid reconfiguration of BAR that covers the framebuffer

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Ard Biesheuvel 

commit 55d728a40d368ba80443be85c02e641fc9082a3f upstream.

On UEFI systems, the PCI subsystem is enumerated by the firmware,
and if a graphical framebuffer is exposed via a PCI device, its base
address and size are exposed to the OS via the Graphics Output
Protocol (GOP).

On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
scratch at boot. This may result in the GOP framebuffer address to
become stale, if the BAR covering the framebuffer is modified. This
will cause the framebuffer to become unresponsive, and may in some
cases result in unpredictable behavior if the range is reassigned to
another device.

So add a non-x86 quirk to the EFI fb driver to find the BAR associated
with the GOP base address, and claim the BAR resource so that the PCI
core will not move it.

Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: leif.lindh...@linaro.org
Cc: linux-efi@vger.kernel.org
Cc: lorenzo.pieral...@arm.com
Fixes: 9822504c1fa5 ("efifb: Enable the efi-framebuffer platform driver ...")
Link: http://lkml.kernel.org/r/20170404152744.26687-3-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/video/fbdev/efifb.c |   66 +++-
 1 file changed, 65 insertions(+), 1 deletion(-)

--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -118,6 +119,8 @@ static inline bool fb_base_is_valid(void
return false;
 }
 
+static bool pci_dev_disabled;  /* FB base matches BAR of a disabled device */
+
 static int efifb_probe(struct platform_device *dev)
 {
struct fb_info *info;
@@ -127,7 +130,7 @@ static int efifb_probe(struct platform_d
unsigned int size_total;
char *option = NULL;
 
-   if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
+   if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
return -ENODEV;
 
if (fb_get_options("efifb", &option))
@@ -327,3 +330,64 @@ static struct platform_driver efifb_driv
 };
 
 builtin_platform_driver(efifb_driver);
+
+#if defined(CONFIG_PCI) && !defined(CONFIG_X86)
+
+static bool pci_bar_found; /* did we find a BAR matching the efifb base? */
+
+static void claim_efifb_bar(struct pci_dev *dev, int idx)
+{
+   u16 word;
+
+   pci_bar_found = true;
+
+   pci_read_config_word(dev, PCI_COMMAND, &word);
+   if (!(word & PCI_COMMAND_MEMORY)) {
+   pci_dev_disabled = true;
+   dev_err(&dev->dev,
+   "BAR %d: assigned to efifb but device is disabled!\n",
+   idx);
+   return;
+   }
+
+   if (pci_claim_resource(dev, idx)) {
+   pci_dev_disabled = true;
+   dev_err(&dev->dev,
+   "BAR %d: failed to claim resource for efifb!\n", idx);
+   return;
+   }
+
+   dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx);
+}
+
+static void efifb_fixup_resources(struct pci_dev *dev)
+{
+   u64 base = screen_info.lfb_base;
+   u64 size = screen_info.lfb_size;
+   int i;
+
+   if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
+   return;
+
+   if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
+   base |= (u64)screen_info.ext_lfb_base << 32;
+
+   if (!base)
+   return;
+
+   for (i = 0; i < PCI_STD_RESOURCE_END; i++) {
+   struct resource *res = &dev->resource[i];
+
+   if (!(res->flags & IORESOURCE_MEM))
+   continue;
+
+   if (res->start <= base && res->end >= base + size - 1) {
+   claim_efifb_bar(dev, i);
+   break;
+   }
+   }
+}
+DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY,
+  16, efifb_fixup_resources);
+
+#endif


--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4.9 16/69] x86/efi: Dont try to reserve runtime regions

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Omar Sandoval 

commit 6f6266a561306e206e0e31a5038f029b6a7b1d89 upstream.

Reserving a runtime region results in splitting the EFI memory
descriptors for the runtime region. This results in runtime region
descriptors with bogus memory mappings, leading to interesting crashes
like the following during a kexec:

  general protection fault:  [#1] SMP
  Modules linked in:
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1 #53
  Hardware name: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05   09/30/2016
  RIP: 0010:virt_efi_set_variable()
  ...
  Call Trace:
   efi_delete_dummy_variable()
   efi_enter_virtual_mode()
   start_kernel()
   ? set_init_arg()
   x86_64_start_reservations()
   x86_64_start_kernel()
   start_cpu()
  ...
  Kernel panic - not syncing: Fatal exception

Runtime regions will not be freed and do not need to be reserved, so
skip the memmap modification in this case.

Signed-off-by: Omar Sandoval 
Signed-off-by: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Dave Young 
Cc: Linus Torvalds 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 8e80632fb23f ("efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()")
Link: http://lkml.kernel.org/r/20170412152719.9779-2-m...@codeblueprint.co.uk
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/platform/efi/quirks.c |4 
 1 file changed, 4 insertions(+)

--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -201,6 +201,10 @@ void __init efi_arch_mem_reserve(phys_ad
return;
}
 
+   /* No need to reserve regions that will never be freed. */
+   if (md.attribute & EFI_MEMORY_RUNTIME)
+   return;
+
size += addr % EFI_PAGE_SIZE;
size = round_up(size, EFI_PAGE_SIZE);
addr = round_down(addr, EFI_PAGE_SIZE);


--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4.10 32/69] efi/fb: Avoid reconfiguration of BAR that covers the framebuffer

[Greg Kroah-Hartman]

4.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Ard Biesheuvel 

commit 55d728a40d368ba80443be85c02e641fc9082a3f upstream.

On UEFI systems, the PCI subsystem is enumerated by the firmware,
and if a graphical framebuffer is exposed via a PCI device, its base
address and size are exposed to the OS via the Graphics Output
Protocol (GOP).

On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
scratch at boot. This may result in the GOP framebuffer address to
become stale, if the BAR covering the framebuffer is modified. This
will cause the framebuffer to become unresponsive, and may in some
cases result in unpredictable behavior if the range is reassigned to
another device.

So add a non-x86 quirk to the EFI fb driver to find the BAR associated
with the GOP base address, and claim the BAR resource so that the PCI
core will not move it.

Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: leif.lindh...@linaro.org
Cc: linux-efi@vger.kernel.org
Cc: lorenzo.pieral...@arm.com
Fixes: 9822504c1fa5 ("efifb: Enable the efi-framebuffer platform driver ...")
Link: http://lkml.kernel.org/r/20170404152744.26687-3-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/video/fbdev/efifb.c |   66 +++-
 1 file changed, 65 insertions(+), 1 deletion(-)

--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -143,6 +144,8 @@ static struct attribute *efifb_attrs[] =
 };
 ATTRIBUTE_GROUPS(efifb);
 
+static bool pci_dev_disabled;  /* FB base matches BAR of a disabled device */
+
 static int efifb_probe(struct platform_device *dev)
 {
struct fb_info *info;
@@ -152,7 +155,7 @@ static int efifb_probe(struct platform_d
unsigned int size_total;
char *option = NULL;
 
-   if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
+   if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
return -ENODEV;
 
if (fb_get_options("efifb", &option))
@@ -360,3 +363,64 @@ static struct platform_driver efifb_driv
 };
 
 builtin_platform_driver(efifb_driver);
+
+#if defined(CONFIG_PCI) && !defined(CONFIG_X86)
+
+static bool pci_bar_found; /* did we find a BAR matching the efifb base? */
+
+static void claim_efifb_bar(struct pci_dev *dev, int idx)
+{
+   u16 word;
+
+   pci_bar_found = true;
+
+   pci_read_config_word(dev, PCI_COMMAND, &word);
+   if (!(word & PCI_COMMAND_MEMORY)) {
+   pci_dev_disabled = true;
+   dev_err(&dev->dev,
+   "BAR %d: assigned to efifb but device is disabled!\n",
+   idx);
+   return;
+   }
+
+   if (pci_claim_resource(dev, idx)) {
+   pci_dev_disabled = true;
+   dev_err(&dev->dev,
+   "BAR %d: failed to claim resource for efifb!\n", idx);
+   return;
+   }
+
+   dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx);
+}
+
+static void efifb_fixup_resources(struct pci_dev *dev)
+{
+   u64 base = screen_info.lfb_base;
+   u64 size = screen_info.lfb_size;
+   int i;
+
+   if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
+   return;
+
+   if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
+   base |= (u64)screen_info.ext_lfb_base << 32;
+
+   if (!base)
+   return;
+
+   for (i = 0; i < PCI_STD_RESOURCE_END; i++) {
+   struct resource *res = &dev->resource[i];
+
+   if (!(res->flags & IORESOURCE_MEM))
+   continue;
+
+   if (res->start <= base && res->end >= base + size - 1) {
+   claim_efifb_bar(dev, i);
+   break;
+   }
+   }
+}
+DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY,
+  16, efifb_fixup_resources);
+
+#endif


--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4.10 31/69] efi/libstub: Skip GOP with PIXEL_BLT_ONLY format

[Greg Kroah-Hartman]

4.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Cohen, Eugene 

commit 540f4c0e894f7e46a66dfa424b16424cbdc12c38 upstream.

The UEFI Specification permits Graphics Output Protocol (GOP) instances
without direct framebuffer access. This is indicated in the Mode structure
with a PixelFormat enumeration value of PIXEL_BLT_ONLY. Given that the
kernel does not know how to drive a Blt() only framebuffer (which is only
permitted before ExitBootServices() anyway), we should disregard such
framebuffers when looking for a GOP instance that is suitable for use as
the boot console.

So modify the EFI GOP initialization to not use a PIXEL_BLT_ONLY instance,
preventing attempts later in boot to use an invalid screen_info.lfb_base
address.

Signed-off-by: Eugene Cohen 
[ Moved the Blt() only check into the loop and clarified that Blt() only GOPs 
are unusable by the kernel. ]
Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: leif.lindh...@linaro.org
Cc: linux-efi@vger.kernel.org
Cc: lorenzo.pieral...@arm.com
Fixes: 9822504c1fa5 ("efifb: Enable the efi-framebuffer platform driver ...")
Link: http://lkml.kernel.org/r/20170404152744.26687-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/firmware/efi/libstub/gop.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/firmware/efi/libstub/gop.c
+++ b/drivers/firmware/efi/libstub/gop.c
@@ -149,7 +149,8 @@ setup_gop32(efi_system_table_t *sys_tabl
 
status = __gop_query32(sys_table_arg, gop32, &info, &size,
   ¤t_fb_base);
-   if (status == EFI_SUCCESS && (!first_gop || conout_found)) {
+   if (status == EFI_SUCCESS && (!first_gop || conout_found) &&
+   info->pixel_format != PIXEL_BLT_ONLY) {
/*
 * Systems that use the UEFI Console Splitter may
 * provide multiple GOP devices, not all of which are
@@ -266,7 +267,8 @@ setup_gop64(efi_system_table_t *sys_tabl
 
status = __gop_query64(sys_table_arg, gop64, &info, &size,
   ¤t_fb_base);
-   if (status == EFI_SUCCESS && (!first_gop || conout_found)) {
+   if (status == EFI_SUCCESS && (!first_gop || conout_found) &&
+   info->pixel_format != PIXEL_BLT_ONLY) {
/*
 * Systems that use the UEFI Console Splitter may
 * provide multiple GOP devices, not all of which are


--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4.10 22/69] x86/efi: Dont try to reserve runtime regions

[Greg Kroah-Hartman]

4.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Omar Sandoval 

commit 6f6266a561306e206e0e31a5038f029b6a7b1d89 upstream.

Reserving a runtime region results in splitting the EFI memory
descriptors for the runtime region. This results in runtime region
descriptors with bogus memory mappings, leading to interesting crashes
like the following during a kexec:

  general protection fault:  [#1] SMP
  Modules linked in:
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1 #53
  Hardware name: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05   09/30/2016
  RIP: 0010:virt_efi_set_variable()
  ...
  Call Trace:
   efi_delete_dummy_variable()
   efi_enter_virtual_mode()
   start_kernel()
   ? set_init_arg()
   x86_64_start_reservations()
   x86_64_start_kernel()
   start_cpu()
  ...
  Kernel panic - not syncing: Fatal exception

Runtime regions will not be freed and do not need to be reserved, so
skip the memmap modification in this case.

Signed-off-by: Omar Sandoval 
Signed-off-by: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Dave Young 
Cc: Linus Torvalds 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 8e80632fb23f ("efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()")
Link: http://lkml.kernel.org/r/20170412152719.9779-2-m...@codeblueprint.co.uk
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/platform/efi/quirks.c |4 
 1 file changed, 4 insertions(+)

--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -201,6 +201,10 @@ void __init efi_arch_mem_reserve(phys_ad
return;
}
 
+   /* No need to reserve regions that will never be freed. */
+   if (md.attribute & EFI_MEMORY_RUNTIME)
+   return;
+
size += addr % EFI_PAGE_SIZE;
size = round_up(size, EFI_PAGE_SIZE);
addr = round_down(addr, EFI_PAGE_SIZE);


--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4.9 031/137] firmware/efi: Add NULL pointer checks in efivars API functions

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit ab2180a15ce54739fed381efb4cb12e78dfb1561 ]

Since commit:

   ce2e6db554fa ("brcmfmac: Add support for getting nvram contents from EFI 
variables")

we have a device driver accessing the efivars API. Several functions in
the efivars API assume __efivars is set, i.e., that they will be accessed
only after efivars_register() has been called. However, the following NULL
pointer access was reported calling efivar_entry_size() from the brcmfmac
device driver:

  Unable to handle kernel NULL pointer dereference at virtual address 0008
  pgd = 60bfa5f1
  [0008] *pgd=
  Internal error: Oops: 5 [#1] SMP ARM
  ...
  Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
  Workqueue: events request_firmware_work_func
  PC is at efivar_entry_size+0x28/0x90
  LR is at brcmf_fw_complete_request+0x3f8/0x8d4 [brcmfmac]
  pc : []lr : []psr: a00d0113
  sp : ede7fe28  ip : ee983410  fp : c1787f30
  r10:   r9 :   r8 : bf2b2258
  r7 : ee983000  r6 : c1604c48  r5 : ede7fe88  r4 : edf337c0
  r3 :   r2 :   r1 : ede7fe88  r0 : c17712c8
  Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
  Control: 10c5387d  Table: ad16804a  DAC: 0051

Disassembly showed that the local static variable __efivars is NULL,
which is not entirely unexpected given that it is a non-EFI platform.

So add a NULL pointer check to efivar_entry_size(), and to related
functions while at it. In efivars_register() a couple of sanity checks
are added as well.

Reported-by: Jon Hunter 
Signed-off-by: Arend van Spriel 
Signed-off-by: Ard Biesheuvel 
Cc: Andy Lutomirski 
Cc: Bhupesh Sharma 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: Eric Snowberg 
Cc: Hans de Goede 
Cc: Joe Perches 
Cc: Julien Thierry 
Cc: Linus Torvalds 
Cc: Marc Zyngier 
Cc: Matt Fleming 
Cc: Nathan Chancellor 
Cc: Peter Zijlstra 
Cc: Sai Praneeth Prakhya 
Cc: Sedat Dilek 
Cc: Thomas Gleixner 
Cc: YiFei Zhu 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20181129171230.18699-9-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/efi/vars.c | 99 +
 1 file changed, 78 insertions(+), 21 deletions(-)

diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
index 9336ffdf6e2c..fceaafd67ec6 100644
--- a/drivers/firmware/efi/vars.c
+++ b/drivers/firmware/efi/vars.c
@@ -318,7 +318,12 @@ EXPORT_SYMBOL_GPL(efivar_variable_is_removable);
 static efi_status_t
 check_var_size(u32 attributes, unsigned long size)
 {
-   const struct efivar_operations *fops = __efivars->ops;
+   const struct efivar_operations *fops;
+
+   if (!__efivars)
+   return EFI_UNSUPPORTED;
+
+   fops = __efivars->ops;
 
if (!fops->query_variable_store)
return EFI_UNSUPPORTED;
@@ -329,7 +334,12 @@ check_var_size(u32 attributes, unsigned long size)
 static efi_status_t
 check_var_size_nonblocking(u32 attributes, unsigned long size)
 {
-   const struct efivar_operations *fops = __efivars->ops;
+   const struct efivar_operations *fops;
+
+   if (!__efivars)
+   return EFI_UNSUPPORTED;
+
+   fops = __efivars->ops;
 
if (!fops->query_variable_store)
return EFI_UNSUPPORTED;
@@ -429,13 +439,18 @@ static void dup_variable_bug(efi_char16_t *str16, 
efi_guid_t *vendor_guid,
 int efivar_init(int (*func)(efi_char16_t *, efi_guid_t, unsigned long, void *),
void *data, bool duplicates, struct list_head *head)
 {
-   const struct efivar_operations *ops = __efivars->ops;
+   const struct efivar_operations *ops;
unsigned long variable_name_size = 1024;
efi_char16_t *variable_name;
efi_status_t status;
efi_guid_t vendor_guid;
int err = 0;
 
+   if (!__efivars)
+   return -EFAULT;
+
+   ops = __efivars->ops;
+
variable_name = kzalloc(variable_name_size, GFP_KERNEL);
if (!variable_name) {
printk(KERN_ERR "efivars: Memory allocation failed.\n");
@@ -583,12 +598,14 @@ static void efivar_entry_list_del_unlock(struct 
efivar_entry *entry)
  */
 int __efivar_entry_delete(struct efivar_entry *entry)
 {
-   const struct efivar_operations *ops = __efivars->ops;
efi_status_t status;
 
-   status = ops->set_variable(entry->var.VariableName,
-  &entry->var.VendorGuid,
-  0, 0, NULL);
+   if (!__efivars)
+   return -EINVAL;
+
+   status = __efivars->ops->set_variable(entry->var.VariableName,
+ &entry->var.VendorGuid,
+ 0, 0, NULL);
 
return efi_status_to_err(status);
 }
@@ -607,12 +624,17 @@ EXPORT_SYMBOL_GPL(__efivar_entry_delete);
  */
 int efivar_entry_delete

[PATCH 4.14 054/205] firmware/efi: Add NULL pointer checks in efivars API functions

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit ab2180a15ce54739fed381efb4cb12e78dfb1561 ]

Since commit:

   ce2e6db554fa ("brcmfmac: Add support for getting nvram contents from EFI 
variables")

we have a device driver accessing the efivars API. Several functions in
the efivars API assume __efivars is set, i.e., that they will be accessed
only after efivars_register() has been called. However, the following NULL
pointer access was reported calling efivar_entry_size() from the brcmfmac
device driver:

  Unable to handle kernel NULL pointer dereference at virtual address 0008
  pgd = 60bfa5f1
  [0008] *pgd=
  Internal error: Oops: 5 [#1] SMP ARM
  ...
  Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
  Workqueue: events request_firmware_work_func
  PC is at efivar_entry_size+0x28/0x90
  LR is at brcmf_fw_complete_request+0x3f8/0x8d4 [brcmfmac]
  pc : []lr : []psr: a00d0113
  sp : ede7fe28  ip : ee983410  fp : c1787f30
  r10:   r9 :   r8 : bf2b2258
  r7 : ee983000  r6 : c1604c48  r5 : ede7fe88  r4 : edf337c0
  r3 :   r2 :   r1 : ede7fe88  r0 : c17712c8
  Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
  Control: 10c5387d  Table: ad16804a  DAC: 0051

Disassembly showed that the local static variable __efivars is NULL,
which is not entirely unexpected given that it is a non-EFI platform.

So add a NULL pointer check to efivar_entry_size(), and to related
functions while at it. In efivars_register() a couple of sanity checks
are added as well.

Reported-by: Jon Hunter 
Signed-off-by: Arend van Spriel 
Signed-off-by: Ard Biesheuvel 
Cc: Andy Lutomirski 
Cc: Bhupesh Sharma 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: Eric Snowberg 
Cc: Hans de Goede 
Cc: Joe Perches 
Cc: Julien Thierry 
Cc: Linus Torvalds 
Cc: Marc Zyngier 
Cc: Matt Fleming 
Cc: Nathan Chancellor 
Cc: Peter Zijlstra 
Cc: Sai Praneeth Prakhya 
Cc: Sedat Dilek 
Cc: Thomas Gleixner 
Cc: YiFei Zhu 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20181129171230.18699-9-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/efi/vars.c | 99 +
 1 file changed, 78 insertions(+), 21 deletions(-)

diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
index 9336ffdf6e2c..fceaafd67ec6 100644
--- a/drivers/firmware/efi/vars.c
+++ b/drivers/firmware/efi/vars.c
@@ -318,7 +318,12 @@ EXPORT_SYMBOL_GPL(efivar_variable_is_removable);
 static efi_status_t
 check_var_size(u32 attributes, unsigned long size)
 {
-   const struct efivar_operations *fops = __efivars->ops;
+   const struct efivar_operations *fops;
+
+   if (!__efivars)
+   return EFI_UNSUPPORTED;
+
+   fops = __efivars->ops;
 
if (!fops->query_variable_store)
return EFI_UNSUPPORTED;
@@ -329,7 +334,12 @@ check_var_size(u32 attributes, unsigned long size)
 static efi_status_t
 check_var_size_nonblocking(u32 attributes, unsigned long size)
 {
-   const struct efivar_operations *fops = __efivars->ops;
+   const struct efivar_operations *fops;
+
+   if (!__efivars)
+   return EFI_UNSUPPORTED;
+
+   fops = __efivars->ops;
 
if (!fops->query_variable_store)
return EFI_UNSUPPORTED;
@@ -429,13 +439,18 @@ static void dup_variable_bug(efi_char16_t *str16, 
efi_guid_t *vendor_guid,
 int efivar_init(int (*func)(efi_char16_t *, efi_guid_t, unsigned long, void *),
void *data, bool duplicates, struct list_head *head)
 {
-   const struct efivar_operations *ops = __efivars->ops;
+   const struct efivar_operations *ops;
unsigned long variable_name_size = 1024;
efi_char16_t *variable_name;
efi_status_t status;
efi_guid_t vendor_guid;
int err = 0;
 
+   if (!__efivars)
+   return -EFAULT;
+
+   ops = __efivars->ops;
+
variable_name = kzalloc(variable_name_size, GFP_KERNEL);
if (!variable_name) {
printk(KERN_ERR "efivars: Memory allocation failed.\n");
@@ -583,12 +598,14 @@ static void efivar_entry_list_del_unlock(struct 
efivar_entry *entry)
  */
 int __efivar_entry_delete(struct efivar_entry *entry)
 {
-   const struct efivar_operations *ops = __efivars->ops;
efi_status_t status;
 
-   status = ops->set_variable(entry->var.VariableName,
-  &entry->var.VendorGuid,
-  0, 0, NULL);
+   if (!__efivars)
+   return -EINVAL;
+
+   status = __efivars->ops->set_variable(entry->var.VariableName,
+ &entry->var.VendorGuid,
+ 0, 0, NULL);
 
return efi_status_to_err(status);
 }
@@ -607,12 +624,17 @@ EXPORT_SYMBOL_GPL(__efivar_entry_delete);
  */
 int efivar_entry_delet

[PATCH 4.19 082/313] firmware/efi: Add NULL pointer checks in efivars API functions

[Greg Kroah-Hartman]

4.19-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit ab2180a15ce54739fed381efb4cb12e78dfb1561 ]

Since commit:

   ce2e6db554fa ("brcmfmac: Add support for getting nvram contents from EFI 
variables")

we have a device driver accessing the efivars API. Several functions in
the efivars API assume __efivars is set, i.e., that they will be accessed
only after efivars_register() has been called. However, the following NULL
pointer access was reported calling efivar_entry_size() from the brcmfmac
device driver:

  Unable to handle kernel NULL pointer dereference at virtual address 0008
  pgd = 60bfa5f1
  [0008] *pgd=
  Internal error: Oops: 5 [#1] SMP ARM
  ...
  Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
  Workqueue: events request_firmware_work_func
  PC is at efivar_entry_size+0x28/0x90
  LR is at brcmf_fw_complete_request+0x3f8/0x8d4 [brcmfmac]
  pc : []lr : []psr: a00d0113
  sp : ede7fe28  ip : ee983410  fp : c1787f30
  r10:   r9 :   r8 : bf2b2258
  r7 : ee983000  r6 : c1604c48  r5 : ede7fe88  r4 : edf337c0
  r3 :   r2 :   r1 : ede7fe88  r0 : c17712c8
  Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
  Control: 10c5387d  Table: ad16804a  DAC: 0051

Disassembly showed that the local static variable __efivars is NULL,
which is not entirely unexpected given that it is a non-EFI platform.

So add a NULL pointer check to efivar_entry_size(), and to related
functions while at it. In efivars_register() a couple of sanity checks
are added as well.

Reported-by: Jon Hunter 
Signed-off-by: Arend van Spriel 
Signed-off-by: Ard Biesheuvel 
Cc: Andy Lutomirski 
Cc: Bhupesh Sharma 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: Eric Snowberg 
Cc: Hans de Goede 
Cc: Joe Perches 
Cc: Julien Thierry 
Cc: Linus Torvalds 
Cc: Marc Zyngier 
Cc: Matt Fleming 
Cc: Nathan Chancellor 
Cc: Peter Zijlstra 
Cc: Sai Praneeth Prakhya 
Cc: Sedat Dilek 
Cc: Thomas Gleixner 
Cc: YiFei Zhu 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20181129171230.18699-9-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/efi/vars.c | 99 +
 1 file changed, 78 insertions(+), 21 deletions(-)

diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
index 9336ffdf6e2c..fceaafd67ec6 100644
--- a/drivers/firmware/efi/vars.c
+++ b/drivers/firmware/efi/vars.c
@@ -318,7 +318,12 @@ EXPORT_SYMBOL_GPL(efivar_variable_is_removable);
 static efi_status_t
 check_var_size(u32 attributes, unsigned long size)
 {
-   const struct efivar_operations *fops = __efivars->ops;
+   const struct efivar_operations *fops;
+
+   if (!__efivars)
+   return EFI_UNSUPPORTED;
+
+   fops = __efivars->ops;
 
if (!fops->query_variable_store)
return EFI_UNSUPPORTED;
@@ -329,7 +334,12 @@ check_var_size(u32 attributes, unsigned long size)
 static efi_status_t
 check_var_size_nonblocking(u32 attributes, unsigned long size)
 {
-   const struct efivar_operations *fops = __efivars->ops;
+   const struct efivar_operations *fops;
+
+   if (!__efivars)
+   return EFI_UNSUPPORTED;
+
+   fops = __efivars->ops;
 
if (!fops->query_variable_store)
return EFI_UNSUPPORTED;
@@ -429,13 +439,18 @@ static void dup_variable_bug(efi_char16_t *str16, 
efi_guid_t *vendor_guid,
 int efivar_init(int (*func)(efi_char16_t *, efi_guid_t, unsigned long, void *),
void *data, bool duplicates, struct list_head *head)
 {
-   const struct efivar_operations *ops = __efivars->ops;
+   const struct efivar_operations *ops;
unsigned long variable_name_size = 1024;
efi_char16_t *variable_name;
efi_status_t status;
efi_guid_t vendor_guid;
int err = 0;
 
+   if (!__efivars)
+   return -EFAULT;
+
+   ops = __efivars->ops;
+
variable_name = kzalloc(variable_name_size, GFP_KERNEL);
if (!variable_name) {
printk(KERN_ERR "efivars: Memory allocation failed.\n");
@@ -583,12 +598,14 @@ static void efivar_entry_list_del_unlock(struct 
efivar_entry *entry)
  */
 int __efivar_entry_delete(struct efivar_entry *entry)
 {
-   const struct efivar_operations *ops = __efivars->ops;
efi_status_t status;
 
-   status = ops->set_variable(entry->var.VariableName,
-  &entry->var.VendorGuid,
-  0, 0, NULL);
+   if (!__efivars)
+   return -EINVAL;
+
+   status = __efivars->ops->set_variable(entry->var.VariableName,
+ &entry->var.VendorGuid,
+ 0, 0, NULL);
 
return efi_status_to_err(status);
 }
@@ -607,12 +624,17 @@ EXPORT_SYMBOL_GPL(__efivar_entry_delete);
  */
 int efivar_entry_delet

[PATCH 4.20 095/352] firmware/efi: Add NULL pointer checks in efivars API functions

[Greg Kroah-Hartman]

4.20-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit ab2180a15ce54739fed381efb4cb12e78dfb1561 ]

Since commit:

   ce2e6db554fa ("brcmfmac: Add support for getting nvram contents from EFI 
variables")

we have a device driver accessing the efivars API. Several functions in
the efivars API assume __efivars is set, i.e., that they will be accessed
only after efivars_register() has been called. However, the following NULL
pointer access was reported calling efivar_entry_size() from the brcmfmac
device driver:

  Unable to handle kernel NULL pointer dereference at virtual address 0008
  pgd = 60bfa5f1
  [0008] *pgd=
  Internal error: Oops: 5 [#1] SMP ARM
  ...
  Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
  Workqueue: events request_firmware_work_func
  PC is at efivar_entry_size+0x28/0x90
  LR is at brcmf_fw_complete_request+0x3f8/0x8d4 [brcmfmac]
  pc : []lr : []psr: a00d0113
  sp : ede7fe28  ip : ee983410  fp : c1787f30
  r10:   r9 :   r8 : bf2b2258
  r7 : ee983000  r6 : c1604c48  r5 : ede7fe88  r4 : edf337c0
  r3 :   r2 :   r1 : ede7fe88  r0 : c17712c8
  Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
  Control: 10c5387d  Table: ad16804a  DAC: 0051

Disassembly showed that the local static variable __efivars is NULL,
which is not entirely unexpected given that it is a non-EFI platform.

So add a NULL pointer check to efivar_entry_size(), and to related
functions while at it. In efivars_register() a couple of sanity checks
are added as well.

Reported-by: Jon Hunter 
Signed-off-by: Arend van Spriel 
Signed-off-by: Ard Biesheuvel 
Cc: Andy Lutomirski 
Cc: Bhupesh Sharma 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: Eric Snowberg 
Cc: Hans de Goede 
Cc: Joe Perches 
Cc: Julien Thierry 
Cc: Linus Torvalds 
Cc: Marc Zyngier 
Cc: Matt Fleming 
Cc: Nathan Chancellor 
Cc: Peter Zijlstra 
Cc: Sai Praneeth Prakhya 
Cc: Sedat Dilek 
Cc: Thomas Gleixner 
Cc: YiFei Zhu 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20181129171230.18699-9-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/efi/vars.c | 99 +
 1 file changed, 78 insertions(+), 21 deletions(-)

diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
index 9336ffdf6e2c..fceaafd67ec6 100644
--- a/drivers/firmware/efi/vars.c
+++ b/drivers/firmware/efi/vars.c
@@ -318,7 +318,12 @@ EXPORT_SYMBOL_GPL(efivar_variable_is_removable);
 static efi_status_t
 check_var_size(u32 attributes, unsigned long size)
 {
-   const struct efivar_operations *fops = __efivars->ops;
+   const struct efivar_operations *fops;
+
+   if (!__efivars)
+   return EFI_UNSUPPORTED;
+
+   fops = __efivars->ops;
 
if (!fops->query_variable_store)
return EFI_UNSUPPORTED;
@@ -329,7 +334,12 @@ check_var_size(u32 attributes, unsigned long size)
 static efi_status_t
 check_var_size_nonblocking(u32 attributes, unsigned long size)
 {
-   const struct efivar_operations *fops = __efivars->ops;
+   const struct efivar_operations *fops;
+
+   if (!__efivars)
+   return EFI_UNSUPPORTED;
+
+   fops = __efivars->ops;
 
if (!fops->query_variable_store)
return EFI_UNSUPPORTED;
@@ -429,13 +439,18 @@ static void dup_variable_bug(efi_char16_t *str16, 
efi_guid_t *vendor_guid,
 int efivar_init(int (*func)(efi_char16_t *, efi_guid_t, unsigned long, void *),
void *data, bool duplicates, struct list_head *head)
 {
-   const struct efivar_operations *ops = __efivars->ops;
+   const struct efivar_operations *ops;
unsigned long variable_name_size = 1024;
efi_char16_t *variable_name;
efi_status_t status;
efi_guid_t vendor_guid;
int err = 0;
 
+   if (!__efivars)
+   return -EFAULT;
+
+   ops = __efivars->ops;
+
variable_name = kzalloc(variable_name_size, GFP_KERNEL);
if (!variable_name) {
printk(KERN_ERR "efivars: Memory allocation failed.\n");
@@ -583,12 +598,14 @@ static void efivar_entry_list_del_unlock(struct 
efivar_entry *entry)
  */
 int __efivar_entry_delete(struct efivar_entry *entry)
 {
-   const struct efivar_operations *ops = __efivars->ops;
efi_status_t status;
 
-   status = ops->set_variable(entry->var.VariableName,
-  &entry->var.VendorGuid,
-  0, 0, NULL);
+   if (!__efivars)
+   return -EINVAL;
+
+   status = __efivars->ops->set_variable(entry->var.VariableName,
+ &entry->var.VendorGuid,
+ 0, 0, NULL);
 
return efi_status_to_err(status);
 }
@@ -607,12 +624,17 @@ EXPORT_SYMBOL_GPL(__efivar_entry_delete);
  */
 int efivar_entry_delet

[PATCH 4.4 135/143] x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Hedi Berriche 

commit f331e766c4be33f4338574f3c9f7f77e98ab4571 upstream.

Calls into UV firmware must be protected against concurrency, expose the
efi_runtime_lock to the UV platform, and use it to serialise UV BIOS
calls.

Signed-off-by: Hedi Berriche 
Signed-off-by: Borislav Petkov 
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
Reviewed-by: Mike Travis 
Cc: Andy Shevchenko 
Cc: Bhupesh Sharma 
Cc: Darren Hart 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: linux-efi 
Cc: platform-driver-...@vger.kernel.org
Cc: sta...@vger.kernel.org # v4.9+
Cc: Steve Wahl 
Cc: Thomas Gleixner 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20190213193413.25560-5-hedi.berri...@hpe.com
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/uv/bios.h  |8 +++-
 arch/x86/platform/uv/bios_uv.c  |   23 +--
 drivers/firmware/efi/runtime-wrappers.c |7 +++
 3 files changed, 35 insertions(+), 3 deletions(-)

--- a/arch/x86/include/asm/uv/bios.h
+++ b/arch/x86/include/asm/uv/bios.h
@@ -48,7 +48,8 @@ enum {
BIOS_STATUS_SUCCESS =  0,
BIOS_STATUS_UNIMPLEMENTED   = -ENOSYS,
BIOS_STATUS_EINVAL  = -EINVAL,
-   BIOS_STATUS_UNAVAIL = -EBUSY
+   BIOS_STATUS_UNAVAIL = -EBUSY,
+   BIOS_STATUS_ABORT   = -EINTR,
 };
 
 /*
@@ -111,4 +112,9 @@ extern long system_serial_number;
 
 extern struct kobject *sgi_uv_kobj;/* /sys/firmware/sgi_uv */
 
+/*
+ * EFI runtime lock; cf. firmware/efi/runtime-wrappers.c for details
+ */
+extern struct semaphore __efi_uv_runtime_lock;
+
 #endif /* _ASM_X86_UV_BIOS_H */
--- a/arch/x86/platform/uv/bios_uv.c
+++ b/arch/x86/platform/uv/bios_uv.c
@@ -28,7 +28,8 @@
 
 static struct uv_systab uv_systab;
 
-s64 uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3, u64 a4, u64 
a5)
+static s64 __uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3,
+   u64 a4, u64 a5)
 {
struct uv_systab *tab = &uv_systab;
s64 ret;
@@ -43,6 +44,19 @@ s64 uv_bios_call(enum uv_bios_cmd which,
a1, a2, a3, a4, a5);
return ret;
 }
+
+s64 uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3, u64 a4, u64 
a5)
+{
+   s64 ret;
+
+   if (down_interruptible(&__efi_uv_runtime_lock))
+   return BIOS_STATUS_ABORT;
+
+   ret = __uv_bios_call(which, a1, a2, a3, a4, a5);
+   up(&__efi_uv_runtime_lock);
+
+   return ret;
+}
 EXPORT_SYMBOL_GPL(uv_bios_call);
 
 s64 uv_bios_call_irqsave(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3,
@@ -51,10 +65,15 @@ s64 uv_bios_call_irqsave(enum uv_bios_cm
unsigned long bios_flags;
s64 ret;
 
+   if (down_interruptible(&__efi_uv_runtime_lock))
+   return BIOS_STATUS_ABORT;
+
local_irq_save(bios_flags);
-   ret = uv_bios_call(which, a1, a2, a3, a4, a5);
+   ret = __uv_bios_call(which, a1, a2, a3, a4, a5);
local_irq_restore(bios_flags);
 
+   up(&__efi_uv_runtime_lock);
+
return ret;
 }
 
--- a/drivers/firmware/efi/runtime-wrappers.c
+++ b/drivers/firmware/efi/runtime-wrappers.c
@@ -88,6 +88,13 @@ static DEFINE_SPINLOCK(efi_runtime_lock)
  */
 
 /*
+ * Expose the EFI runtime lock to the UV platform
+ */
+#ifdef CONFIG_X86_UV
+extern struct semaphore __efi_uv_runtime_lock __alias(efi_runtime_lock);
+#endif
+
+/*
  * As per commit ef68c8f87ed1 ("x86: Serialize EFI time accesses on rtc_lock"),
  * the EFI specification requires that callers of the time related runtime
  * functions serialize with other CMOS accesses in the kernel, as the EFI time

[PATCH 4.9 47/58] x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Hedi Berriche 

commit f331e766c4be33f4338574f3c9f7f77e98ab4571 upstream.

Calls into UV firmware must be protected against concurrency, expose the
efi_runtime_lock to the UV platform, and use it to serialise UV BIOS
calls.

Signed-off-by: Hedi Berriche 
Signed-off-by: Borislav Petkov 
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
Reviewed-by: Mike Travis 
Cc: Andy Shevchenko 
Cc: Bhupesh Sharma 
Cc: Darren Hart 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: linux-efi 
Cc: platform-driver-...@vger.kernel.org
Cc: sta...@vger.kernel.org # v4.9+
Cc: Steve Wahl 
Cc: Thomas Gleixner 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20190213193413.25560-5-hedi.berri...@hpe.com
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/uv/bios.h  |8 +++-
 arch/x86/platform/uv/bios_uv.c  |   23 +--
 drivers/firmware/efi/runtime-wrappers.c |7 +++
 3 files changed, 35 insertions(+), 3 deletions(-)

--- a/arch/x86/include/asm/uv/bios.h
+++ b/arch/x86/include/asm/uv/bios.h
@@ -48,7 +48,8 @@ enum {
BIOS_STATUS_SUCCESS =  0,
BIOS_STATUS_UNIMPLEMENTED   = -ENOSYS,
BIOS_STATUS_EINVAL  = -EINVAL,
-   BIOS_STATUS_UNAVAIL = -EBUSY
+   BIOS_STATUS_UNAVAIL = -EBUSY,
+   BIOS_STATUS_ABORT   = -EINTR,
 };
 
 /* Address map parameters */
@@ -167,4 +168,9 @@ extern long system_serial_number;
 
 extern struct kobject *sgi_uv_kobj;/* /sys/firmware/sgi_uv */
 
+/*
+ * EFI runtime lock; cf. firmware/efi/runtime-wrappers.c for details
+ */
+extern struct semaphore __efi_uv_runtime_lock;
+
 #endif /* _ASM_X86_UV_BIOS_H */
--- a/arch/x86/platform/uv/bios_uv.c
+++ b/arch/x86/platform/uv/bios_uv.c
@@ -29,7 +29,8 @@
 
 struct uv_systab *uv_systab;
 
-s64 uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3, u64 a4, u64 
a5)
+static s64 __uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3,
+   u64 a4, u64 a5)
 {
struct uv_systab *tab = uv_systab;
s64 ret;
@@ -51,6 +52,19 @@ s64 uv_bios_call(enum uv_bios_cmd which,
 
return ret;
 }
+
+s64 uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3, u64 a4, u64 
a5)
+{
+   s64 ret;
+
+   if (down_interruptible(&__efi_uv_runtime_lock))
+   return BIOS_STATUS_ABORT;
+
+   ret = __uv_bios_call(which, a1, a2, a3, a4, a5);
+   up(&__efi_uv_runtime_lock);
+
+   return ret;
+}
 EXPORT_SYMBOL_GPL(uv_bios_call);
 
 s64 uv_bios_call_irqsave(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3,
@@ -59,10 +73,15 @@ s64 uv_bios_call_irqsave(enum uv_bios_cm
unsigned long bios_flags;
s64 ret;
 
+   if (down_interruptible(&__efi_uv_runtime_lock))
+   return BIOS_STATUS_ABORT;
+
local_irq_save(bios_flags);
-   ret = uv_bios_call(which, a1, a2, a3, a4, a5);
+   ret = __uv_bios_call(which, a1, a2, a3, a4, a5);
local_irq_restore(bios_flags);
 
+   up(&__efi_uv_runtime_lock);
+
return ret;
 }
 
--- a/drivers/firmware/efi/runtime-wrappers.c
+++ b/drivers/firmware/efi/runtime-wrappers.c
@@ -50,6 +50,13 @@ void efi_call_virt_check_flags(unsigned
 }
 
 /*
+ * Expose the EFI runtime lock to the UV platform
+ */
+#ifdef CONFIG_X86_UV
+extern struct semaphore __efi_uv_runtime_lock __alias(efi_runtime_lock);
+#endif
+
+/*
  * According to section 7.1 of the UEFI spec, Runtime Services are not fully
  * reentrant, and there are particular combinations of calls that need to be
  * serialized. (source: UEFI Specification v2.4A)

[PATCH 4.14 53/62] x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Hedi Berriche 

commit f331e766c4be33f4338574f3c9f7f77e98ab4571 upstream.

Calls into UV firmware must be protected against concurrency, expose the
efi_runtime_lock to the UV platform, and use it to serialise UV BIOS
calls.

Signed-off-by: Hedi Berriche 
Signed-off-by: Borislav Petkov 
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
Reviewed-by: Mike Travis 
Cc: Andy Shevchenko 
Cc: Bhupesh Sharma 
Cc: Darren Hart 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: linux-efi 
Cc: platform-driver-...@vger.kernel.org
Cc: sta...@vger.kernel.org # v4.9+
Cc: Steve Wahl 
Cc: Thomas Gleixner 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20190213193413.25560-5-hedi.berri...@hpe.com
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/uv/bios.h  |8 +++-
 arch/x86/platform/uv/bios_uv.c  |   23 +--
 drivers/firmware/efi/runtime-wrappers.c |7 +++
 3 files changed, 35 insertions(+), 3 deletions(-)

--- a/arch/x86/include/asm/uv/bios.h
+++ b/arch/x86/include/asm/uv/bios.h
@@ -48,7 +48,8 @@ enum {
BIOS_STATUS_SUCCESS =  0,
BIOS_STATUS_UNIMPLEMENTED   = -ENOSYS,
BIOS_STATUS_EINVAL  = -EINVAL,
-   BIOS_STATUS_UNAVAIL = -EBUSY
+   BIOS_STATUS_UNAVAIL = -EBUSY,
+   BIOS_STATUS_ABORT   = -EINTR,
 };
 
 /* Address map parameters */
@@ -167,4 +168,9 @@ extern long system_serial_number;
 
 extern struct kobject *sgi_uv_kobj;/* /sys/firmware/sgi_uv */
 
+/*
+ * EFI runtime lock; cf. firmware/efi/runtime-wrappers.c for details
+ */
+extern struct semaphore __efi_uv_runtime_lock;
+
 #endif /* _ASM_X86_UV_BIOS_H */
--- a/arch/x86/platform/uv/bios_uv.c
+++ b/arch/x86/platform/uv/bios_uv.c
@@ -29,7 +29,8 @@
 
 struct uv_systab *uv_systab;
 
-s64 uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3, u64 a4, u64 
a5)
+static s64 __uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3,
+   u64 a4, u64 a5)
 {
struct uv_systab *tab = uv_systab;
s64 ret;
@@ -51,6 +52,19 @@ s64 uv_bios_call(enum uv_bios_cmd which,
 
return ret;
 }
+
+s64 uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3, u64 a4, u64 
a5)
+{
+   s64 ret;
+
+   if (down_interruptible(&__efi_uv_runtime_lock))
+   return BIOS_STATUS_ABORT;
+
+   ret = __uv_bios_call(which, a1, a2, a3, a4, a5);
+   up(&__efi_uv_runtime_lock);
+
+   return ret;
+}
 EXPORT_SYMBOL_GPL(uv_bios_call);
 
 s64 uv_bios_call_irqsave(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3,
@@ -59,10 +73,15 @@ s64 uv_bios_call_irqsave(enum uv_bios_cm
unsigned long bios_flags;
s64 ret;
 
+   if (down_interruptible(&__efi_uv_runtime_lock))
+   return BIOS_STATUS_ABORT;
+
local_irq_save(bios_flags);
-   ret = uv_bios_call(which, a1, a2, a3, a4, a5);
+   ret = __uv_bios_call(which, a1, a2, a3, a4, a5);
local_irq_restore(bios_flags);
 
+   up(&__efi_uv_runtime_lock);
+
return ret;
 }
 
--- a/drivers/firmware/efi/runtime-wrappers.c
+++ b/drivers/firmware/efi/runtime-wrappers.c
@@ -50,6 +50,13 @@ void efi_call_virt_check_flags(unsigned
 }
 
 /*
+ * Expose the EFI runtime lock to the UV platform
+ */
+#ifdef CONFIG_X86_UV
+extern struct semaphore __efi_uv_runtime_lock __alias(efi_runtime_lock);
+#endif
+
+/*
  * According to section 7.1 of the UEFI spec, Runtime Services are not fully
  * reentrant, and there are particular combinations of calls that need to be
  * serialized. (source: UEFI Specification v2.4A)

[PATCH 4.19 74/85] x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls

[Greg Kroah-Hartman]

4.19-stable review patch.  If anyone has any objections, please let me know.

--

From: Hedi Berriche 

commit f331e766c4be33f4338574f3c9f7f77e98ab4571 upstream.

Calls into UV firmware must be protected against concurrency, expose the
efi_runtime_lock to the UV platform, and use it to serialise UV BIOS
calls.

Signed-off-by: Hedi Berriche 
Signed-off-by: Borislav Petkov 
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
Reviewed-by: Mike Travis 
Cc: Andy Shevchenko 
Cc: Bhupesh Sharma 
Cc: Darren Hart 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: linux-efi 
Cc: platform-driver-...@vger.kernel.org
Cc: sta...@vger.kernel.org # v4.9+
Cc: Steve Wahl 
Cc: Thomas Gleixner 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20190213193413.25560-5-hedi.berri...@hpe.com
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/uv/bios.h  |8 +++-
 arch/x86/platform/uv/bios_uv.c  |   23 +--
 drivers/firmware/efi/runtime-wrappers.c |7 +++
 3 files changed, 35 insertions(+), 3 deletions(-)

--- a/arch/x86/include/asm/uv/bios.h
+++ b/arch/x86/include/asm/uv/bios.h
@@ -48,7 +48,8 @@ enum {
BIOS_STATUS_SUCCESS =  0,
BIOS_STATUS_UNIMPLEMENTED   = -ENOSYS,
BIOS_STATUS_EINVAL  = -EINVAL,
-   BIOS_STATUS_UNAVAIL = -EBUSY
+   BIOS_STATUS_UNAVAIL = -EBUSY,
+   BIOS_STATUS_ABORT   = -EINTR,
 };
 
 /* Address map parameters */
@@ -167,4 +168,9 @@ extern long system_serial_number;
 
 extern struct kobject *sgi_uv_kobj;/* /sys/firmware/sgi_uv */
 
+/*
+ * EFI runtime lock; cf. firmware/efi/runtime-wrappers.c for details
+ */
+extern struct semaphore __efi_uv_runtime_lock;
+
 #endif /* _ASM_X86_UV_BIOS_H */
--- a/arch/x86/platform/uv/bios_uv.c
+++ b/arch/x86/platform/uv/bios_uv.c
@@ -29,7 +29,8 @@
 
 struct uv_systab *uv_systab;
 
-s64 uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3, u64 a4, u64 
a5)
+static s64 __uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3,
+   u64 a4, u64 a5)
 {
struct uv_systab *tab = uv_systab;
s64 ret;
@@ -51,6 +52,19 @@ s64 uv_bios_call(enum uv_bios_cmd which,
 
return ret;
 }
+
+s64 uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3, u64 a4, u64 
a5)
+{
+   s64 ret;
+
+   if (down_interruptible(&__efi_uv_runtime_lock))
+   return BIOS_STATUS_ABORT;
+
+   ret = __uv_bios_call(which, a1, a2, a3, a4, a5);
+   up(&__efi_uv_runtime_lock);
+
+   return ret;
+}
 EXPORT_SYMBOL_GPL(uv_bios_call);
 
 s64 uv_bios_call_irqsave(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3,
@@ -59,10 +73,15 @@ s64 uv_bios_call_irqsave(enum uv_bios_cm
unsigned long bios_flags;
s64 ret;
 
+   if (down_interruptible(&__efi_uv_runtime_lock))
+   return BIOS_STATUS_ABORT;
+
local_irq_save(bios_flags);
-   ret = uv_bios_call(which, a1, a2, a3, a4, a5);
+   ret = __uv_bios_call(which, a1, a2, a3, a4, a5);
local_irq_restore(bios_flags);
 
+   up(&__efi_uv_runtime_lock);
+
return ret;
 }
 
--- a/drivers/firmware/efi/runtime-wrappers.c
+++ b/drivers/firmware/efi/runtime-wrappers.c
@@ -173,6 +173,13 @@ void efi_call_virt_check_flags(unsigned
 static DEFINE_SEMAPHORE(efi_runtime_lock);
 
 /*
+ * Expose the EFI runtime lock to the UV platform
+ */
+#ifdef CONFIG_X86_UV
+extern struct semaphore __efi_uv_runtime_lock __alias(efi_runtime_lock);
+#endif
+
+/*
  * Calls the appropriate efi_runtime_service() with the appropriate
  * arguments.
  *

[PATCH 4.20 78/92] x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls

[Greg Kroah-Hartman]

4.20-stable review patch.  If anyone has any objections, please let me know.

--

From: Hedi Berriche 

commit f331e766c4be33f4338574f3c9f7f77e98ab4571 upstream.

Calls into UV firmware must be protected against concurrency, expose the
efi_runtime_lock to the UV platform, and use it to serialise UV BIOS
calls.

Signed-off-by: Hedi Berriche 
Signed-off-by: Borislav Petkov 
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
Reviewed-by: Mike Travis 
Cc: Andy Shevchenko 
Cc: Bhupesh Sharma 
Cc: Darren Hart 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: linux-efi 
Cc: platform-driver-...@vger.kernel.org
Cc: sta...@vger.kernel.org # v4.9+
Cc: Steve Wahl 
Cc: Thomas Gleixner 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20190213193413.25560-5-hedi.berri...@hpe.com
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/uv/bios.h  |8 +++-
 arch/x86/platform/uv/bios_uv.c  |   23 +--
 drivers/firmware/efi/runtime-wrappers.c |7 +++
 3 files changed, 35 insertions(+), 3 deletions(-)

--- a/arch/x86/include/asm/uv/bios.h
+++ b/arch/x86/include/asm/uv/bios.h
@@ -48,7 +48,8 @@ enum {
BIOS_STATUS_SUCCESS =  0,
BIOS_STATUS_UNIMPLEMENTED   = -ENOSYS,
BIOS_STATUS_EINVAL  = -EINVAL,
-   BIOS_STATUS_UNAVAIL = -EBUSY
+   BIOS_STATUS_UNAVAIL = -EBUSY,
+   BIOS_STATUS_ABORT   = -EINTR,
 };
 
 /* Address map parameters */
@@ -167,4 +168,9 @@ extern long system_serial_number;
 
 extern struct kobject *sgi_uv_kobj;/* /sys/firmware/sgi_uv */
 
+/*
+ * EFI runtime lock; cf. firmware/efi/runtime-wrappers.c for details
+ */
+extern struct semaphore __efi_uv_runtime_lock;
+
 #endif /* _ASM_X86_UV_BIOS_H */
--- a/arch/x86/platform/uv/bios_uv.c
+++ b/arch/x86/platform/uv/bios_uv.c
@@ -29,7 +29,8 @@
 
 struct uv_systab *uv_systab;
 
-s64 uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3, u64 a4, u64 
a5)
+static s64 __uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3,
+   u64 a4, u64 a5)
 {
struct uv_systab *tab = uv_systab;
s64 ret;
@@ -51,6 +52,19 @@ s64 uv_bios_call(enum uv_bios_cmd which,
 
return ret;
 }
+
+s64 uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3, u64 a4, u64 
a5)
+{
+   s64 ret;
+
+   if (down_interruptible(&__efi_uv_runtime_lock))
+   return BIOS_STATUS_ABORT;
+
+   ret = __uv_bios_call(which, a1, a2, a3, a4, a5);
+   up(&__efi_uv_runtime_lock);
+
+   return ret;
+}
 EXPORT_SYMBOL_GPL(uv_bios_call);
 
 s64 uv_bios_call_irqsave(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3,
@@ -59,10 +73,15 @@ s64 uv_bios_call_irqsave(enum uv_bios_cm
unsigned long bios_flags;
s64 ret;
 
+   if (down_interruptible(&__efi_uv_runtime_lock))
+   return BIOS_STATUS_ABORT;
+
local_irq_save(bios_flags);
-   ret = uv_bios_call(which, a1, a2, a3, a4, a5);
+   ret = __uv_bios_call(which, a1, a2, a3, a4, a5);
local_irq_restore(bios_flags);
 
+   up(&__efi_uv_runtime_lock);
+
return ret;
 }
 
--- a/drivers/firmware/efi/runtime-wrappers.c
+++ b/drivers/firmware/efi/runtime-wrappers.c
@@ -147,6 +147,13 @@ void efi_call_virt_check_flags(unsigned
 static DEFINE_SEMAPHORE(efi_runtime_lock);
 
 /*
+ * Expose the EFI runtime lock to the UV platform
+ */
+#ifdef CONFIG_X86_UV
+extern struct semaphore __efi_uv_runtime_lock __alias(efi_runtime_lock);
+#endif
+
+/*
  * Calls the appropriate efi_runtime_service() with the appropriate
  * arguments.
  *

[PATCH 4.20 23/32] efi/arm: Revert "Defer persistent reservations until after paging_init()"

[Greg Kroah-Hartman]

4.20-stable review patch.  If anyone has any objections, please let me know.

--

Commit 582a32e708823e5957fd73ccd78dc4a9e49d21ea upstream.

This reverts commit eff896288872d687d9662000ec9ae11b6d61766f, which
deferred the processing of persistent memory reservations to a point
where the memory may have already been allocated and overwritten,
defeating the purpose.

Signed-off-by: Ard Biesheuvel 
Acked-by: Will Deacon 
Cc: Linus Torvalds 
Cc: Marc Zyngier 
Cc: Mike Rapoport 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/2019021512.21209-3-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Sasha Levin 
---
 arch/arm64/kernel/setup.c   | 1 -
 drivers/firmware/efi/efi.c  | 4 
 drivers/firmware/efi/libstub/arm-stub.c | 3 ---
 include/linux/efi.h | 7 ---
 4 files changed, 15 deletions(-)

diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index f4fc1e0544b73..953e316521fca 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -313,7 +313,6 @@ void __init setup_arch(char **cmdline_p)
arm64_memblock_init();
 
paging_init();
-   efi_apply_persistent_mem_reservations();
 
acpi_table_upgrade();
 
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 415849bab2339..bde3822cf539a 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -592,11 +592,7 @@ int __init efi_config_parse_tables(void *config_tables, 
int count, int sz,
 
early_memunmap(tbl, sizeof(*tbl));
}
-   return 0;
-}
 
-int __init efi_apply_persistent_mem_reservations(void)
-{
if (efi.mem_reserve != EFI_INVALID_TABLE_ADDR) {
unsigned long prsv = efi.mem_reserve;
 
diff --git a/drivers/firmware/efi/libstub/arm-stub.c 
b/drivers/firmware/efi/libstub/arm-stub.c
index 3d36142cf8120..30ac0c975f8a1 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -75,9 +75,6 @@ void install_memreserve_table(efi_system_table_t 
*sys_table_arg)
efi_guid_t memreserve_table_guid = LINUX_EFI_MEMRESERVE_TABLE_GUID;
efi_status_t status;
 
-   if (IS_ENABLED(CONFIG_ARM))
-   return;
-
status = efi_call_early(allocate_pool, EFI_LOADER_DATA, sizeof(*rsv),
(void **)&rsv);
if (status != EFI_SUCCESS) {
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 100ce4a4aff6c..845174e113ce9 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1167,8 +1167,6 @@ static inline bool efi_enabled(int feature)
 extern void efi_reboot(enum reboot_mode reboot_mode, const char *__unused);
 
 extern bool efi_is_table_address(unsigned long phys_addr);
-
-extern int efi_apply_persistent_mem_reservations(void);
 #else
 static inline bool efi_enabled(int feature)
 {
@@ -1187,11 +1185,6 @@ static inline bool efi_is_table_address(unsigned long 
phys_addr)
 {
return false;
 }
-
-static inline int efi_apply_persistent_mem_reservations(void)
-{
-   return 0;
-}
 #endif
 
 extern int efi_status_to_err(efi_status_t status);
-- 
2.19.1

[PATCH 4.20 22/32] arm64, mm, efi: Account for GICv3 LPI tables in static memblock reserve table

[Greg Kroah-Hartman]

4.20-stable review patch.  If anyone has any objections, please let me know.

--

Commit 8a5b403d71affa098009cc3dff1b2c45113021ad upstream.

In the irqchip and EFI code, we have what basically amounts to a quirk
to work around a peculiarity in the GICv3 architecture, which permits
the system memory address of LPI tables to be programmable only once
after a CPU reset. This means kexec kernels must use the same memory
as the first kernel, and thus ensure that this memory has not been
given out for other purposes by the time the ITS init code runs, which
is not very early for secondary CPUs.

On systems with many CPUs, these reservations could overflow the
memblock reservation table, and this was addressed in commit:

  eff896288872 ("efi/arm: Defer persistent reservations until after 
paging_init()")

However, this turns out to have made things worse, since the allocation
of page tables and heap space for the resized memblock reservation table
itself may overwrite the regions we are attempting to reserve, which may
cause all kinds of corruption, also considering that the ITS will still
be poking bits into that memory in response to incoming MSIs.

So instead, let's grow the static memblock reservation table on such
systems so it can accommodate these reservations at an earlier time.
This will permit us to revert the above commit in a subsequent patch.

[ mingo: Minor cleanups. ]

Signed-off-by: Ard Biesheuvel 
Acked-by: Mike Rapoport 
Acked-by: Will Deacon 
Acked-by: Marc Zyngier 
Cc: Andrew Morton 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/2019021512.21209-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
[ ardb: Double the size of the slack to account for the lack of an
optimization that was introduced in mainline after the release
of v4.20. ]
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Sasha Levin 
---
 arch/arm64/include/asm/memory.h | 11 +++
 include/linux/memblock.h|  3 ---
 mm/memblock.c   | 11 +--
 3 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 778af0b7f7fd5..c67081301035f 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -303,6 +303,17 @@ static inline void *phys_to_virt(phys_addr_t x)
 #define virt_addr_valid(kaddr) (_virt_addr_is_linear(kaddr) && \
 _virt_addr_valid(kaddr))
 
+/*
+ * Given that the GIC architecture permits ITS implementations that can only be
+ * configured with a LPI table address once, GICv3 systems with many CPUs may
+ * end up reserving a lot of different regions after a kexec for their LPI
+ * tables (one per CPU), as we are forced to reuse the same memory after kexec
+ * (and thus reserve it persistently with EFI beforehand)
+ */
+#if defined(CONFIG_EFI) && defined(CONFIG_ARM_GIC_V3_ITS)
+# define INIT_MEMBLOCK_RESERVED_REGIONS(INIT_MEMBLOCK_REGIONS + 
2*(NR_CPUS + 1))
+#endif
+
 #include 
 
 #endif
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 3ef3086ed52f9..ecff64ff365d4 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -29,9 +29,6 @@ extern unsigned long max_pfn;
  */
 extern unsigned long long max_possible_pfn;
 
-#define INIT_MEMBLOCK_REGIONS  128
-#define INIT_PHYSMEM_REGIONS   4
-
 /**
  * enum memblock_flags - definition of memory region attributes
  * @MEMBLOCK_NONE: no special request
diff --git a/mm/memblock.c b/mm/memblock.c
index f45a049532fea..74ac4f89018ab 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -26,6 +26,13 @@
 
 #include "internal.h"
 
+#define INIT_MEMBLOCK_REGIONS  128
+#define INIT_PHYSMEM_REGIONS   4
+
+#ifndef INIT_MEMBLOCK_RESERVED_REGIONS
+# define INIT_MEMBLOCK_RESERVED_REGIONSINIT_MEMBLOCK_REGIONS
+#endif
+
 /**
  * DOC: memblock overview
  *
@@ -92,7 +99,7 @@ unsigned long max_pfn;
 unsigned long long max_possible_pfn;
 
 static struct memblock_region 
memblock_memory_init_regions[INIT_MEMBLOCK_REGIONS] __initdata_memblock;
-static struct memblock_region 
memblock_reserved_init_regions[INIT_MEMBLOCK_REGIONS] __initdata_memblock;
+static struct memblock_region 
memblock_reserved_init_regions[INIT_MEMBLOCK_RESERVED_REGIONS] 
__initdata_memblock;
 #ifdef CONFIG_HAVE_MEMBLOCK_PHYS_MAP
 static struct memblock_region 
memblock_physmem_init_regions[INIT_PHYSMEM_REGIONS] __initdata_memblock;
 #endif
@@ -105,7 +112,7 @@ struct memblock memblock __initdata_memblock = {
 
.reserved.regions   = memblock_reserved_init_regions,
.reserved.cnt   = 1,/* empty dummy entry */
-   .reserved.max   = INIT_MEMBLOCK_REGIONS,
+   .reserved.max   = INIT_MEMBLOCK_RESERVED_REGIONS,
.reserved.name  = "reserved",
 
 #ifdef CO

[PATCH 4.9 16/51] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T

[Greg Kroah-Hartman]

[ Upstream commit 0082517fa4bce073e7cf542633439f26538a14cc ]

Upon reboot, the Acer TravelMate X514-51T laptop appears to complete the
shutdown process, but then it hangs in BIOS POST with a black screen.

The problem is intermittent - at some points it has appeared related to
Secure Boot settings or different kernel builds, but ultimately we have
not been able to identify the exact conditions that trigger the issue to
come and go.

Besides, the EFI mode cannot be disabled in the BIOS of this model.

However, after extensive testing, we observe that using the EFI reboot
method reliably avoids the issue in all cases.

So add a boot time quirk to use EFI reboot on such systems.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203119
Signed-off-by: Jian-Hong Pan 
Signed-off-by: Daniel Drake 
Cc: Ard Biesheuvel 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Cc: li...@endlessm.com
Link: http://lkml.kernel.org/r/20190412080152.3718-1-jian-h...@endlessm.com
[ Fix !CONFIG_EFI build failure, clarify the code and the changelog a bit. ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 arch/x86/kernel/reboot.c | 21 +
 include/linux/efi.h  |  7 ++-
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 4a12362a194af..c55b11fe8e9f6 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -82,6 +82,19 @@ static int __init set_bios_reboot(const struct dmi_system_id 
*d)
return 0;
 }
 
+/*
+ * Some machines don't handle the default ACPI reboot method and
+ * require the EFI reboot method:
+ */
+static int __init set_efi_reboot(const struct dmi_system_id *d)
+{
+   if (reboot_type != BOOT_EFI && !efi_runtime_disabled()) {
+   reboot_type = BOOT_EFI;
+   pr_info("%s series board detected. Selecting EFI-method for 
reboot.\n", d->ident);
+   }
+   return 0;
+}
+
 void __noreturn machine_real_restart(unsigned int type)
 {
local_irq_disable();
@@ -167,6 +180,14 @@ static struct dmi_system_id __initdata reboot_dmi_table[] 
= {
DMI_MATCH(DMI_PRODUCT_NAME, "AOA110"),
},
},
+   {   /* Handle reboot issue on Acer TravelMate X514-51T */
+   .callback = set_efi_reboot,
+   .ident = "Acer TravelMate X514-51T",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate X514-51T"),
+   },
+   },
 
/* Apple */
{   /* Handle problems with rebooting on Apple MacBook5 */
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 80b1b8faf503f..e6711bf9f0d12 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1433,7 +1433,12 @@ efi_status_t efi_setup_gop(efi_system_table_t 
*sys_table_arg,
   struct screen_info *si, efi_guid_t *proto,
   unsigned long size);
 
-bool efi_runtime_disabled(void);
+#ifdef CONFIG_EFI
+extern bool efi_runtime_disabled(void);
+#else
+static inline bool efi_runtime_disabled(void) { return true; }
+#endif
+
 extern void efi_call_virt_check_flags(unsigned long flags, const char *call);
 
 /*
-- 
2.20.1

[PATCH 5.0 049/137] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T

[Greg Kroah-Hartman]

[ Upstream commit 0082517fa4bce073e7cf542633439f26538a14cc ]

Upon reboot, the Acer TravelMate X514-51T laptop appears to complete the
shutdown process, but then it hangs in BIOS POST with a black screen.

The problem is intermittent - at some points it has appeared related to
Secure Boot settings or different kernel builds, but ultimately we have
not been able to identify the exact conditions that trigger the issue to
come and go.

Besides, the EFI mode cannot be disabled in the BIOS of this model.

However, after extensive testing, we observe that using the EFI reboot
method reliably avoids the issue in all cases.

So add a boot time quirk to use EFI reboot on such systems.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203119
Signed-off-by: Jian-Hong Pan 
Signed-off-by: Daniel Drake 
Cc: Ard Biesheuvel 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Cc: li...@endlessm.com
Link: http://lkml.kernel.org/r/20190412080152.3718-1-jian-h...@endlessm.com
[ Fix !CONFIG_EFI build failure, clarify the code and the changelog a bit. ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 arch/x86/kernel/reboot.c | 21 +
 include/linux/efi.h  |  7 ++-
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 725624b6c0c05..8fd3cedd9accd 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -81,6 +81,19 @@ static int __init set_bios_reboot(const struct dmi_system_id 
*d)
return 0;
 }
 
+/*
+ * Some machines don't handle the default ACPI reboot method and
+ * require the EFI reboot method:
+ */
+static int __init set_efi_reboot(const struct dmi_system_id *d)
+{
+   if (reboot_type != BOOT_EFI && !efi_runtime_disabled()) {
+   reboot_type = BOOT_EFI;
+   pr_info("%s series board detected. Selecting EFI-method for 
reboot.\n", d->ident);
+   }
+   return 0;
+}
+
 void __noreturn machine_real_restart(unsigned int type)
 {
local_irq_disable();
@@ -166,6 +179,14 @@ static const struct dmi_system_id reboot_dmi_table[] 
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "AOA110"),
},
},
+   {   /* Handle reboot issue on Acer TravelMate X514-51T */
+   .callback = set_efi_reboot,
+   .ident = "Acer TravelMate X514-51T",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate X514-51T"),
+   },
+   },
 
/* Apple */
{   /* Handle problems with rebooting on Apple MacBook5 */
diff --git a/include/linux/efi.h b/include/linux/efi.h
index a86485ac7c878..de05a43025292 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1598,7 +1598,12 @@ efi_status_t efi_setup_gop(efi_system_table_t 
*sys_table_arg,
   struct screen_info *si, efi_guid_t *proto,
   unsigned long size);
 
-bool efi_runtime_disabled(void);
+#ifdef CONFIG_EFI
+extern bool efi_runtime_disabled(void);
+#else
+static inline bool efi_runtime_disabled(void) { return true; }
+#endif
+
 extern void efi_call_virt_check_flags(unsigned long flags, const char *call);
 
 enum efi_secureboot_mode {
-- 
2.20.1

[PATCH 4.19 037/113] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T

[Greg Kroah-Hartman]

[ Upstream commit 0082517fa4bce073e7cf542633439f26538a14cc ]

Upon reboot, the Acer TravelMate X514-51T laptop appears to complete the
shutdown process, but then it hangs in BIOS POST with a black screen.

The problem is intermittent - at some points it has appeared related to
Secure Boot settings or different kernel builds, but ultimately we have
not been able to identify the exact conditions that trigger the issue to
come and go.

Besides, the EFI mode cannot be disabled in the BIOS of this model.

However, after extensive testing, we observe that using the EFI reboot
method reliably avoids the issue in all cases.

So add a boot time quirk to use EFI reboot on such systems.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203119
Signed-off-by: Jian-Hong Pan 
Signed-off-by: Daniel Drake 
Cc: Ard Biesheuvel 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Cc: li...@endlessm.com
Link: http://lkml.kernel.org/r/20190412080152.3718-1-jian-h...@endlessm.com
[ Fix !CONFIG_EFI build failure, clarify the code and the changelog a bit. ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 arch/x86/kernel/reboot.c | 21 +
 include/linux/efi.h  |  7 ++-
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 725624b6c0c05..8fd3cedd9accd 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -81,6 +81,19 @@ static int __init set_bios_reboot(const struct dmi_system_id 
*d)
return 0;
 }
 
+/*
+ * Some machines don't handle the default ACPI reboot method and
+ * require the EFI reboot method:
+ */
+static int __init set_efi_reboot(const struct dmi_system_id *d)
+{
+   if (reboot_type != BOOT_EFI && !efi_runtime_disabled()) {
+   reboot_type = BOOT_EFI;
+   pr_info("%s series board detected. Selecting EFI-method for 
reboot.\n", d->ident);
+   }
+   return 0;
+}
+
 void __noreturn machine_real_restart(unsigned int type)
 {
local_irq_disable();
@@ -166,6 +179,14 @@ static const struct dmi_system_id reboot_dmi_table[] 
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "AOA110"),
},
},
+   {   /* Handle reboot issue on Acer TravelMate X514-51T */
+   .callback = set_efi_reboot,
+   .ident = "Acer TravelMate X514-51T",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate X514-51T"),
+   },
+   },
 
/* Apple */
{   /* Handle problems with rebooting on Apple MacBook5 */
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 401e4b254e30b..cc3391796c0b8 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1564,7 +1564,12 @@ efi_status_t efi_setup_gop(efi_system_table_t 
*sys_table_arg,
   struct screen_info *si, efi_guid_t *proto,
   unsigned long size);
 
-bool efi_runtime_disabled(void);
+#ifdef CONFIG_EFI
+extern bool efi_runtime_disabled(void);
+#else
+static inline bool efi_runtime_disabled(void) { return true; }
+#endif
+
 extern void efi_call_virt_check_flags(unsigned long flags, const char *call);
 
 enum efi_secureboot_mode {
-- 
2.20.1

[PATCH 4.14 083/115] x86/fpu: Dont export __kernel_fpu_{begin,end}()

[Greg Kroah-Hartman]

[ Upstream commit 12209993e98c5fa1855c467f22a24e3d5b8be205 ]

There is one user of __kernel_fpu_begin() and before invoking it,
it invokes preempt_disable(). So it could invoke kernel_fpu_begin()
right away. The 32bit version of arch_efi_call_virt_setup() and
arch_efi_call_virt_teardown() does this already.

The comment above *kernel_fpu*() claims that before invoking
__kernel_fpu_begin() preemption should be disabled and that KVM is a
good example of doing it. Well, KVM doesn't do that since commit

  f775b13eedee2 ("x86,kvm: move qemu/guest FPU switching out to vcpu_run")

so it is not an example anymore.

With EFI gone as the last user of __kernel_fpu_{begin|end}(), both can
be made static and not exported anymore.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Borislav Petkov 
Reviewed-by: Rik van Riel 
Cc: "H. Peter Anvin" 
Cc: "Jason A. Donenfeld" 
Cc: Andy Lutomirski 
Cc: Ard Biesheuvel 
Cc: Dave Hansen 
Cc: Ingo Molnar 
Cc: Nicolai Stange 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Thomas Gleixner 
Cc: kvm ML 
Cc: linux-efi 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20181129150210.2k4mawt37ow6c...@linutronix.de
Signed-off-by: Sasha Levin 
---
 arch/x86/include/asm/efi.h |  6 ++
 arch/x86/include/asm/fpu/api.h | 15 +--
 arch/x86/kernel/fpu/core.c |  6 ++
 3 files changed, 9 insertions(+), 18 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index a399c1ebf6f0e..96fd0251f8f57 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -82,8 +82,7 @@ struct efi_scratch {
 #define arch_efi_call_virt_setup() \
 ({ \
efi_sync_low_kernel_mappings(); \
-   preempt_disable();  \
-   __kernel_fpu_begin();   \
+   kernel_fpu_begin(); \
firmware_restrict_branch_speculation_start();   \
\
if (efi_scratch.use_pgd) {  \
@@ -104,8 +103,7 @@ struct efi_scratch {
}   \
\
firmware_restrict_branch_speculation_end(); \
-   __kernel_fpu_end(); \
-   preempt_enable();   \
+   kernel_fpu_end();   \
 })
 
 extern void __iomem *__init efi_ioremap(unsigned long addr, unsigned long size,
diff --git a/arch/x86/include/asm/fpu/api.h b/arch/x86/include/asm/fpu/api.h
index a9caac9d4a729..b56d504af6545 100644
--- a/arch/x86/include/asm/fpu/api.h
+++ b/arch/x86/include/asm/fpu/api.h
@@ -12,17 +12,12 @@
 #define _ASM_X86_FPU_API_H
 
 /*
- * Careful: __kernel_fpu_begin/end() must be called with preempt disabled
- * and they don't touch the preempt state on their own.
- * If you enable preemption after __kernel_fpu_begin(), preempt notifier
- * should call the __kernel_fpu_end() to prevent the kernel/user FPU
- * state from getting corrupted. KVM for example uses this model.
- *
- * All other cases use kernel_fpu_begin/end() which disable preemption
- * during kernel FPU usage.
+ * Use kernel_fpu_begin/end() if you intend to use FPU in kernel context. It
+ * disables preemption so be careful if you intend to use it for long periods
+ * of time.
+ * If you intend to use the FPU in softirq you need to check first with
+ * irq_fpu_usable() if it is possible.
  */
-extern void __kernel_fpu_begin(void);
-extern void __kernel_fpu_end(void);
 extern void kernel_fpu_begin(void);
 extern void kernel_fpu_end(void);
 extern bool irq_fpu_usable(void);
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index 2ea85b32421a0..2e5003fef51a9 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -93,7 +93,7 @@ bool irq_fpu_usable(void)
 }
 EXPORT_SYMBOL(irq_fpu_usable);
 
-void __kernel_fpu_begin(void)
+static void __kernel_fpu_begin(void)
 {
struct fpu *fpu = ¤t->thread.fpu;
 
@@ -111,9 +111,8 @@ void __kernel_fpu_begin(void)
__cpu_invalidate_fpregs_state();
}
 }
-EXPORT_SYMBOL(__kernel_fpu_begin);
 
-void __kernel_fpu_end(void)
+static void __kernel_fpu_end(void)
 {
struct fpu *fpu = ¤t->thread.fpu;
 
@@ -122,7 +121,6 @@ void __kernel_fpu_end(void)
 
kernel_fpu_enable();
 }
-EXPORT_SYMBOL(__kernel_fpu_end);
 
 void kernel_fpu_begin(void)
 {
-- 
2.20.1

[PATCH 4.14 022/115] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T

[Greg Kroah-Hartman]

[ Upstream commit 0082517fa4bce073e7cf542633439f26538a14cc ]

Upon reboot, the Acer TravelMate X514-51T laptop appears to complete the
shutdown process, but then it hangs in BIOS POST with a black screen.

The problem is intermittent - at some points it has appeared related to
Secure Boot settings or different kernel builds, but ultimately we have
not been able to identify the exact conditions that trigger the issue to
come and go.

Besides, the EFI mode cannot be disabled in the BIOS of this model.

However, after extensive testing, we observe that using the EFI reboot
method reliably avoids the issue in all cases.

So add a boot time quirk to use EFI reboot on such systems.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203119
Signed-off-by: Jian-Hong Pan 
Signed-off-by: Daniel Drake 
Cc: Ard Biesheuvel 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Cc: li...@endlessm.com
Link: http://lkml.kernel.org/r/20190412080152.3718-1-jian-h...@endlessm.com
[ Fix !CONFIG_EFI build failure, clarify the code and the changelog a bit. ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 arch/x86/kernel/reboot.c | 21 +
 include/linux/efi.h  |  7 ++-
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 2126b9d27c340..c663d5fcff2ee 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -81,6 +81,19 @@ static int __init set_bios_reboot(const struct dmi_system_id 
*d)
return 0;
 }
 
+/*
+ * Some machines don't handle the default ACPI reboot method and
+ * require the EFI reboot method:
+ */
+static int __init set_efi_reboot(const struct dmi_system_id *d)
+{
+   if (reboot_type != BOOT_EFI && !efi_runtime_disabled()) {
+   reboot_type = BOOT_EFI;
+   pr_info("%s series board detected. Selecting EFI-method for 
reboot.\n", d->ident);
+   }
+   return 0;
+}
+
 void __noreturn machine_real_restart(unsigned int type)
 {
local_irq_disable();
@@ -166,6 +179,14 @@ static const struct dmi_system_id reboot_dmi_table[] 
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "AOA110"),
},
},
+   {   /* Handle reboot issue on Acer TravelMate X514-51T */
+   .callback = set_efi_reboot,
+   .ident = "Acer TravelMate X514-51T",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate X514-51T"),
+   },
+   },
 
/* Apple */
{   /* Handle problems with rebooting on Apple MacBook5 */
diff --git a/include/linux/efi.h b/include/linux/efi.h
index b68b7d199feea..2dab158b74c45 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1518,7 +1518,12 @@ efi_status_t efi_setup_gop(efi_system_table_t 
*sys_table_arg,
   struct screen_info *si, efi_guid_t *proto,
   unsigned long size);
 
-bool efi_runtime_disabled(void);
+#ifdef CONFIG_EFI
+extern bool efi_runtime_disabled(void);
+#else
+static inline bool efi_runtime_disabled(void) { return true; }
+#endif
+
 extern void efi_call_virt_check_flags(unsigned long flags, const char *call);
 
 enum efi_secureboot_mode {
-- 
2.20.1

[PATCH 5.1 085/122] fbdev/efifb: Ignore framebuffer memmap entries that lack any memory types

[Greg Kroah-Hartman]

From: Ard Biesheuvel 

commit f8585539df0a1527c78b5d760665c89fe1c105a9 upstream.

The following commit:

  38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping 
the FB")

updated the EFI framebuffer code to use memory mappings for the linear
framebuffer that are permitted by the memory attributes described by the
EFI memory map for the particular region, if the framebuffer happens to
be covered by the EFI memory map (which is typically only the case for
framebuffers in shared memory). This is required since non-x86 systems
may require cacheable attributes for memory mappings that are shared
with other masters (such as GPUs), and this information cannot be
described by the Graphics Output Protocol (GOP) EFI protocol itself,
and so we rely on the EFI memory map for this.

As reported by James, this breaks some x86 systems:

  [ 1.173368] efifb: probing for efifb
  [ 1.173386] efifb: abort, cannot remap video memory 0x1d5000 @ 0xcf80
  [ 1.173395] Trying to free nonexistent resource 
<cf80-cf9d4bff>
  [ 1.173413] efi-framebuffer: probe of efi-framebuffer.0 failed with error -5

The problem turns out to be that the memory map entry that describes the
framebuffer has no memory attributes listed at all, and so we end up with
a mem_flags value of 0x0.

So work around this by ensuring that the memory map entry's attribute field
has a sane value before using it to mask the set of usable attributes.

Reported-by: James Hilliard 
Tested-by: James Hilliard 
Signed-off-by: Ard Biesheuvel 
Cc:  # v4.19+
Cc: Borislav Petkov 
Cc: James Morse 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when ...")
Link: http://lkml.kernel.org/r/20190516213159.3530-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/video/fbdev/efifb.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -476,8 +476,12 @@ static int efifb_probe(struct platform_d
 * If the UEFI memory map covers the efifb region, we may only
 * remap it using the attributes the memory map prescribes.
 */
-   mem_flags |= EFI_MEMORY_WT | EFI_MEMORY_WB;
-   mem_flags &= md.attribute;
+   md.attribute &= EFI_MEMORY_UC | EFI_MEMORY_WC |
+   EFI_MEMORY_WT | EFI_MEMORY_WB;
+   if (md.attribute) {
+   mem_flags |= EFI_MEMORY_WT | EFI_MEMORY_WB;
+   mem_flags &= md.attribute;
+   }
}
if (mem_flags & EFI_MEMORY_WC)
info->screen_base = ioremap_wc(efifb_fix.smem_start,

[PATCH 5.0 076/139] fbdev/efifb: Ignore framebuffer memmap entries that lack any memory types

[Greg Kroah-Hartman]

From: Ard Biesheuvel 

commit f8585539df0a1527c78b5d760665c89fe1c105a9 upstream.

The following commit:

  38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping 
the FB")

updated the EFI framebuffer code to use memory mappings for the linear
framebuffer that are permitted by the memory attributes described by the
EFI memory map for the particular region, if the framebuffer happens to
be covered by the EFI memory map (which is typically only the case for
framebuffers in shared memory). This is required since non-x86 systems
may require cacheable attributes for memory mappings that are shared
with other masters (such as GPUs), and this information cannot be
described by the Graphics Output Protocol (GOP) EFI protocol itself,
and so we rely on the EFI memory map for this.

As reported by James, this breaks some x86 systems:

  [ 1.173368] efifb: probing for efifb
  [ 1.173386] efifb: abort, cannot remap video memory 0x1d5000 @ 0xcf80
  [ 1.173395] Trying to free nonexistent resource 
<cf80-cf9d4bff>
  [ 1.173413] efi-framebuffer: probe of efi-framebuffer.0 failed with error -5

The problem turns out to be that the memory map entry that describes the
framebuffer has no memory attributes listed at all, and so we end up with
a mem_flags value of 0x0.

So work around this by ensuring that the memory map entry's attribute field
has a sane value before using it to mask the set of usable attributes.

Reported-by: James Hilliard 
Tested-by: James Hilliard 
Signed-off-by: Ard Biesheuvel 
Cc:  # v4.19+
Cc: Borislav Petkov 
Cc: James Morse 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when ...")
Link: http://lkml.kernel.org/r/20190516213159.3530-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/video/fbdev/efifb.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -476,8 +476,12 @@ static int efifb_probe(struct platform_d
 * If the UEFI memory map covers the efifb region, we may only
 * remap it using the attributes the memory map prescribes.
 */
-   mem_flags |= EFI_MEMORY_WT | EFI_MEMORY_WB;
-   mem_flags &= md.attribute;
+   md.attribute &= EFI_MEMORY_UC | EFI_MEMORY_WC |
+   EFI_MEMORY_WT | EFI_MEMORY_WB;
+   if (md.attribute) {
+   mem_flags |= EFI_MEMORY_WT | EFI_MEMORY_WB;
+   mem_flags &= md.attribute;
+   }
}
if (mem_flags & EFI_MEMORY_WC)
info->screen_base = ioremap_wc(efifb_fix.smem_start,

[PATCH 4.19 061/114] fbdev/efifb: Ignore framebuffer memmap entries that lack any memory types

[Greg Kroah-Hartman]

From: Ard Biesheuvel 

commit f8585539df0a1527c78b5d760665c89fe1c105a9 upstream.

The following commit:

  38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping 
the FB")

updated the EFI framebuffer code to use memory mappings for the linear
framebuffer that are permitted by the memory attributes described by the
EFI memory map for the particular region, if the framebuffer happens to
be covered by the EFI memory map (which is typically only the case for
framebuffers in shared memory). This is required since non-x86 systems
may require cacheable attributes for memory mappings that are shared
with other masters (such as GPUs), and this information cannot be
described by the Graphics Output Protocol (GOP) EFI protocol itself,
and so we rely on the EFI memory map for this.

As reported by James, this breaks some x86 systems:

  [ 1.173368] efifb: probing for efifb
  [ 1.173386] efifb: abort, cannot remap video memory 0x1d5000 @ 0xcf80
  [ 1.173395] Trying to free nonexistent resource 
<cf80-cf9d4bff>
  [ 1.173413] efi-framebuffer: probe of efi-framebuffer.0 failed with error -5

The problem turns out to be that the memory map entry that describes the
framebuffer has no memory attributes listed at all, and so we end up with
a mem_flags value of 0x0.

So work around this by ensuring that the memory map entry's attribute field
has a sane value before using it to mask the set of usable attributes.

Reported-by: James Hilliard 
Tested-by: James Hilliard 
Signed-off-by: Ard Biesheuvel 
Cc:  # v4.19+
Cc: Borislav Petkov 
Cc: James Morse 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when ...")
Link: http://lkml.kernel.org/r/20190516213159.3530-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/video/fbdev/efifb.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -476,8 +476,12 @@ static int efifb_probe(struct platform_d
 * If the UEFI memory map covers the efifb region, we may only
 * remap it using the attributes the memory map prescribes.
 */
-   mem_flags |= EFI_MEMORY_WT | EFI_MEMORY_WB;
-   mem_flags &= md.attribute;
+   md.attribute &= EFI_MEMORY_UC | EFI_MEMORY_WC |
+   EFI_MEMORY_WT | EFI_MEMORY_WB;
+   if (md.attribute) {
+   mem_flags |= EFI_MEMORY_WT | EFI_MEMORY_WB;
+   mem_flags &= md.attribute;
+   }
}
if (mem_flags & EFI_MEMORY_WC)
info->screen_base = ioremap_wc(efifb_fix.smem_start,

[PATCH 4.19 223/276] efifb: Omit memory map check on legacy boot

[Greg Kroah-Hartman]

[ Upstream commit c2999c281ea2d2ebbdfce96cecc7b52e2ae7c406 ]

Since the following commit:

  38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping 
the FB")

efifb_probe() checks its memory range via efi_mem_desc_lookup(),
and this leads to a spurious error message:

   EFI_MEMMAP is not enabled

at every boot on KVM.  This is quite annoying since the error message
appears even if you set "quiet" boot option.

Since this happens on legacy boot, which strangely enough exposes
a EFI framebuffer via screen_info, let's double check that we are
doing an EFI boot before attempting to access the EFI memory map.

Reported-by: Takashi Iwai 
Tested-by: Takashi Iwai 
Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20190328193429.21373-3-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/efifb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index fd02e8a4841d6..9f39f0c360e0c 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -464,7 +464,8 @@ static int efifb_probe(struct platform_device *dev)
info->apertures->ranges[0].base = efifb_fix.smem_start;
info->apertures->ranges[0].size = size_remap;
 
-   if (!efi_mem_desc_lookup(efifb_fix.smem_start, &md)) {
+   if (efi_enabled(EFI_BOOT) &&
+   !efi_mem_desc_lookup(efifb_fix.smem_start, &md)) {
if ((efifb_fix.smem_start + efifb_fix.smem_len) >
(md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT))) {
pr_err("efifb: video memory @ 0x%lx spans multiple EFI 
memory regions\n",
-- 
2.20.1

[PATCH 5.0 260/346] efifb: Omit memory map check on legacy boot

[Greg Kroah-Hartman]

[ Upstream commit c2999c281ea2d2ebbdfce96cecc7b52e2ae7c406 ]

Since the following commit:

  38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping 
the FB")

efifb_probe() checks its memory range via efi_mem_desc_lookup(),
and this leads to a spurious error message:

   EFI_MEMMAP is not enabled

at every boot on KVM.  This is quite annoying since the error message
appears even if you set "quiet" boot option.

Since this happens on legacy boot, which strangely enough exposes
a EFI framebuffer via screen_info, let's double check that we are
doing an EFI boot before attempting to access the EFI memory map.

Reported-by: Takashi Iwai 
Tested-by: Takashi Iwai 
Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20190328193429.21373-3-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/efifb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index fd02e8a4841d6..9f39f0c360e0c 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -464,7 +464,8 @@ static int efifb_probe(struct platform_device *dev)
info->apertures->ranges[0].base = efifb_fix.smem_start;
info->apertures->ranges[0].size = size_remap;
 
-   if (!efi_mem_desc_lookup(efifb_fix.smem_start, &md)) {
+   if (efi_enabled(EFI_BOOT) &&
+   !efi_mem_desc_lookup(efifb_fix.smem_start, &md)) {
if ((efifb_fix.smem_start + efifb_fix.smem_len) >
(md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT))) {
pr_err("efifb: video memory @ 0x%lx spans multiple EFI 
memory regions\n",
-- 
2.20.1

[PATCH 5.1 289/405] efifb: Omit memory map check on legacy boot

[Greg Kroah-Hartman]

[ Upstream commit c2999c281ea2d2ebbdfce96cecc7b52e2ae7c406 ]

Since the following commit:

  38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping 
the FB")

efifb_probe() checks its memory range via efi_mem_desc_lookup(),
and this leads to a spurious error message:

   EFI_MEMMAP is not enabled

at every boot on KVM.  This is quite annoying since the error message
appears even if you set "quiet" boot option.

Since this happens on legacy boot, which strangely enough exposes
a EFI framebuffer via screen_info, let's double check that we are
doing an EFI boot before attempting to access the EFI memory map.

Reported-by: Takashi Iwai 
Tested-by: Takashi Iwai 
Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20190328193429.21373-3-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/efifb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index fd02e8a4841d6..9f39f0c360e0c 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -464,7 +464,8 @@ static int efifb_probe(struct platform_device *dev)
info->apertures->ranges[0].base = efifb_fix.smem_start;
info->apertures->ranges[0].size = size_remap;
 
-   if (!efi_mem_desc_lookup(efifb_fix.smem_start, &md)) {
+   if (efi_enabled(EFI_BOOT) &&
+   !efi_mem_desc_lookup(efifb_fix.smem_start, &md)) {
if ((efifb_fix.smem_start + efifb_fix.smem_len) >
(md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT))) {
pr_err("efifb: video memory @ 0x%lx spans multiple EFI 
memory regions\n",
-- 
2.20.1

[PATCH 4.9 60/83] efi/libstub: Unify command line param parsing

[Greg Kroah-Hartman]

From: Ard Biesheuvel 

commit 60f38de7a8d4e816100ceafd1b382df52527bd50 upstream.

Merge the parsing of the command line carried out in arm-stub.c with
the handling in efi_parse_options(). Note that this also fixes the
missing handling of CONFIG_CMDLINE_FORCE=y, in which case the builtin
command line should supersede the one passed by the firmware.

Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: b...@redhat.com
Cc: bhsha...@redhat.com
Cc: b...@alien8.de
Cc: eug...@hp.com
Cc: evgeny.kalu...@intel.com
Cc: jh...@codeaurora.org
Cc: leif.lindh...@linaro.org
Cc: linux-efi@vger.kernel.org
Cc: mark.rutl...@arm.com
Cc: roy.fr...@cavium.com
Cc: rruig...@codeaurora.org
Link: http://lkml.kernel.org/r/20170404160910.28115-1-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
[ardb: fix up merge conflicts with 4.9.180]
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/firmware/efi/libstub/arm-stub.c|   23 +++
 drivers/firmware/efi/libstub/arm64-stub.c  |4 +---
 drivers/firmware/efi/libstub/efi-stub-helper.c |   19 +++
 drivers/firmware/efi/libstub/efistub.h |2 ++
 include/linux/efi.h|2 +-
 5 files changed, 22 insertions(+), 28 deletions(-)

--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -18,7 +18,6 @@
 
 #include "efistub.h"
 
-bool __nokaslr;
 
 static int efi_get_secureboot(efi_system_table_t *sys_table_arg)
 {
@@ -268,18 +267,6 @@ unsigned long efi_entry(void *handle, ef
goto fail;
}
 
-   /* check whether 'nokaslr' was passed on the command line */
-   if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
-   static const u8 default_cmdline[] = CONFIG_CMDLINE;
-   const u8 *str, *cmdline = cmdline_ptr;
-
-   if (IS_ENABLED(CONFIG_CMDLINE_FORCE))
-   cmdline = default_cmdline;
-   str = strstr(cmdline, "nokaslr");
-   if (str == cmdline || (str > cmdline && *(str - 1) == ' '))
-   __nokaslr = true;
-   }
-
si = setup_graphics(sys_table);
 
status = handle_kernel_image(sys_table, image_addr, &image_size,
@@ -291,9 +278,13 @@ unsigned long efi_entry(void *handle, ef
goto fail_free_cmdline;
}
 
-   status = efi_parse_options(cmdline_ptr);
-   if (status != EFI_SUCCESS)
-   pr_efi_err(sys_table, "Failed to parse EFI cmdline options\n");
+   if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
+   IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
+   cmdline_size == 0)
+   efi_parse_options(CONFIG_CMDLINE);
+
+   if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && cmdline_size > 0)
+   efi_parse_options(cmdline_ptr);
 
secure_boot = efi_get_secureboot(sys_table);
if (secure_boot > 0)
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@ -24,8 +24,6 @@
 
 #include "efistub.h"
 
-extern bool __nokaslr;
-
 efi_status_t check_platform_features(efi_system_table_t *sys_table_arg)
 {
u64 tg;
@@ -60,7 +58,7 @@ efi_status_t handle_kernel_image(efi_sys
u64 phys_seed = 0;
 
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
-   if (!__nokaslr) {
+   if (!nokaslr()) {
status = efi_get_random_bytes(sys_table_arg,
  sizeof(phys_seed),
  (u8 *)&phys_seed);
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -32,6 +32,13 @@
 
 static unsigned long __chunk_size = EFI_READ_CHUNK_SIZE;
 
+static int __section(.data) __nokaslr;
+
+int __pure nokaslr(void)
+{
+   return __nokaslr;
+}
+
 /*
  * Allow the platform to override the allocation granularity: this allows
  * systems that have the capability to run with a larger page size to deal
@@ -351,17 +358,13 @@ void efi_free(efi_system_table_t *sys_ta
  * environments, first in the early boot environment of the EFI boot
  * stub, and subsequently during the kernel boot.
  */
-efi_status_t efi_parse_options(char *cmdline)
+efi_status_t efi_parse_options(char const *cmdline)
 {
char *str;
 
-   /*
-* Currently, the only efi= option we look for is 'nochunk', which
-* is intended to work around known issues on certain x86 UEFI
-* versions. So ignore for now on other architectures.
-*/
-   if (!IS_ENABLED(CONFIG_X86))
-   return EFI_SUCCESS;
+   str = strstr(cmdline, "nokaslr");
+   if (str == cmdline || (str && str > cmdline && *(str - 1) == ' '))
+   __nokaslr = 1;
 

Re: [PATCH 2/2] powerpc: expose secure variables via sysfs

[Greg Kroah-Hartman]

On Thu, Jun 13, 2019 at 04:50:27PM -0400, Nayna Jain wrote:
> As part of PowerNV secure boot support, OS verification keys are stored
> and controlled by OPAL as secure variables. These need to be exposed to
> the userspace so that sysadmins can perform key management tasks.
> 
> This patch adds the support to expose secure variables via a sysfs
> interface It reuses the the existing efi defined hooks and backend in
> order to maintain the compatibility with the userspace tools.
> 
> Though it reuses a great deal of efi, POWER platforms do not use EFI.
> A new config, POWER_SECVAR_SYSFS, is defined to enable this new sysfs
> interface.
> 
> Signed-off-by: Nayna Jain 
> ---
>  arch/powerpc/Kconfig |   2 +
>  drivers/firmware/Makefile|   1 +
>  drivers/firmware/efi/efivars.c   |   2 +-
>  drivers/firmware/powerpc/Kconfig |  12 +
>  drivers/firmware/powerpc/Makefile|   3 +
>  drivers/firmware/powerpc/efi_error.c |  46 
>  drivers/firmware/powerpc/secvar.c| 326 +++
>  7 files changed, 391 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/firmware/powerpc/Kconfig
>  create mode 100644 drivers/firmware/powerpc/Makefile
>  create mode 100644 drivers/firmware/powerpc/efi_error.c
>  create mode 100644 drivers/firmware/powerpc/secvar.c

If you add/remove/modify sysfs files, you also need to update the
relevant Documentation/ABI/ entry as well.  Please add something there
to describe your new files when you resend the next version of this
patch series.

> diff --git a/drivers/firmware/powerpc/Kconfig 
> b/drivers/firmware/powerpc/Kconfig
> new file mode 100644
> index ..e0303fc517d5
> --- /dev/null
> +++ b/drivers/firmware/powerpc/Kconfig
> @@ -0,0 +1,12 @@
> +config POWER_SECVAR_SYSFS
> + tristate "Enable sysfs interface for POWER secure variables"
> + default n

default is always n, no need to list it.

> --- /dev/null
> +++ b/drivers/firmware/powerpc/efi_error.c
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 IBM Corporation
> + * Author: Nayna Jain 
> + *
> + * efi_error.c
> + *  - Error codes as understood by efi based tools
> + *  Taken from drivers/firmware/efi/efi.c

Why not just export the symbol from the original file instead of
duplicating it here?

> +static int convert_buffer_to_efi_guid(u8 *buffer, efi_guid_t *guid)
> +{
> + u32 *a1;
> + u16 *a2;
> + u16 *a3;
> +
> + a1 = kzalloc(4, GFP_KERNEL);

No error checking in this function for memory issues at all?

> + memcpy(a1, buffer, 4);
> + *a1 = be32_to_cpu(*a1);
> +
> + a2 = kzalloc(2, GFP_KERNEL);
> + memcpy(a2, buffer+4, 2);
> + *a2 = be16_to_cpu(*a2);
> +
> + a3 = kzalloc(2, GFP_KERNEL);
> + memcpy(a3, buffer+6, 2);
> + *a3 = be16_to_cpu(*a3);
> +
> + *guid = EFI_GUID(*a1, *a2, *a3, *(buffer + 8),
> + *(buffer + 9),
> + *(buffer + 10),
> + *(buffer + 11),
> + *(buffer + 12),
> + *(buffer + 13),
> + *(buffer + 14),
> + *(buffer + 15));
> +
> + kfree(a1);
> + kfree(a2);
> + kfree(a3);
> + return 0;
> +}
> +static efi_status_t powerpc_get_next_variable(unsigned long *name_size,
> +   efi_char16_t *name,
> +   efi_guid_t *vendor)
> +{
> + int rc;
> + u8 *key;
> + int namesize;
> + unsigned long keylen;
> + unsigned long keysize = 1024;
> + unsigned long *mdsize;
> + u8 *mdata = NULL;
> + efi_guid_t guid;
> +
> + if (ucs2_strnlen(name, 1024) > 0) {
> + createkey(name, &key, &keylen);
> + } else {
> + keylen = 0;
> + key = kzalloc(1024, GFP_KERNEL);
> + }
> +
> + pr_info("%s: powerpc get next variable, key is %s\n", __func__, key);

Don't put debugging info like this in the kernel log of everyone :(

> +
> + rc = opal_get_next_variable(key, &keylen, keysize);
> + if (rc) {
> + kfree(key);
> + return opal_to_efi_status(rc);
> + }
> +
> + mdsize = kzalloc(sizeof(unsigned long), GFP_KERNEL);

No error checking?

> + rc = opal_get_variable_size(key, keylen, mdsize, NULL);
> + if (rc)
> + goto out;
> +
> + if (*mdsize <= 0)
> + goto out;
> +
> + mdata = kzalloc(*mdsize, GFP_KERNEL);
> +
> + rc = opal_get_variable(key, keylen, mdata, mdsize, NULL, NULL);
> + if (rc)
> + goto out;
> +
> + if (*mdsize > 0) {
> + namesize = *mdsize - sizeof(efi_guid_t) - sizeof(u32);
> + if (namesize > 0) {
> + memset(&guid, 0, sizeof(efi_guid_t));
> + convert_buffer_to_efi_guid(mdata + namesize, &guid);
> + memcpy(vendor, &guid, sizeof(efi_guid_t));
> + memset(name,

Re: [PATCH v2 2/4] powerpc: expose secure variables to userspace via sysfs

[Greg Kroah-Hartman]

On Wed, Aug 21, 2019 at 11:08:21AM -0400, Nayna Jain wrote:
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-secvar
> @@ -0,0 +1,27 @@
> +What:/sys/firmware/secvar
> +Date:August 2019
> +Contact: Nayna Jain 
> +Description:
> + This directory exposes interfaces for interacting with
> + the secure variables managed by OPAL firmware.
> +
> + This is only for the powerpc/powernv platform.
> +
> + Directory:
> + vars:   This directory lists all the variables that
> + are supported by the OPAL. The variables are
> + represented in the form of directories with
> + their variable names. The variable name is
> + unique and is in ASCII representation. The data
> + and size can be determined by reading their
> + respective attribute files.
> +
> + Each variable directory has the following files:
> + name:   An ASCII representation of the variable name
> + data:   A read-only file containing the value of the
> + variable
> + size:   An integer representation of the size of the
> + content of the variable. In other works, it
> + represents the size of the data
> + update: A write-only file that is used to submit the new
> + value for the variable.

Can you break this out into one-entry-per-file like most other entries
are defined?  That makes it easier for tools to parse (specifically the
tool in the tree right now...)



> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 42109682b727..b4bdf77837b2 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -925,6 +925,15 @@ config PPC_SECURE_BOOT
> allows user to enable OS Secure Boot on PowerPC systems that
> have firmware secure boot support.
>  
> +config SECVAR_SYSFS
> +tristate "Enable sysfs interface for POWER secure variables"
> +depends on PPC_SECURE_BOOT

No depends on SYSFS?

> +help
> +  POWER secure variables are managed and controlled by firmware.
> +  These variables are exposed to userspace via sysfs to enable
> +  read/write operations on these variables. Say Y if you have
> +   secure boot enabled and want to expose variables to userspace.

Mix of tabs and spaces :(

> +
>  endmenu
>  
>  config ISA_DMA_API
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index 9041563f1c74..4ea7b738c3a3 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -158,6 +158,7 @@ obj-$(CONFIG_EPAPR_PARAVIRT)  += epapr_paravirt.o 
> epapr_hcalls.o
>  obj-$(CONFIG_KVM_GUEST)  += kvm.o kvm_emul.o
>  
>  obj-$(CONFIG_PPC_SECURE_BOOT)+= secboot.o ima_arch.o secvar-ops.o
> +obj-$(CONFIG_SECVAR_SYSFS) += secvar-sysfs.o

No tab?

>  
>  # Disable GCOV, KCOV & sanitizers in odd or sensitive code
>  GCOV_PROFILE_prom_init.o := n
> diff --git a/arch/powerpc/kernel/secvar-sysfs.c 
> b/arch/powerpc/kernel/secvar-sysfs.c
> new file mode 100644
> index ..e46986bb29a0
> --- /dev/null
> +++ b/arch/powerpc/kernel/secvar-sysfs.c
> @@ -0,0 +1,210 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 IBM Corporation 
> + *
> + * This code exposes secure variables to user via sysfs
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +//Approximating it for now, it is bound to change.

" " before "A" here please.

> +#define VARIABLE_MAX_SIZE  32000
> +
> +static struct kobject *powerpc_kobj;
> +static struct secvar_operations *secvarops;
> +struct kset *secvar_kset;
> +
> +static ssize_t name_show(struct kobject *kobj, struct kobj_attribute *attr,
> +  char *buf)
> +{
> + return sprintf(buf, "%s", kobj->name);
> +}

Why do you need this entry as it is the directory name?  Userspace
already "knows" it if they can open this file.


> +
> +static ssize_t size_show(struct kobject *kobj, struct kobj_attribute *attr,
> +  char *buf)
> +{
> + unsigned long dsize;
> + int rc;
> +
> + rc = secvarops->get_variable(kobj->name, strlen(kobj->name) + 1, NULL,
> +  &dsize);
> + if (rc) {
> + pr_err("Error retrieving variable size %d\n", rc);
> + return rc;
> + }
> +
> + rc = sprintf(buf, "%ld", dsize);
> +
> + return rc;
> +}
> +
> +static ssize_t data_read(struct file *filep, struct kobject *kobj,
> +  struct bin_attribute *attr, char *buf, loff_t off,
> +  size_t count)
> +{
> + unsigned long dsize;
> + int r

Re: [PATCH v2 3/4] x86/efi: move common keyring handler functions to new file

[Greg Kroah-Hartman]

On Wed, Aug 21, 2019 at 11:08:22AM -0400, Nayna Jain wrote:
> This patch moves the common code to keyring_handler.c

That says _what_ you are doing, but not _why_ you are doing it.  We have
no idea :(

Re: [PATCH v2 4/4] powerpc: load firmware trusted keys into kernel keyring

[Greg Kroah-Hartman]

On Wed, Aug 21, 2019 at 11:08:23AM -0400, Nayna Jain wrote:
> The keys used to verify the Host OS kernel are managed by OPAL as secure
> variables. This patch loads the verification keys into the .platform
> keyring and revocation keys into .blacklist keyring. This enables
> verification and loading of the kernels signed by the boot time keys which
> are trusted by firmware.
> 
> Signed-off-by: Nayna Jain 
> ---
>  security/integrity/Kconfig|  9 ++
>  security/integrity/Makefile   |  3 +
>  .../integrity/platform_certs/load_powerpc.c   | 94 +++
>  3 files changed, 106 insertions(+)
>  create mode 100644 security/integrity/platform_certs/load_powerpc.c
> 
> diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig
> index 0bae6adb63a9..2b4109c157e2 100644
> --- a/security/integrity/Kconfig
> +++ b/security/integrity/Kconfig
> @@ -72,6 +72,15 @@ config LOAD_IPL_KEYS
> depends on S390
> def_bool y
>  
> +config LOAD_PPC_KEYS
> + bool "Enable loading of platform and revocation keys for POWER"
> + depends on INTEGRITY_PLATFORM_KEYRING
> + depends on PPC_SECURE_BOOT
> + def_bool y

def_bool y only for things that the system will not boot if it is not
enabled because you added a new feature.  Otherwise just do not set the
default.

> + help
> +   Enable loading of db keys to the .platform keyring and dbx keys to
> +   the .blacklist keyring for powerpc based platforms.
> +
>  config INTEGRITY_AUDIT
>   bool "Enables integrity auditing support "
>   depends on AUDIT
> diff --git a/security/integrity/Makefile b/security/integrity/Makefile
> index 525bf1d6e0db..9eeb6b053de3 100644
> --- a/security/integrity/Makefile
> +++ b/security/integrity/Makefile
> @@ -14,6 +14,9 @@ integrity-$(CONFIG_LOAD_UEFI_KEYS) += 
> platform_certs/efi_parser.o \
> platform_certs/load_uefi.o \
> platform_certs/keyring_handler.o
>  integrity-$(CONFIG_LOAD_IPL_KEYS) += platform_certs/load_ipl_s390.o
> +integrity-$(CONFIG_LOAD_PPC_KEYS) += platform_certs/efi_parser.o \
> +  platform_certs/load_powerpc.o \
> +  platform_certs/keyring_handler.o
>  $(obj)/load_uefi.o: KBUILD_CFLAGS += -fshort-wchar
  
>  subdir-$(CONFIG_IMA) += ima
> diff --git a/security/integrity/platform_certs/load_powerpc.c 
> b/security/integrity/platform_certs/load_powerpc.c
> new file mode 100644
> index ..f4d869171062
> --- /dev/null
> +++ b/security/integrity/platform_certs/load_powerpc.c
> @@ -0,0 +1,94 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 IBM Corporation
> + * Author: Nayna Jain 
> + *
> + * load_powernv.c

That's not the name of this file :(

And the perfect example of why you NEVER have the name of the file in
the file itself, as it's not needed and easy to get wrong :)

thanks,

greg k-h

Re: [PATCH v3 2/4] powerpc: expose secure variables to userspace via sysfs

[Greg Kroah-Hartman]

On Mon, Aug 26, 2019 at 09:23:36AM -0400, Nayna Jain wrote:
> +static struct bin_attribute update_attr = {
> + .attr = {.name = "update", .mode = 0200},
> + .size = VARIABLE_MAX_SIZE,
> + .write = update_write,
> +};

Ah, do we need a __BIN_ATTR_WO() macro for you?  That would make this
more obvious, right?

Other than that minor thing (not a complaint at all) looks much better
to me, nice work:

Reviewed-by: Greg Kroah-Hartman 

Re: [PATCH v3 2/4] powerpc: expose secure variables to userspace via sysfs

[Greg Kroah-Hartman]

On Mon, Aug 26, 2019 at 09:23:36AM -0400, Nayna Jain wrote:
> +static struct kobj_attribute size_attr = __ATTR_RO(size);

Wait, why not just normal ATTR_RO()?

> +static struct bin_attribute data_attr = __BIN_ATTR_RO(data, 
> VARIABLE_MAX_SIZE);

And BIN_ATTR_RO() here?

Do those not work for you somehow?

thanks,

greg k-h

[PATCH] sysfs: add BIN_ATTR_WO() macro

[Greg Kroah-Hartman]

This variant was missing from sysfs.h, I guess no one noticed it before.

Turns out the powerpc secure variable code can use it, so add it to the
tree for it, and potentially others to take advantage of, instead of
open-coding it.

Reported-by: Nayna Jain 
Signed-off-by: Greg Kroah-Hartman 
---

I'll queue this up to my tree for 5.4-rc1, but if you want to take this
in your tree earlier, feel free to do so.

 include/linux/sysfs.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 965236795750..5420817ed317 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -196,6 +196,12 @@ struct bin_attribute {
.size   = _size,\
 }
 
+#define __BIN_ATTR_WO(_name) { \
+   .attr   = { .name = __stringify(_name), .mode = 0200 }, \
+   .store  = _name##_store,\
+   .size   = _size,\
+}
+
 #define __BIN_ATTR_RW(_name, _size)\
__BIN_ATTR(_name, 0644, _name##_read, _name##_write, _size)
 
@@ -208,6 +214,9 @@ struct bin_attribute bin_attr_##_name = __BIN_ATTR(_name, 
_mode, _read, \
 #define BIN_ATTR_RO(_name, _size)  \
 struct bin_attribute bin_attr_##_name = __BIN_ATTR_RO(_name, _size)
 
+#define BIN_ATTR_WO(_name, _size)  \
+struct bin_attribute bin_attr_##_name = __BIN_ATTR_WO(_name, _size)
+
 #define BIN_ATTR_RW(_name, _size)  \
 struct bin_attribute bin_attr_##_name = __BIN_ATTR_RW(_name, _size)
 
-- 
2.23.0

Re: [PATCH v3 2/4] powerpc: expose secure variables to userspace via sysfs

[Greg Kroah-Hartman]

On Mon, Aug 26, 2019 at 11:46:11AM -0400, Nayna wrote:
> 
> 
> On 08/26/2019 10:56 AM, Greg Kroah-Hartman wrote:
> > On Mon, Aug 26, 2019 at 09:23:36AM -0400, Nayna Jain wrote:
> > > +static struct kobj_attribute size_attr = __ATTR_RO(size);
> > Wait, why not just normal ATTR_RO()?
> 
> Oh!! Sorry. I am not seeing this macro in sysfs.h. am I missing something ?

Ugh, no, you are right, I thought it was there as the BIN_ATTR_RO() one
was there :)

> > > +static struct bin_attribute data_attr = __BIN_ATTR_RO(data, 
> > > VARIABLE_MAX_SIZE);
> > And BIN_ATTR_RO() here?
> 
> This would have worked. I think I just thought to use the same way as
> __ATTR_RO().

Yes, that's fine to use, sorry for the noise.

greg k-h

Re: [PATCH] sysfs: add BIN_ATTR_WO() macro

[Greg Kroah-Hartman]

On Tue, Sep 03, 2019 at 01:37:02PM +1000, Michael Ellerman wrote:
> Greg Kroah-Hartman  writes:
> > This variant was missing from sysfs.h, I guess no one noticed it before.
> >
> > Turns out the powerpc secure variable code can use it, so add it to the
> > tree for it, and potentially others to take advantage of, instead of
> > open-coding it.
> >
> > Reported-by: Nayna Jain 
> > Signed-off-by: Greg Kroah-Hartman 
> > ---
> >
> > I'll queue this up to my tree for 5.4-rc1, but if you want to take this
> > in your tree earlier, feel free to do so.
> 
> OK. This series is blocked on the firmware support going in, so at the
> moment it might miss v5.4 anyway. So this going via your tree is no
> problem.

Ok, will queue it up now, thanks!

greg k-h

Re: [PATCH] sysfs: add BIN_ATTR_WO() macro

[Greg Kroah-Hartman]

On Tue, Oct 01, 2019 at 02:08:53PM -0400, Nayna wrote:
> Hi Greg,
> 
> 
> On 08/26/2019 11:01 AM, Greg Kroah-Hartman wrote:
> > This variant was missing from sysfs.h, I guess no one noticed it before.
> > 
> > Turns out the powerpc secure variable code can use it, so add it to the
> > tree for it, and potentially others to take advantage of, instead of
> > open-coding it.
> > 
> > Reported-by: Nayna Jain 
> > Signed-off-by: Greg Kroah-Hartman 
> > ---
> > 
> > I'll queue this up to my tree for 5.4-rc1, but if you want to take this
> > in your tree earlier, feel free to do so.
> > 
> >   include/linux/sysfs.h | 9 +
> >   1 file changed, 9 insertions(+)
> > 
> > diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
> > index 965236795750..5420817ed317 100644
> > --- a/include/linux/sysfs.h
> > +++ b/include/linux/sysfs.h
> > @@ -196,6 +196,12 @@ struct bin_attribute {
> > .size   = _size,\
> >   }
> > +#define __BIN_ATTR_WO(_name) { 
> > \
> > +   .attr   = { .name = __stringify(_name), .mode = 0200 }, \
> > +   .store  = _name##_store,\
> > +   .size   = _size,\
> > +}
> > +
> >   #define __BIN_ATTR_RW(_name, _size)   
> > \
> > __BIN_ATTR(_name, 0644, _name##_read, _name##_write, _size)
> > @@ -208,6 +214,9 @@ struct bin_attribute bin_attr_##_name = 
> > __BIN_ATTR(_name, _mode, _read, \
> >   #define BIN_ATTR_RO(_name, _size) \
> >   struct bin_attribute bin_attr_##_name = __BIN_ATTR_RO(_name, _size)
> > +#define BIN_ATTR_WO(_name, _size)  \
> > +struct bin_attribute bin_attr_##_name = __BIN_ATTR_WO(_name, _size)
> > +
> >   #define BIN_ATTR_RW(_name, _size) \
> >   struct bin_attribute bin_attr_##_name = __BIN_ATTR_RW(_name, _size)
> 
> I am sorry. I didn't notice it via inspection but there is a bug in this
> macro. When I actually try using it, compilation fails. Here's a likely
> patch:
> 
> diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
> index 5420817ed317..fa7ee503fb76 100644
> --- a/include/linux/sysfs.h
> +++ b/include/linux/sysfs.h
> @@ -196,9 +196,9 @@ struct bin_attribute {
> .size   = _size,\
>  }
> -#define __BIN_ATTR_WO(_name) { \
> +#define __BIN_ATTR_WO(_name, _size) {  \
> .attr   = { .name = __stringify(_name), .mode = 0200 }, \
> -   .store  = _name##_store,\
> +   .write  = _name##_write,\
> .size   = _size,\
>  }
> 

Heh, good catch.  Can you send a real patch for this that I can apply to
give you the proper credit for finding and fixing this?

thanks,

greg k-h

[PATCH 5.3 062/112] efivar/ssdt: Dont iterate over EFI vars if no SSDT override was specified

[Greg Kroah-Hartman]

From: Ard Biesheuvel 

commit c05f8f92b701576b615f30aac31fabdc0648649b upstream.

The kernel command line option efivar_ssdt= allows the name to be
specified of an EFI variable containing an ACPI SSDT table that should
be loaded into memory by the OS, and treated as if it was provided by
the firmware.

Currently, that code will always iterate over the EFI variables and
compare each name with the provided name, even if the command line
option wasn't set to begin with.

So bail early when no variable name was provided. This works around a
boot regression on the 2012 Mac Pro, as reported by Scott.

Tested-by: Scott Talbert 
Signed-off-by: Ard Biesheuvel 
Cc:  # v4.9+
Cc: Ben Dooks 
Cc: Dave Young 
Cc: Jarkko Sakkinen 
Cc: Jerry Snitselaar 
Cc: Linus Torvalds 
Cc: Lukas Wunner 
Cc: Lyude Paul 
Cc: Matthew Garrett 
Cc: Octavian Purdila 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Cc: linux-integr...@vger.kernel.org
Fixes: 475fb4e8b2f4 ("efi / ACPI: load SSTDs from EFI variables")
Link: https://lkml.kernel.org/r/20191002165904.8819-3-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/firmware/efi/efi.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -282,6 +282,9 @@ static __init int efivar_ssdt_load(void)
void *data;
int ret;
 
+   if (!efivar_ssdt[0])
+   return 0;
+
ret = efivar_init(efivar_ssdt_iter, &entries, true, &entries);
 
list_for_each_entry_safe(entry, aux, &entries, list) {

[PATCH 5.3 111/112] efi/tpm: Fix sanity check of unsigned tbl_size being less than zero

[Greg Kroah-Hartman]

From: Colin Ian King 

commit be59d57f98065af0b8472f66a0a969207b168680 upstream.

Currently the check for tbl_size being less than zero is always false
because tbl_size is unsigned. Fix this by making it a signed int.

Addresses-Coverity: ("Unsigned compared against 0")
Signed-off-by: Colin Ian King 
Cc: Ard Biesheuvel 
Cc: Jerry Snitselaar 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: kernel-janit...@vger.kernel.org
Cc: linux-efi@vger.kernel.org
Fixes: e658c82be556 ("efi/tpm: Only set 'efi_tpm_final_log_size' after 
successful event log parsing")
Link: https://lkml.kernel.org/r/20191008100153.8499-1-colin.k...@canonical.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/firmware/efi/tpm.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/firmware/efi/tpm.c
+++ b/drivers/firmware/efi/tpm.c
@@ -40,7 +40,7 @@ int __init efi_tpm_eventlog_init(void)
 {
struct linux_efi_tpm_eventlog *log_tbl;
struct efi_tcg2_final_events_table *final_tbl;
-   unsigned int tbl_size;
+   int tbl_size;
int ret = 0;
 
if (efi.tpm_log == EFI_INVALID_TABLE_ADDR) {

[PATCH 5.3 063/112] efi/tpm: Dont access event->count when it isnt mapped

[Greg Kroah-Hartman]

From: Peter Jones 

commit 047d50aee341d940350897c85799e56ae57c3849 upstream.

Some machines generate a lot of event log entries.  When we're
iterating over them, the code removes the old mapping and adds a
new one, so once we cross the page boundary we're unmapping the page
with the count on it.  Hilarity ensues.

This patch keeps the info from the header in local variables so we don't
need to access that page again or keep track of if it's mapped.

Tested-by: Lyude Paul 
Signed-off-by: Peter Jones 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jarkko Sakkinen 
Acked-by: Matthew Garrett 
Acked-by: Ard Biesheuvel 
Cc: Ben Dooks 
Cc: Dave Young 
Cc: Jerry Snitselaar 
Cc: Linus Torvalds 
Cc: Lukas Wunner 
Cc: Octavian Purdila 
Cc: Peter Zijlstra 
Cc: Scott Talbert 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Cc: linux-integr...@vger.kernel.org
Cc: sta...@vger.kernel.org
Fixes: 44038bc514a2 ("tpm: Abstract crypto agile event size calculations")
Link: https://lkml.kernel.org/r/20191002165904.8819-4-ard.biesheu...@linaro.org
[ Minor edits. ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/tpm_eventlog.h |   14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

--- a/include/linux/tpm_eventlog.h
+++ b/include/linux/tpm_eventlog.h
@@ -170,6 +170,7 @@ static inline int __calc_tpm2_event_size
u16 halg;
int i;
int j;
+   u32 count, event_type;
 
marker = event;
marker_start = marker;
@@ -190,16 +191,22 @@ static inline int __calc_tpm2_event_size
}
 
event = (struct tcg_pcr_event2_head *)mapping;
+   /*
+* The loop below will unmap these fields if the log is larger than
+* one page, so save them here for reference:
+*/
+   count = READ_ONCE(event->count);
+   event_type = READ_ONCE(event->event_type);
 
efispecid = (struct tcg_efi_specid_event_head *)event_header->event;
 
/* Check if event is malformed. */
-   if (event->count > efispecid->num_algs) {
+   if (count > efispecid->num_algs) {
size = 0;
goto out;
}
 
-   for (i = 0; i < event->count; i++) {
+   for (i = 0; i < count; i++) {
halg_size = sizeof(event->digests[i].alg_id);
 
/* Map the digest's algorithm identifier */
@@ -256,8 +263,9 @@ static inline int __calc_tpm2_event_size
+ event_field->event_size;
size = marker - marker_start;
 
-   if ((event->event_type == 0) && (event_field->event_size == 0))
+   if (event_type == 0 && event_field->event_size == 0)
size = 0;
+
 out:
if (do_mapping)
TPM_MEMUNMAP(mapping, mapping_size);

[PATCH 5.3 065/112] efi/tpm: Only set efi_tpm_final_log_size after successful event log parsing

[Greg Kroah-Hartman]

From: Jerry Snitselaar 

commit e658c82be5561412c5e83b5e74e9da4830593f3e upstream.

If __calc_tpm2_event_size() fails to parse an event it will return 0,
resulting tpm2_calc_event_log_size() returning -1. Currently there is
no check of this return value, and 'efi_tpm_final_log_size' can end up
being set to this negative value resulting in a crash like this one:

  BUG: unable to handle page fault for address: bc8fc00866ad
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x) - not-present page

  RIP: 0010:memcpy_erms+0x6/0x10
  Call Trace:
   tpm_read_log_efi()
   tpm_bios_log_setup()
   tpm_chip_register()
   tpm_tis_core_init.cold.9+0x28c/0x466
   tpm_tis_plat_probe()
   platform_drv_probe()
   ...

Also __calc_tpm2_event_size() returns a size of 0 when it fails
to parse an event, so update function documentation to reflect this.

The root cause of the issue that caused the failure of event parsing
in this case is resolved by Peter Jone's patchset dealing with large
event logs where crossing over a page boundary causes the page with
the event count to be unmapped.

Signed-off-by: Jerry Snitselaar 
Signed-off-by: Ard Biesheuvel 
Cc: Ben Dooks 
Cc: Dave Young 
Cc: Jarkko Sakkinen 
Cc: Linus Torvalds 
Cc: Lukas Wunner 
Cc: Lyude Paul 
Cc: Matthew Garrett 
Cc: Octavian Purdila 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Scott Talbert 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Cc: linux-integr...@vger.kernel.org
Cc: sta...@vger.kernel.org
Fixes: c46f3405692de ("tpm: Reserve the TPM final events table")
Link: https://lkml.kernel.org/r/20191002165904.8819-6-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/firmware/efi/tpm.c   |9 -
 include/linux/tpm_eventlog.h |2 +-
 2 files changed, 9 insertions(+), 2 deletions(-)

--- a/drivers/firmware/efi/tpm.c
+++ b/drivers/firmware/efi/tpm.c
@@ -85,11 +85,18 @@ int __init efi_tpm_eventlog_init(void)
final_tbl->nr_events,
log_tbl->log);
}
+
+   if (tbl_size < 0) {
+   pr_err(FW_BUG "Failed to parse event in TPM Final Events 
Log\n");
+   goto out_calc;
+   }
+
memblock_reserve((unsigned long)final_tbl,
 tbl_size + sizeof(*final_tbl));
-   early_memunmap(final_tbl, sizeof(*final_tbl));
efi_tpm_final_log_size = tbl_size;
 
+out_calc:
+   early_memunmap(final_tbl, sizeof(*final_tbl));
 out:
early_memunmap(log_tbl, sizeof(*log_tbl));
return ret;
--- a/include/linux/tpm_eventlog.h
+++ b/include/linux/tpm_eventlog.h
@@ -152,7 +152,7 @@ struct tcg_algorithm_info {
  * total. Once we've done this we know the offset of the data length field,
  * and can calculate the total size of the event.
  *
- * Return: size of the event on success, <0 on failure
+ * Return: size of the event on success, 0 on failure
  */
 
 static inline int __calc_tpm2_event_size(struct tcg_pcr_event2_head *event,

[PATCH 5.3 064/112] efi/tpm: Dont traverse an event log with no events

[Greg Kroah-Hartman]

From: Peter Jones 

commit 05c8c1ff81ed2eb9bad7c27cf92e55c864c16df8 upstream.

When there are no entries to put into the final event log, some machines
will return the template they would have populated anyway.  In this case
the nr_events field is 0, but the rest of the log is just garbage.

This patch stops us from trying to iterate the table with
__calc_tpm2_event_size() when the number of events in the table is 0.

Tested-by: Lyude Paul 
Signed-off-by: Peter Jones 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jarkko Sakkinen 
Acked-by: Matthew Garrett 
Acked-by: Ard Biesheuvel 
Cc: Ben Dooks 
Cc: Dave Young 
Cc: Jerry Snitselaar 
Cc: Linus Torvalds 
Cc: Lukas Wunner 
Cc: Octavian Purdila 
Cc: Peter Zijlstra 
Cc: Scott Talbert 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Cc: linux-integr...@vger.kernel.org
Cc: sta...@vger.kernel.org
Fixes: c46f3405692d ("tpm: Reserve the TPM final events table")
Link: https://lkml.kernel.org/r/20191002165904.8819-5-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/firmware/efi/tpm.c |   15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

--- a/drivers/firmware/efi/tpm.c
+++ b/drivers/firmware/efi/tpm.c
@@ -75,11 +75,16 @@ int __init efi_tpm_eventlog_init(void)
goto out;
}
 
-   tbl_size = tpm2_calc_event_log_size((void *)efi.tpm_final_log
-   + sizeof(final_tbl->version)
-   + sizeof(final_tbl->nr_events),
-   final_tbl->nr_events,
-   log_tbl->log);
+   tbl_size = 0;
+   if (final_tbl->nr_events != 0) {
+   void *events = (void *)efi.tpm_final_log
+   + sizeof(final_tbl->version)
+   + sizeof(final_tbl->nr_events);
+
+   tbl_size = tpm2_calc_event_log_size(events,
+   final_tbl->nr_events,
+   log_tbl->log);
+   }
memblock_reserve((unsigned long)final_tbl,
 tbl_size + sizeof(*final_tbl));
early_memunmap(final_tbl, sizeof(*final_tbl));

[PATCH 4.19 49/81] efivar/ssdt: Dont iterate over EFI vars if no SSDT override was specified

[Greg Kroah-Hartman]

From: Ard Biesheuvel 

commit c05f8f92b701576b615f30aac31fabdc0648649b upstream.

The kernel command line option efivar_ssdt= allows the name to be
specified of an EFI variable containing an ACPI SSDT table that should
be loaded into memory by the OS, and treated as if it was provided by
the firmware.

Currently, that code will always iterate over the EFI variables and
compare each name with the provided name, even if the command line
option wasn't set to begin with.

So bail early when no variable name was provided. This works around a
boot regression on the 2012 Mac Pro, as reported by Scott.

Tested-by: Scott Talbert 
Signed-off-by: Ard Biesheuvel 
Cc:  # v4.9+
Cc: Ben Dooks 
Cc: Dave Young 
Cc: Jarkko Sakkinen 
Cc: Jerry Snitselaar 
Cc: Linus Torvalds 
Cc: Lukas Wunner 
Cc: Lyude Paul 
Cc: Matthew Garrett 
Cc: Octavian Purdila 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Cc: linux-integr...@vger.kernel.org
Fixes: 475fb4e8b2f4 ("efi / ACPI: load SSTDs from EFI variables")
Link: https://lkml.kernel.org/r/20191002165904.8819-3-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/firmware/efi/efi.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -281,6 +281,9 @@ static __init int efivar_ssdt_load(void)
void *data;
int ret;
 
+   if (!efivar_ssdt[0])
+   return 0;
+
ret = efivar_init(efivar_ssdt_iter, &entries, true, &entries);
 
list_for_each_entry_safe(entry, aux, &entries, list) {

[PATCH 4.14 43/65] efivar/ssdt: Dont iterate over EFI vars if no SSDT override was specified

[Greg Kroah-Hartman]

From: Ard Biesheuvel 

commit c05f8f92b701576b615f30aac31fabdc0648649b upstream.

The kernel command line option efivar_ssdt= allows the name to be
specified of an EFI variable containing an ACPI SSDT table that should
be loaded into memory by the OS, and treated as if it was provided by
the firmware.

Currently, that code will always iterate over the EFI variables and
compare each name with the provided name, even if the command line
option wasn't set to begin with.

So bail early when no variable name was provided. This works around a
boot regression on the 2012 Mac Pro, as reported by Scott.

Tested-by: Scott Talbert 
Signed-off-by: Ard Biesheuvel 
Cc:  # v4.9+
Cc: Ben Dooks 
Cc: Dave Young 
Cc: Jarkko Sakkinen 
Cc: Jerry Snitselaar 
Cc: Linus Torvalds 
Cc: Lukas Wunner 
Cc: Lyude Paul 
Cc: Matthew Garrett 
Cc: Octavian Purdila 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Cc: linux-integr...@vger.kernel.org
Fixes: 475fb4e8b2f4 ("efi / ACPI: load SSTDs from EFI variables")
Link: https://lkml.kernel.org/r/20191002165904.8819-3-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/firmware/efi/efi.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -266,6 +266,9 @@ static __init int efivar_ssdt_load(void)
void *data;
int ret;
 
+   if (!efivar_ssdt[0])
+   return 0;
+
ret = efivar_init(efivar_ssdt_iter, &entries, true, &entries);
 
list_for_each_entry_safe(entry, aux, &entries, list) {

[PATCH 4.9 76/92] efivar/ssdt: Dont iterate over EFI vars if no SSDT override was specified

[Greg Kroah-Hartman]

From: Ard Biesheuvel 

commit c05f8f92b701576b615f30aac31fabdc0648649b upstream.

The kernel command line option efivar_ssdt= allows the name to be
specified of an EFI variable containing an ACPI SSDT table that should
be loaded into memory by the OS, and treated as if it was provided by
the firmware.

Currently, that code will always iterate over the EFI variables and
compare each name with the provided name, even if the command line
option wasn't set to begin with.

So bail early when no variable name was provided. This works around a
boot regression on the 2012 Mac Pro, as reported by Scott.

Tested-by: Scott Talbert 
Signed-off-by: Ard Biesheuvel 
Cc:  # v4.9+
Cc: Ben Dooks 
Cc: Dave Young 
Cc: Jarkko Sakkinen 
Cc: Jerry Snitselaar 
Cc: Linus Torvalds 
Cc: Lukas Wunner 
Cc: Lyude Paul 
Cc: Matthew Garrett 
Cc: Octavian Purdila 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Cc: linux-integr...@vger.kernel.org
Fixes: 475fb4e8b2f4 ("efi / ACPI: load SSTDs from EFI variables")
Link: https://lkml.kernel.org/r/20191002165904.8819-3-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/firmware/efi/efi.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -243,6 +243,9 @@ static __init int efivar_ssdt_load(void)
void *data;
int ret;
 
+   if (!efivar_ssdt[0])
+   return 0;
+
ret = efivar_init(efivar_ssdt_iter, &entries, true, &entries);
 
list_for_each_entry_safe(entry, aux, &entries, list) {

[PATCH 4.19 133/187] efi/memattr: Dont bail on zero VA if it equals the regions PA

[Greg Kroah-Hartman]

4.19-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 5de0fef0230f3c8d75cff450a71740a7bf2db866 ]

The EFI memory attributes code cross-references the EFI memory map with
the more granular EFI memory attributes table to ensure that they are in
sync before applying the strict permissions to the regions it describes.

Since we always install virtual mappings for the EFI runtime regions to
which these strict permissions apply, we currently perform a sanity check
on the EFI memory descriptor, and ensure that the EFI_MEMORY_RUNTIME bit
is set, and that the virtual address has been assigned.

However, in cases where a runtime region exists at physical address 0x0,
and the virtual mapping equals the physical mapping, e.g., when running
in mixed mode on x86, we encounter a memory descriptor with the runtime
attribute and virtual address 0x0, and incorrectly draw the conclusion
that a runtime region exists for which no virtual mapping was installed,
and give up altogether. The consequence of this is that firmware mappings
retain their read-write-execute permissions, making the system more
vulnerable to attacks.

So let's only bail if the virtual address of 0x0 has been assigned to a
physical region that does not reside at address 0x0.

Signed-off-by: Ard Biesheuvel 
Acked-by: Sai Praneeth Prakhya 
Cc: AKASHI Takahiro 
Cc: Alexander Graf 
Cc: Bjorn Andersson 
Cc: Borislav Petkov 
Cc: Heinrich Schuchardt 
Cc: Jeffrey Hugo 
Cc: Lee Jones 
Cc: Leif Lindholm 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 10f0d2f577053 ("efi: Implement generic support for the Memory ...")
Link: http://lkml.kernel.org/r/20190202094119.13230-4-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/efi/memattr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/memattr.c b/drivers/firmware/efi/memattr.c
index 8986757eafaf..aac972b056d9 100644
--- a/drivers/firmware/efi/memattr.c
+++ b/drivers/firmware/efi/memattr.c
@@ -94,7 +94,7 @@ static bool entry_is_valid(const efi_memory_desc_t *in, 
efi_memory_desc_t *out)
 
if (!(md->attribute & EFI_MEMORY_RUNTIME))
continue;
-   if (md->virt_addr == 0) {
+   if (md->virt_addr == 0 && md->phys_addr != 0) {
/* no virtual mapping has been installed by the stub */
break;
}
-- 
2.19.1

[PATCH 5.0 180/246] efi/arm/arm64: Allow SetVirtualAddressMap() to be omitted

[Greg Kroah-Hartman]

5.0-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 4e46c2a956215482418d7b315749fb1b6c6bc224 ]

The UEFI spec revision 2.7 errata A section 8.4 has the following to
say about the virtual memory runtime services:

  "This section contains function definitions for the virtual memory
  support that may be optionally used by an operating system at runtime.
  If an operating system chooses to make EFI runtime service calls in a
  virtual addressing mode instead of the flat physical mode, then the
  operating system must use the services in this section to switch the
  EFI runtime services from flat physical addressing to virtual
  addressing."

So it is pretty clear that calling SetVirtualAddressMap() is entirely
optional, and so there is no point in doing so unless it achieves
anything useful for us.

This is not the case for 64-bit ARM. The identity mapping used by the
firmware is arbitrarily converted into another permutation of userland
addresses (i.e., bits [63:48] cleared), and the runtime code could easily
deal with the original layout in exactly the same way as it deals with
the converted layout. However, due to constraints related to page size
differences if the OS is not running with 4k pages, and related to
systems that may expose the individual sections of PE/COFF runtime
modules as different memory regions, creating the virtual layout is a
bit fiddly, and requires us to sort the memory map and reason about
adjacent regions with identical memory types etc etc.

So the obvious fix is to stop calling SetVirtualAddressMap() altogether
on arm64 systems. However, to avoid surprises, which are notoriously
hard to diagnose when it comes to OS<->firmware interactions, let's
start by making it an opt-out feature, and implement support for the
'efi=novamap' kernel command line parameter on ARM and arm64 systems.

( Note that 32-bit ARM generally does require SetVirtualAddressMap() to be
  used, given that the physical memory map and the kernel virtual address
  map are not guaranteed to be non-overlapping like on arm64. However,
  having support for efi=novamap,noruntime on 32-bit ARM, combined with
  the recently proposed support for earlycon=efifb, is likely to be useful
  to diagnose boot issues on such systems if they have no accessible serial
  port. )

Tested-by: Jeffrey Hugo 
Tested-by: Bjorn Andersson 
Tested-by: Lee Jones 
Signed-off-by: Ard Biesheuvel 
Cc: AKASHI Takahiro 
Cc: Alexander Graf 
Cc: Borislav Petkov 
Cc: Heinrich Schuchardt 
Cc: Leif Lindholm 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Sai Praneeth Prakhya 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20190202094119.13230-8-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/efi/libstub/arm-stub.c|  5 +
 drivers/firmware/efi/libstub/efi-stub-helper.c | 10 ++
 drivers/firmware/efi/libstub/efistub.h |  1 +
 drivers/firmware/efi/libstub/fdt.c |  3 +++
 4 files changed, 19 insertions(+)

diff --git a/drivers/firmware/efi/libstub/arm-stub.c 
b/drivers/firmware/efi/libstub/arm-stub.c
index c037c6c5d0b7..04e6ecd72cd9 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -367,6 +367,11 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, 
unsigned long map_size,
paddr = in->phys_addr;
size = in->num_pages * EFI_PAGE_SIZE;
 
+   if (novamap()) {
+   in->virt_addr = in->phys_addr;
+   continue;
+   }
+
/*
 * Make the mapping compatible with 64k pages: this allows
 * a 4k page size kernel to kexec a 64k page size kernel and
diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c 
b/drivers/firmware/efi/libstub/efi-stub-helper.c
index e94975f4655b..442f51c2a53d 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -34,6 +34,7 @@ static unsigned long __chunk_size = EFI_READ_CHUNK_SIZE;
 
 static int __section(.data) __nokaslr;
 static int __section(.data) __quiet;
+static int __section(.data) __novamap;
 
 int __pure nokaslr(void)
 {
@@ -43,6 +44,10 @@ int __pure is_quiet(void)
 {
return __quiet;
 }
+int __pure novamap(void)
+{
+   return __novamap;
+}
 
 #define EFI_MMAP_NR_SLACK_SLOTS8
 
@@ -482,6 +487,11 @@ efi_status_t efi_parse_options(char const *cmdline)
__chunk_size = -1UL;
}
 
+   if (!strncmp(str, "novamap", 7)) {
+   str += strlen("novamap");
+   __novamap = 1;
+   }
+
/* Group words together, delimited by "," */
while (*str && *str != ' ' && *str != ',')
str++;
diff --git a/drivers/

[PATCH 5.0 175/246] efi/memattr: Dont bail on zero VA if it equals the regions PA

[Greg Kroah-Hartman]

5.0-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 5de0fef0230f3c8d75cff450a71740a7bf2db866 ]

The EFI memory attributes code cross-references the EFI memory map with
the more granular EFI memory attributes table to ensure that they are in
sync before applying the strict permissions to the regions it describes.

Since we always install virtual mappings for the EFI runtime regions to
which these strict permissions apply, we currently perform a sanity check
on the EFI memory descriptor, and ensure that the EFI_MEMORY_RUNTIME bit
is set, and that the virtual address has been assigned.

However, in cases where a runtime region exists at physical address 0x0,
and the virtual mapping equals the physical mapping, e.g., when running
in mixed mode on x86, we encounter a memory descriptor with the runtime
attribute and virtual address 0x0, and incorrectly draw the conclusion
that a runtime region exists for which no virtual mapping was installed,
and give up altogether. The consequence of this is that firmware mappings
retain their read-write-execute permissions, making the system more
vulnerable to attacks.

So let's only bail if the virtual address of 0x0 has been assigned to a
physical region that does not reside at address 0x0.

Signed-off-by: Ard Biesheuvel 
Acked-by: Sai Praneeth Prakhya 
Cc: AKASHI Takahiro 
Cc: Alexander Graf 
Cc: Bjorn Andersson 
Cc: Borislav Petkov 
Cc: Heinrich Schuchardt 
Cc: Jeffrey Hugo 
Cc: Lee Jones 
Cc: Leif Lindholm 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 10f0d2f577053 ("efi: Implement generic support for the Memory ...")
Link: http://lkml.kernel.org/r/20190202094119.13230-4-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/efi/memattr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/memattr.c b/drivers/firmware/efi/memattr.c
index 8986757eafaf..aac972b056d9 100644
--- a/drivers/firmware/efi/memattr.c
+++ b/drivers/firmware/efi/memattr.c
@@ -94,7 +94,7 @@ static bool entry_is_valid(const efi_memory_desc_t *in, 
efi_memory_desc_t *out)
 
if (!(md->attribute & EFI_MEMORY_RUNTIME))
continue;
-   if (md->virt_addr == 0) {
+   if (md->virt_addr == 0 && md->phys_addr != 0) {
/* no virtual mapping has been installed by the stub */
break;
}
-- 
2.19.1

[PATCH 5.0 126/246] efi: Fix build error due to enum collision between efi.h and ima.h

[Greg Kroah-Hartman]

5.0-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 5c418dc789a3898717ebf2caa5716ba91a7150b2 ]

The following commit:

  a893ea15d764 ("tpm: move tpm_chip definition to include/linux/tpm.h")

introduced a build error when both IMA and EFI are enabled:

In file included from ../security/integrity/ima/ima_fs.c:30:
../security/integrity/ima/ima.h:176:7: error: redeclaration of enumerator 
"NONE"

What happens is that both headers (ima.h and efi.h) defines the same
'NONE' constant, and it broke when they started getting included from
the same file:

Rework to prefix the EFI enum with 'EFI_*'.

Signed-off-by: Anders Roxell 
Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20190215165551.12220-2-ard.biesheu...@linaro.org
[ Cleaned up the changelog a bit. ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 arch/x86/platform/efi/quirks.c  |  4 +--
 drivers/firmware/efi/runtime-wrappers.c | 48 -
 include/linux/efi.h | 26 +++---
 3 files changed, 39 insertions(+), 39 deletions(-)

diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 17456a1d3f04..6c571ae86947 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -717,7 +717,7 @@ void efi_recover_from_page_fault(unsigned long phys_addr)
 * "efi_mm" cannot be used to check if the page fault had occurred
 * in the firmware context because efi=old_map doesn't use efi_pgd.
 */
-   if (efi_rts_work.efi_rts_id == NONE)
+   if (efi_rts_work.efi_rts_id == EFI_NONE)
return;
 
/*
@@ -742,7 +742,7 @@ void efi_recover_from_page_fault(unsigned long phys_addr)
 * because this case occurs *very* rarely and hence could be improved
 * on a need by basis.
 */
-   if (efi_rts_work.efi_rts_id == RESET_SYSTEM) {
+   if (efi_rts_work.efi_rts_id == EFI_RESET_SYSTEM) {
pr_info("efi_reset_system() buggy! Reboot through BIOS\n");
machine_real_restart(MRR_BIOS);
return;
diff --git a/drivers/firmware/efi/runtime-wrappers.c 
b/drivers/firmware/efi/runtime-wrappers.c
index e2abfdb5cee6..698745c249e8 100644
--- a/drivers/firmware/efi/runtime-wrappers.c
+++ b/drivers/firmware/efi/runtime-wrappers.c
@@ -85,7 +85,7 @@ struct efi_runtime_work efi_rts_work;
pr_err("Failed to queue work to efi_rts_wq.\n");\
\
 exit:  \
-   efi_rts_work.efi_rts_id = NONE; \
+   efi_rts_work.efi_rts_id = EFI_NONE; \
efi_rts_work.status;\
 })
 
@@ -175,50 +175,50 @@ static void efi_call_rts(struct work_struct *work)
arg5 = efi_rts_work.arg5;
 
switch (efi_rts_work.efi_rts_id) {
-   case GET_TIME:
+   case EFI_GET_TIME:
status = efi_call_virt(get_time, (efi_time_t *)arg1,
   (efi_time_cap_t *)arg2);
break;
-   case SET_TIME:
+   case EFI_SET_TIME:
status = efi_call_virt(set_time, (efi_time_t *)arg1);
break;
-   case GET_WAKEUP_TIME:
+   case EFI_GET_WAKEUP_TIME:
status = efi_call_virt(get_wakeup_time, (efi_bool_t *)arg1,
   (efi_bool_t *)arg2, (efi_time_t *)arg3);
break;
-   case SET_WAKEUP_TIME:
+   case EFI_SET_WAKEUP_TIME:
status = efi_call_virt(set_wakeup_time, *(efi_bool_t *)arg1,
   (efi_time_t *)arg2);
break;
-   case GET_VARIABLE:
+   case EFI_GET_VARIABLE:
status = efi_call_virt(get_variable, (efi_char16_t *)arg1,
   (efi_guid_t *)arg2, (u32 *)arg3,
   (unsigned long *)arg4, (void *)arg5);
break;
-   case GET_NEXT_VARIABLE:
+   case EFI_GET_NEXT_VARIABLE:
status = efi_call_virt(get_next_variable, (unsigned long *)arg1,
   (efi_char16_t *)arg2,
   (efi_guid_t *)arg3);
break;
-   case SET_VARIABLE:
+   case EFI_SET_VARIABLE:
status = efi_call_virt(set_variable, (efi_char16_t *)arg1,
   (efi_guid_t *)arg2, *(u32 *)arg3,
   *(unsigned long *)arg4, (void *)arg5);
break;
-   case QUERY_VARIABLE_INFO:
+   case EFI_QUERY_VARIABLE_INFO:
status = efi_call_virt(query_variable_info, *(u3

[PATCH 4.19 137/187] efi/arm/arm64: Allow SetVirtualAddressMap() to be omitted

[Greg Kroah-Hartman]

4.19-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 4e46c2a956215482418d7b315749fb1b6c6bc224 ]

The UEFI spec revision 2.7 errata A section 8.4 has the following to
say about the virtual memory runtime services:

  "This section contains function definitions for the virtual memory
  support that may be optionally used by an operating system at runtime.
  If an operating system chooses to make EFI runtime service calls in a
  virtual addressing mode instead of the flat physical mode, then the
  operating system must use the services in this section to switch the
  EFI runtime services from flat physical addressing to virtual
  addressing."

So it is pretty clear that calling SetVirtualAddressMap() is entirely
optional, and so there is no point in doing so unless it achieves
anything useful for us.

This is not the case for 64-bit ARM. The identity mapping used by the
firmware is arbitrarily converted into another permutation of userland
addresses (i.e., bits [63:48] cleared), and the runtime code could easily
deal with the original layout in exactly the same way as it deals with
the converted layout. However, due to constraints related to page size
differences if the OS is not running with 4k pages, and related to
systems that may expose the individual sections of PE/COFF runtime
modules as different memory regions, creating the virtual layout is a
bit fiddly, and requires us to sort the memory map and reason about
adjacent regions with identical memory types etc etc.

So the obvious fix is to stop calling SetVirtualAddressMap() altogether
on arm64 systems. However, to avoid surprises, which are notoriously
hard to diagnose when it comes to OS<->firmware interactions, let's
start by making it an opt-out feature, and implement support for the
'efi=novamap' kernel command line parameter on ARM and arm64 systems.

( Note that 32-bit ARM generally does require SetVirtualAddressMap() to be
  used, given that the physical memory map and the kernel virtual address
  map are not guaranteed to be non-overlapping like on arm64. However,
  having support for efi=novamap,noruntime on 32-bit ARM, combined with
  the recently proposed support for earlycon=efifb, is likely to be useful
  to diagnose boot issues on such systems if they have no accessible serial
  port. )

Tested-by: Jeffrey Hugo 
Tested-by: Bjorn Andersson 
Tested-by: Lee Jones 
Signed-off-by: Ard Biesheuvel 
Cc: AKASHI Takahiro 
Cc: Alexander Graf 
Cc: Borislav Petkov 
Cc: Heinrich Schuchardt 
Cc: Leif Lindholm 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Sai Praneeth Prakhya 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20190202094119.13230-8-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/efi/libstub/arm-stub.c|  5 +
 drivers/firmware/efi/libstub/efi-stub-helper.c | 10 ++
 drivers/firmware/efi/libstub/efistub.h |  1 +
 drivers/firmware/efi/libstub/fdt.c |  3 +++
 4 files changed, 19 insertions(+)

diff --git a/drivers/firmware/efi/libstub/arm-stub.c 
b/drivers/firmware/efi/libstub/arm-stub.c
index 6920033de6d4..6c09644d620e 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -340,6 +340,11 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, 
unsigned long map_size,
paddr = in->phys_addr;
size = in->num_pages * EFI_PAGE_SIZE;
 
+   if (novamap()) {
+   in->virt_addr = in->phys_addr;
+   continue;
+   }
+
/*
 * Make the mapping compatible with 64k pages: this allows
 * a 4k page size kernel to kexec a 64k page size kernel and
diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c 
b/drivers/firmware/efi/libstub/efi-stub-helper.c
index e94975f4655b..442f51c2a53d 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -34,6 +34,7 @@ static unsigned long __chunk_size = EFI_READ_CHUNK_SIZE;
 
 static int __section(.data) __nokaslr;
 static int __section(.data) __quiet;
+static int __section(.data) __novamap;
 
 int __pure nokaslr(void)
 {
@@ -43,6 +44,10 @@ int __pure is_quiet(void)
 {
return __quiet;
 }
+int __pure novamap(void)
+{
+   return __novamap;
+}
 
 #define EFI_MMAP_NR_SLACK_SLOTS8
 
@@ -482,6 +487,11 @@ efi_status_t efi_parse_options(char const *cmdline)
__chunk_size = -1UL;
}
 
+   if (!strncmp(str, "novamap", 7)) {
+   str += strlen("novamap");
+   __novamap = 1;
+   }
+
/* Group words together, delimited by "," */
while (*str && *str != ' ' && *str != ',')
str++;
diff --git a/drivers

[PATCH 4.14 087/121] efi/memattr: Dont bail on zero VA if it equals the regions PA

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 5de0fef0230f3c8d75cff450a71740a7bf2db866 ]

The EFI memory attributes code cross-references the EFI memory map with
the more granular EFI memory attributes table to ensure that they are in
sync before applying the strict permissions to the regions it describes.

Since we always install virtual mappings for the EFI runtime regions to
which these strict permissions apply, we currently perform a sanity check
on the EFI memory descriptor, and ensure that the EFI_MEMORY_RUNTIME bit
is set, and that the virtual address has been assigned.

However, in cases where a runtime region exists at physical address 0x0,
and the virtual mapping equals the physical mapping, e.g., when running
in mixed mode on x86, we encounter a memory descriptor with the runtime
attribute and virtual address 0x0, and incorrectly draw the conclusion
that a runtime region exists for which no virtual mapping was installed,
and give up altogether. The consequence of this is that firmware mappings
retain their read-write-execute permissions, making the system more
vulnerable to attacks.

So let's only bail if the virtual address of 0x0 has been assigned to a
physical region that does not reside at address 0x0.

Signed-off-by: Ard Biesheuvel 
Acked-by: Sai Praneeth Prakhya 
Cc: AKASHI Takahiro 
Cc: Alexander Graf 
Cc: Bjorn Andersson 
Cc: Borislav Petkov 
Cc: Heinrich Schuchardt 
Cc: Jeffrey Hugo 
Cc: Lee Jones 
Cc: Leif Lindholm 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 10f0d2f577053 ("efi: Implement generic support for the Memory ...")
Link: http://lkml.kernel.org/r/20190202094119.13230-4-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/efi/memattr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/memattr.c b/drivers/firmware/efi/memattr.c
index 8986757eafaf..aac972b056d9 100644
--- a/drivers/firmware/efi/memattr.c
+++ b/drivers/firmware/efi/memattr.c
@@ -94,7 +94,7 @@ static bool entry_is_valid(const efi_memory_desc_t *in, 
efi_memory_desc_t *out)
 
if (!(md->attribute & EFI_MEMORY_RUNTIME))
continue;
-   if (md->virt_addr == 0) {
+   if (md->virt_addr == 0 && md->phys_addr != 0) {
/* no virtual mapping has been installed by the stub */
break;
}
-- 
2.19.1

[PATCH 4.14 089/121] efi/arm/arm64: Allow SetVirtualAddressMap() to be omitted

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 4e46c2a956215482418d7b315749fb1b6c6bc224 ]

The UEFI spec revision 2.7 errata A section 8.4 has the following to
say about the virtual memory runtime services:

  "This section contains function definitions for the virtual memory
  support that may be optionally used by an operating system at runtime.
  If an operating system chooses to make EFI runtime service calls in a
  virtual addressing mode instead of the flat physical mode, then the
  operating system must use the services in this section to switch the
  EFI runtime services from flat physical addressing to virtual
  addressing."

So it is pretty clear that calling SetVirtualAddressMap() is entirely
optional, and so there is no point in doing so unless it achieves
anything useful for us.

This is not the case for 64-bit ARM. The identity mapping used by the
firmware is arbitrarily converted into another permutation of userland
addresses (i.e., bits [63:48] cleared), and the runtime code could easily
deal with the original layout in exactly the same way as it deals with
the converted layout. However, due to constraints related to page size
differences if the OS is not running with 4k pages, and related to
systems that may expose the individual sections of PE/COFF runtime
modules as different memory regions, creating the virtual layout is a
bit fiddly, and requires us to sort the memory map and reason about
adjacent regions with identical memory types etc etc.

So the obvious fix is to stop calling SetVirtualAddressMap() altogether
on arm64 systems. However, to avoid surprises, which are notoriously
hard to diagnose when it comes to OS<->firmware interactions, let's
start by making it an opt-out feature, and implement support for the
'efi=novamap' kernel command line parameter on ARM and arm64 systems.

( Note that 32-bit ARM generally does require SetVirtualAddressMap() to be
  used, given that the physical memory map and the kernel virtual address
  map are not guaranteed to be non-overlapping like on arm64. However,
  having support for efi=novamap,noruntime on 32-bit ARM, combined with
  the recently proposed support for earlycon=efifb, is likely to be useful
  to diagnose boot issues on such systems if they have no accessible serial
  port. )

Tested-by: Jeffrey Hugo 
Tested-by: Bjorn Andersson 
Tested-by: Lee Jones 
Signed-off-by: Ard Biesheuvel 
Cc: AKASHI Takahiro 
Cc: Alexander Graf 
Cc: Borislav Petkov 
Cc: Heinrich Schuchardt 
Cc: Leif Lindholm 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Sai Praneeth Prakhya 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20190202094119.13230-8-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/efi/libstub/arm-stub.c|  5 +
 drivers/firmware/efi/libstub/efi-stub-helper.c | 10 ++
 drivers/firmware/efi/libstub/efistub.h |  1 +
 drivers/firmware/efi/libstub/fdt.c |  3 +++
 4 files changed, 19 insertions(+)

diff --git a/drivers/firmware/efi/libstub/arm-stub.c 
b/drivers/firmware/efi/libstub/arm-stub.c
index 01a9d78ee415..3b1e1dc3fb46 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -364,6 +364,11 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, 
unsigned long map_size,
paddr = in->phys_addr;
size = in->num_pages * EFI_PAGE_SIZE;
 
+   if (novamap()) {
+   in->virt_addr = in->phys_addr;
+   continue;
+   }
+
/*
 * Make the mapping compatible with 64k pages: this allows
 * a 4k page size kernel to kexec a 64k page size kernel and
diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c 
b/drivers/firmware/efi/libstub/efi-stub-helper.c
index 50a9cab5a834..39f87e6dac5c 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -34,6 +34,7 @@ static unsigned long __chunk_size = EFI_READ_CHUNK_SIZE;
 
 static int __section(.data) __nokaslr;
 static int __section(.data) __quiet;
+static int __section(.data) __novamap;
 
 int __pure nokaslr(void)
 {
@@ -43,6 +44,10 @@ int __pure is_quiet(void)
 {
return __quiet;
 }
+int __pure novamap(void)
+{
+   return __novamap;
+}
 
 #define EFI_MMAP_NR_SLACK_SLOTS8
 
@@ -454,6 +459,11 @@ efi_status_t efi_parse_options(char const *cmdline)
__chunk_size = -1UL;
}
 
+   if (!strncmp(str, "novamap", 7)) {
+   str += strlen("novamap");
+   __novamap = 1;
+   }
+
/* Group words together, delimited by "," */
while (*str && *str != ' ' && *str != ',')
str++;
diff --git a/drivers

[PATCH 4.9 67/91] efi/memattr: Dont bail on zero VA if it equals the regions PA

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 5de0fef0230f3c8d75cff450a71740a7bf2db866 ]

The EFI memory attributes code cross-references the EFI memory map with
the more granular EFI memory attributes table to ensure that they are in
sync before applying the strict permissions to the regions it describes.

Since we always install virtual mappings for the EFI runtime regions to
which these strict permissions apply, we currently perform a sanity check
on the EFI memory descriptor, and ensure that the EFI_MEMORY_RUNTIME bit
is set, and that the virtual address has been assigned.

However, in cases where a runtime region exists at physical address 0x0,
and the virtual mapping equals the physical mapping, e.g., when running
in mixed mode on x86, we encounter a memory descriptor with the runtime
attribute and virtual address 0x0, and incorrectly draw the conclusion
that a runtime region exists for which no virtual mapping was installed,
and give up altogether. The consequence of this is that firmware mappings
retain their read-write-execute permissions, making the system more
vulnerable to attacks.

So let's only bail if the virtual address of 0x0 has been assigned to a
physical region that does not reside at address 0x0.

Signed-off-by: Ard Biesheuvel 
Acked-by: Sai Praneeth Prakhya 
Cc: AKASHI Takahiro 
Cc: Alexander Graf 
Cc: Bjorn Andersson 
Cc: Borislav Petkov 
Cc: Heinrich Schuchardt 
Cc: Jeffrey Hugo 
Cc: Lee Jones 
Cc: Leif Lindholm 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 10f0d2f577053 ("efi: Implement generic support for the Memory ...")
Link: http://lkml.kernel.org/r/20190202094119.13230-4-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/efi/memattr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/memattr.c b/drivers/firmware/efi/memattr.c
index 236004b9a50d..9faa09e7c31f 100644
--- a/drivers/firmware/efi/memattr.c
+++ b/drivers/firmware/efi/memattr.c
@@ -93,7 +93,7 @@ static bool entry_is_valid(const efi_memory_desc_t *in, 
efi_memory_desc_t *out)
 
if (!(md->attribute & EFI_MEMORY_RUNTIME))
continue;
-   if (md->virt_addr == 0) {
+   if (md->virt_addr == 0 && md->phys_addr != 0) {
/* no virtual mapping has been installed by the stub */
break;
}
-- 
2.19.1

[PATCH 4.19 083/100] x86/fpu: Dont export __kernel_fpu_{begin,end}()

[Greg Kroah-Hartman]

From: Sebastian Andrzej Siewior 

commit 12209993e98c5fa1855c467f22a24e3d5b8be205 upstream.

There is one user of __kernel_fpu_begin() and before invoking it,
it invokes preempt_disable(). So it could invoke kernel_fpu_begin()
right away. The 32bit version of arch_efi_call_virt_setup() and
arch_efi_call_virt_teardown() does this already.

The comment above *kernel_fpu*() claims that before invoking
__kernel_fpu_begin() preemption should be disabled and that KVM is a
good example of doing it. Well, KVM doesn't do that since commit

  f775b13eedee2 ("x86,kvm: move qemu/guest FPU switching out to vcpu_run")

so it is not an example anymore.

With EFI gone as the last user of __kernel_fpu_{begin|end}(), both can
be made static and not exported anymore.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Borislav Petkov 
Reviewed-by: Rik van Riel 
Cc: "H. Peter Anvin" 
Cc: "Jason A. Donenfeld" 
Cc: Andy Lutomirski 
Cc: Ard Biesheuvel 
Cc: Dave Hansen 
Cc: Ingo Molnar 
Cc: Nicolai Stange 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Thomas Gleixner 
Cc: kvm ML 
Cc: linux-efi 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20181129150210.2k4mawt37ow6c...@linutronix.de
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/efi.h |6 ++
 arch/x86/include/asm/fpu/api.h |   15 +--
 arch/x86/kernel/fpu/core.c |6 ++
 3 files changed, 9 insertions(+), 18 deletions(-)

--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -82,8 +82,7 @@ struct efi_scratch {
 #define arch_efi_call_virt_setup() \
 ({ \
efi_sync_low_kernel_mappings(); \
-   preempt_disable();  \
-   __kernel_fpu_begin();   \
+   kernel_fpu_begin(); \
firmware_restrict_branch_speculation_start();   \
\
if (!efi_enabled(EFI_OLD_MEMMAP))   \
@@ -99,8 +98,7 @@ struct efi_scratch {
efi_switch_mm(efi_scratch.prev_mm); \
\
firmware_restrict_branch_speculation_end(); \
-   __kernel_fpu_end(); \
-   preempt_enable();   \
+   kernel_fpu_end();   \
 })
 
 extern void __iomem *__init efi_ioremap(unsigned long addr, unsigned long size,
--- a/arch/x86/include/asm/fpu/api.h
+++ b/arch/x86/include/asm/fpu/api.h
@@ -12,17 +12,12 @@
 #define _ASM_X86_FPU_API_H
 
 /*
- * Careful: __kernel_fpu_begin/end() must be called with preempt disabled
- * and they don't touch the preempt state on their own.
- * If you enable preemption after __kernel_fpu_begin(), preempt notifier
- * should call the __kernel_fpu_end() to prevent the kernel/user FPU
- * state from getting corrupted. KVM for example uses this model.
- *
- * All other cases use kernel_fpu_begin/end() which disable preemption
- * during kernel FPU usage.
+ * Use kernel_fpu_begin/end() if you intend to use FPU in kernel context. It
+ * disables preemption so be careful if you intend to use it for long periods
+ * of time.
+ * If you intend to use the FPU in softirq you need to check first with
+ * irq_fpu_usable() if it is possible.
  */
-extern void __kernel_fpu_begin(void);
-extern void __kernel_fpu_end(void);
 extern void kernel_fpu_begin(void);
 extern void kernel_fpu_end(void);
 extern bool irq_fpu_usable(void);
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -93,7 +93,7 @@ bool irq_fpu_usable(void)
 }
 EXPORT_SYMBOL(irq_fpu_usable);
 
-void __kernel_fpu_begin(void)
+static void __kernel_fpu_begin(void)
 {
struct fpu *fpu = ¤t->thread.fpu;
 
@@ -111,9 +111,8 @@ void __kernel_fpu_begin(void)
__cpu_invalidate_fpregs_state();
}
 }
-EXPORT_SYMBOL(__kernel_fpu_begin);
 
-void __kernel_fpu_end(void)
+static void __kernel_fpu_end(void)
 {
struct fpu *fpu = ¤t->thread.fpu;
 
@@ -122,7 +121,6 @@ void __kernel_fpu_end(void)
 
kernel_fpu_enable();
 }
-EXPORT_SYMBOL(__kernel_fpu_end);
 
 void kernel_fpu_begin(void)
 {

[PATCH 4.19 20/99] efi: Fix debugobjects warning on efi_rts_work

[Greg Kroah-Hartman]

[ Upstream commit ef1491e791308317bb9851a0ad380c4a68b58d54 ]

The following commit:

  9dbbedaa6171 ("efi: Make efi_rts_work accessible to efi page fault handler")

converted 'efi_rts_work' from an auto variable to a global variable.
However, when submitting the work, INIT_WORK_ONSTACK() was still used,
causing the following complaint from debugobjects:

  ODEBUG: object ed27b500 is NOT on stack c7d38760, but 
annotated.

Change the macro to just INIT_WORK() to eliminate the warning.

Signed-off-by: Waiman Long 
Signed-off-by: Ard Biesheuvel 
Acked-by: Sai Praneeth Prakhya 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 9dbbedaa6171 ("efi: Make efi_rts_work accessible to efi page fault 
handler")
Link: http://lkml.kernel.org/r/20181114175544.12860-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/efi/runtime-wrappers.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/runtime-wrappers.c 
b/drivers/firmware/efi/runtime-wrappers.c
index b0aeffd4e269..1606abead22c 100644
--- a/drivers/firmware/efi/runtime-wrappers.c
+++ b/drivers/firmware/efi/runtime-wrappers.c
@@ -95,7 +95,7 @@ struct efi_runtime_work {
efi_rts_work.status = EFI_ABORTED;  \
\
init_completion(&efi_rts_work.efi_rts_comp);\
-   INIT_WORK_ONSTACK(&efi_rts_work.work, efi_call_rts);\
+   INIT_WORK(&efi_rts_work.work, efi_call_rts);\
efi_rts_work.arg1 = _arg1;  \
efi_rts_work.arg2 = _arg2;  \
efi_rts_work.arg3 = _arg3;  \
-- 
2.20.1

Re: [PATCH 1/2] sysfs: Add sysfs_bin_attr_simple_read() helper

[Greg Kroah-Hartman]

On Sat, Apr 06, 2024 at 03:52:01PM +0200, Lukas Wunner wrote:
> When drivers expose a bin_attribute in sysfs which is backed by a buffer
> in memory, a common pattern is to set the @private and @size members in
> struct bin_attribute to the buffer's location and size.
> 
> The ->read() callback then merely consists of a single memcpy() call.
> It's not even necessary to perform bounds checks as these are already
> handled by sysfs_kf_bin_read().
> 
> However each driver is so far providing its own ->read() implementation.
> The pattern is sufficiently frequent to merit a public helper, so add
> sysfs_bin_attr_simple_read() as well as BIN_ATTR_SIMPLE_RO() and
> BIN_ATTR_SIMPLE_ADMIN_RO() macros to ease declaration of such
> bin_attributes and reduce LoC and .text section size.
> 
> Signed-off-by: Lukas Wunner 
> ---
>  fs/sysfs/file.c   | 27 +++
>  include/linux/sysfs.h | 15 +++++++
>  2 files changed, 42 insertions(+)

Reviewed-by: Greg Kroah-Hartman 

Re: [PATCH 0/2] Deduplicate bin_attribute simple read() callbacks

[Greg Kroah-Hartman]

On Sat, Apr 06, 2024 at 03:52:00PM +0200, Lukas Wunner wrote:
> For my upcoming PCI device authentication v2 patches, I have the need
> to expose a simple buffer in virtual memory as a bin_attribute.
> 
> It turns out we've duplicated the ->read() callback for such simple
> buffers a fair number of times across the tree.
> 
> So instead of reinventing the wheel, I decided to introduce a common
> helper and eliminate all duplications I could find.
> 
> I'm open to a bikeshedding discussion on the sysfs_bin_attr_simple_read()
> name. ;)

Seems like no one objects, should I just take this through my
driver-core tree for 6.10?

thanks,

greg k-h

Re: [PATCH 2/2] treewide: Use sysfs_bin_attr_simple_read() helper

[Greg Kroah-Hartman]

On Wed, May 22, 2024 at 07:51:35PM -0700, Guenter Roeck wrote:
> Hi,
> 
> On Sat, Apr 06, 2024 at 03:52:02PM +0200, Lukas Wunner wrote:
> > Deduplicate ->read() callbacks of bin_attributes which are backed by a
> > simple buffer in memory:
> > 
> > Use the newly introduced sysfs_bin_attr_simple_read() helper instead,
> > either by referencing it directly or by declaring such bin_attributes
> > with BIN_ATTR_SIMPLE_RO() or BIN_ATTR_SIMPLE_ADMIN_RO().
> > 
> > Aside from a reduction of LoC, this shaves off a few bytes from vmlinux
> > (304 bytes on an x86_64 allyesconfig).
> > 
> > No functional change intended.
> > 
> 
> Not really; see below.
> 
> > Signed-off-by: Lukas Wunner 
> > Acked-by: Michael Ellerman  (powerpc)
> > ---
> ...
> > index da79760..5193fae 100644
> > --- a/init/initramfs.c
> > +++ b/init/initramfs.c
> > @@ -575,15 +575,7 @@ static int __init initramfs_async_setup(char *str)
> >  #include 
> >  #include 
> >  
> > -static ssize_t raw_read(struct file *file, struct kobject *kobj,
> > -   struct bin_attribute *attr, char *buf,
> > -   loff_t pos, size_t count)
> > -{
> > -   memcpy(buf, attr->private + pos, count);
> > -   return count;
> > -}
> > -
> > -static BIN_ATTR(initrd, 0440, raw_read, NULL, 0);
> > +static BIN_ATTR(initrd, 0440, sysfs_bin_attr_simple_read, NULL, 0);
> >  
> 
> sysfs_bin_attr_simple_read is only declared and available if CONFIG_SYSFS=y.
> With m68k:m5208evb_defconfig + CONFIG_BLK_DEV_INITRD=y, this results in
> 
> /opt/buildbot/slave/qemu-m68k/build/init/initramfs.c:578:31:
>   error: 'sysfs_bin_attr_simple_read' undeclared here (not in a function)
> 
> This happens because CONFIG_SYSFS=n and there is no dummy function for
> sysfs_bin_attr_simple_read(). Presumably the problem will be seen for all
> configurations with CONFIG_BLK_DEV_INITRD=y and CONFIG_SYSFS=n.

Lukas, can you send a patch adding a dummy function?

thanks,

greg k-h

[PATCH 4.9 034/119] efi: Dont issue error message when booted under Xen

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Juergen Gross 

commit 1ea34adb87c969b89dfd83f1905a79161e9ada26 upstream.

When booted as Xen dom0 there won't be an EFI memmap allocated. Avoid
issuing an error message in this case:

  [0.144079] efi: Failed to allocate new EFI memmap

Signed-off-by: Juergen Gross 
Signed-off-by: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20170526113652.21339-2-m...@codeblueprint.co.uk
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/platform/efi/quirks.c |3 +++
 1 file changed, 3 insertions(+)

--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -358,6 +358,9 @@ void __init efi_free_boot_services(void)
free_bootmem_late(start, size);
}
 
+   if (!num_entries)
+   return;
+
new_size = efi.memmap.desc_size * num_entries;
new_phys = efi_memmap_alloc(num_entries);
if (!new_phys) {


--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4.11 049/150] efi/bgrt: Skip efi_bgrt_init() in case of non-EFI boot

[Greg Kroah-Hartman]

4.11-stable review patch.  If anyone has any objections, please let me know.

--

From: Dave Young 

commit 7425826f4f7ac60f2538b06a7f0a5d1006405159 upstream.

Sabrina Dubroca reported an early panic:

  BUG: unable to handle kernel paging request at ff240001
  IP: efi_bgrt_init+0xdc/0x134

  [...]

  ---[ end Kernel panic - not syncing: Attempted to kill the idle task!

... which was introduced by:

  7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init code")

The cause is that on this machine the firmware provides the EFI ACPI BGRT
table even on legacy non-EFI bootups - which table should be EFI only.

The garbage BGRT data causes the efi_bgrt_init() panic.

Add a check to skip efi_bgrt_init() in case non-EFI bootup to work around
this firmware bug.

Tested-by: Sabrina Dubroca 
Signed-off-by: Dave Young 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Matt Fleming 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init code")
Link: http://lkml.kernel.org/r/20170526113652.21339-6-m...@codeblueprint.co.uk
[ Rewrote the changelog to be more readable. ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/platform/efi/efi-bgrt.c |3 +++
 1 file changed, 3 insertions(+)

--- a/arch/x86/platform/efi/efi-bgrt.c
+++ b/arch/x86/platform/efi/efi-bgrt.c
@@ -36,6 +36,9 @@ void __init efi_bgrt_init(struct acpi_ta
if (acpi_disabled)
return;
 
+   if (!efi_enabled(EFI_BOOT))
+   return;
+
if (table->length < sizeof(bgrt_tab)) {
pr_notice("Ignoring BGRT: invalid length %u (expected %zu)\n",
   table->length, sizeof(bgrt_tab));


--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4.11 048/150] efi: Dont issue error message when booted under Xen

[Greg Kroah-Hartman]

4.11-stable review patch.  If anyone has any objections, please let me know.

--

From: Juergen Gross 

commit 1ea34adb87c969b89dfd83f1905a79161e9ada26 upstream.

When booted as Xen dom0 there won't be an EFI memmap allocated. Avoid
issuing an error message in this case:

  [0.144079] efi: Failed to allocate new EFI memmap

Signed-off-by: Juergen Gross 
Signed-off-by: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20170526113652.21339-2-m...@codeblueprint.co.uk
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/platform/efi/quirks.c |3 +++
 1 file changed, 3 insertions(+)

--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -358,6 +358,9 @@ void __init efi_free_boot_services(void)
free_bootmem_late(start, size);
}
 
+   if (!num_entries)
+   return;
+
new_size = efi.memmap.desc_size * num_entries;
new_phys = efi_memmap_alloc(num_entries);
if (!new_phys) {


--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4.11 049/150] efi/bgrt: Skip efi_bgrt_init() in case of non-EFI boot

[Greg Kroah-Hartman]

On Thu, Jun 15, 2017 at 01:34:38AM +0200, Maniaxx wrote:
> On 12.06.2017 at 17:24 wrote Greg Kroah-Hartman:
> > 4.11-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Dave Young 
> > 
> > commit 7425826f4f7ac60f2538b06a7f0a5d1006405159 upstream.
> > 
> > Sabrina Dubroca reported an early panic:
> > 
> >   BUG: unable to handle kernel paging request at ff240001
> >   IP: efi_bgrt_init+0xdc/0x134
> > 
> >   [...]
> > 
> >   ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
> > 
> > ... which was introduced by:
> > 
> >   7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init code")
> > 
> > The cause is that on this machine the firmware provides the EFI ACPI BGRT
> > table even on legacy non-EFI bootups - which table should be EFI only.
> > 
> > The garbage BGRT data causes the efi_bgrt_init() panic.
> > 
> > Add a check to skip efi_bgrt_init() in case non-EFI bootup to work around
> > this firmware bug.
> > 
> > Tested-by: Sabrina Dubroca 
> > Signed-off-by: Dave Young 
> > Signed-off-by: Ard Biesheuvel 
> > Signed-off-by: Matt Fleming 
> > Cc: Linus Torvalds 
> > Cc: Peter Zijlstra 
> > Cc: Thomas Gleixner 
> > Cc: linux-efi@vger.kernel.org
> > Fixes: 7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init 
> > code")
> > Link: 
> > http://lkml.kernel.org/r/20170526113652.21339-6-m...@codeblueprint.co.uk
> > [ Rewrote the changelog to be more readable. ]
> > Signed-off-by: Ingo Molnar 
> > Signed-off-by: Greg Kroah-Hartman 
> > 
> > ---
> >  arch/x86/platform/efi/efi-bgrt.c |3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > --- a/arch/x86/platform/efi/efi-bgrt.c
> > +++ b/arch/x86/platform/efi/efi-bgrt.c
> > @@ -36,6 +36,9 @@ void __init efi_bgrt_init(struct acpi_ta
> > if (acpi_disabled)
> > return;
> >  
> > +   if (!efi_enabled(EFI_BOOT))
> > +   return;
> > +
> > if (table->length < sizeof(bgrt_tab)) {
> > pr_notice("Ignoring BGRT: invalid length %u (expected %zu)\n",
> >table->length, sizeof(bgrt_tab));
> > 
> > 
> > 
> 
> The patch is ok but it only fixes BIOS systems.
> To fix the regression above (commit 7b0a911478c7) for EFI systems 
> it needs this patch as well:
> commit 792ef14df5c585c19b2831673a077504a09e5203 master
> (efi: Fix boot panic because of invalid BGRT image address)

Thanks for letting me know, now queued up.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4.11 05/13] efi: Fix boot panic because of invalid BGRT image address

[Greg Kroah-Hartman]

4.11-stable review patch.  If anyone has any objections, please let me know.

--

From: Dave Young 

commit 792ef14df5c585c19b2831673a077504a09e5203 upstream.

Maniaxx reported a kernel boot crash in the EFI code, which I emulated
by using same invalid phys addr in code:

  BUG: unable to handle kernel paging request at ff280001
  IP: efi_bgrt_init+0xfb/0x153
  ...
  Call Trace:
   ? bgrt_init+0xbc/0xbc
   acpi_parse_bgrt+0xe/0x12
   acpi_table_parse+0x89/0xb8
   acpi_boot_init+0x445/0x4e2
   ? acpi_parse_x2apic+0x79/0x79
   ? dmi_ignore_irq0_timer_override+0x33/0x33
   setup_arch+0xb63/0xc82
   ? early_idt_handler_array+0x120/0x120
   start_kernel+0xb7/0x443
   ? early_idt_handler_array+0x120/0x120
   x86_64_start_reservations+0x29/0x2b
   x86_64_start_kernel+0x154/0x177
   secondary_startup_64+0x9f/0x9f

There is also a similar bug filed in bugzilla.kernel.org:

  https://bugzilla.kernel.org/show_bug.cgi?id=195633

The crash is caused by this commit:

  7b0a911478c7 efi/x86: Move the EFI BGRT init code to early init code

The root cause is the firmware on those machines provides invalid BGRT
image addresses.

In a kernel before above commit BGRT initializes late and uses ioremap()
to map the image address. Ioremap validates the address, if it is not a
valid physical address ioremap() just fails and returns. However in current
kernel EFI BGRT initializes early and uses early_memremap() which does not
validate the image address, and kernel panic happens.

According to ACPI spec the BGRT image address should fall into
EFI_BOOT_SERVICES_DATA, see the section 5.2.22.4 of below document:

  http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf

Fix this issue by validating the image address in efi_bgrt_init(). If the
image address does not fall into any EFI_BOOT_SERVICES_DATA areas we just
bail out with a warning message.

Reported-by: Maniaxx 
Signed-off-by: Dave Young 
Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init code")
Link: http://lkml.kernel.org/r/20170609084558.26766-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/platform/efi/efi-bgrt.c |   26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

--- a/arch/x86/platform/efi/efi-bgrt.c
+++ b/arch/x86/platform/efi/efi-bgrt.c
@@ -27,6 +27,26 @@ struct bmp_header {
u32 size;
 } __packed;
 
+static bool efi_bgrt_addr_valid(u64 addr)
+{
+   efi_memory_desc_t *md;
+
+   for_each_efi_memory_desc(md) {
+   u64 size;
+   u64 end;
+
+   if (md->type != EFI_BOOT_SERVICES_DATA)
+   continue;
+
+   size = md->num_pages << EFI_PAGE_SHIFT;
+   end = md->phys_addr + size;
+   if (addr >= md->phys_addr && addr < end)
+   return true;
+   }
+
+   return false;
+}
+
 void __init efi_bgrt_init(struct acpi_table_header *table)
 {
void *image;
@@ -36,7 +56,7 @@ void __init efi_bgrt_init(struct acpi_ta
if (acpi_disabled)
return;
 
-   if (!efi_enabled(EFI_BOOT))
+   if (!efi_enabled(EFI_MEMMAP))
return;
 
if (table->length < sizeof(bgrt_tab)) {
@@ -65,6 +85,10 @@ void __init efi_bgrt_init(struct acpi_ta
goto out;
}
 
+   if (!efi_bgrt_addr_valid(bgrt->image_address)) {
+   pr_notice("Ignoring BGRT: invalid image address\n");
+   goto out;
+   }
image = early_memremap(bgrt->image_address, sizeof(bmp_header));
if (!image) {
pr_notice("Ignoring BGRT: failed to map image header memory\n");


--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4.12 27/84] efi: Process the MEMATTR table only if EFI_MEMMAP is enabled

[Greg Kroah-Hartman]

4.12-stable review patch.  If anyone has any objections, please let me know.

--

From: Daniel Kiper 

commit 457ea3f7e97881f937136ce0ba1f29f82b9abdb0 upstream.

Otherwise e.g. Xen dom0 on x86_64 EFI platforms crashes.

In theory we can check EFI_PARAVIRT too, however,
EFI_MEMMAP looks more targeted and covers more cases.

Signed-off-by: Daniel Kiper 
Reviewed-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: andrew.coop...@citrix.com
Cc: boris.ostrov...@oracle.com
Cc: jgr...@suse.com
Cc: linux-efi@vger.kernel.org
Cc: m...@codeblueprint.co.uk
Cc: xen-de...@lists.xenproject.org
Link: 
http://lkml.kernel.org/r/1498128697-12943-2-git-send-email-daniel.ki...@oracle.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/firmware/efi/efi.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -528,7 +528,8 @@ int __init efi_config_parse_tables(void
}
}
 
-   efi_memattr_init();
+   if (efi_enabled(EFI_MEMMAP))
+   efi_memattr_init();
 
/* Parse the EFI Properties table if it exists */
if (efi.properties_table != EFI_INVALID_TABLE_ADDR) {


--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen

[Greg Kroah-Hartman]

4.12-stable review patch.  If anyone has any objections, please let me know.

--

From: Daniel Kiper 

commit 6c64447ec58b0bac612732303f7ab04562124587 upstream.

The current approach, which is the wholesale efi struct initialization from
a 'efi_xen' local template is not robust. Usually if new member is defined
then it is properly initialized in drivers/firmware/efi/efi.c, but not in
arch/x86/xen/efi.c.

The effect is that the Xen initialization clears any fields the generic code
might have set and the Xen code does not know about yet.

I saw this happen a few times, so let's initialize only the EFI struct members
used by Xen and maintain no local duplicate, to avoid such issues in the future.

Signed-off-by: Daniel Kiper 
Reviewed-by: Boris Ostrovsky 
Acked-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: andrew.coop...@citrix.com
Cc: jgr...@suse.com
Cc: linux-efi@vger.kernel.org
Cc: m...@codeblueprint.co.uk
Cc: xen-de...@lists.xenproject.org
Link: 
http://lkml.kernel.org/r/1498128697-12943-3-git-send-email-daniel.ki...@oracle.com
[ Clarified the changelog. ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/xen/efi.c |   45 -
 1 file changed, 12 insertions(+), 33 deletions(-)

--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -54,38 +54,6 @@ static efi_system_table_t efi_systab_xen
.tables = EFI_INVALID_TABLE_ADDR  /* Initialized later. */
 };
 
-static const struct efi efi_xen __initconst = {
-   .systab   = NULL, /* Initialized later. */
-   .runtime_version  = 0,/* Initialized later. */
-   .mps  = EFI_INVALID_TABLE_ADDR,
-   .acpi = EFI_INVALID_TABLE_ADDR,
-   .acpi20   = EFI_INVALID_TABLE_ADDR,
-   .smbios   = EFI_INVALID_TABLE_ADDR,
-   .smbios3  = EFI_INVALID_TABLE_ADDR,
-   .sal_systab   = EFI_INVALID_TABLE_ADDR,
-   .boot_info= EFI_INVALID_TABLE_ADDR,
-   .hcdp = EFI_INVALID_TABLE_ADDR,
-   .uga  = EFI_INVALID_TABLE_ADDR,
-   .uv_systab= EFI_INVALID_TABLE_ADDR,
-   .fw_vendor= EFI_INVALID_TABLE_ADDR,
-   .runtime  = EFI_INVALID_TABLE_ADDR,
-   .config_table = EFI_INVALID_TABLE_ADDR,
-   .get_time = xen_efi_get_time,
-   .set_time = xen_efi_set_time,
-   .get_wakeup_time  = xen_efi_get_wakeup_time,
-   .set_wakeup_time  = xen_efi_set_wakeup_time,
-   .get_variable = xen_efi_get_variable,
-   .get_next_variable= xen_efi_get_next_variable,
-   .set_variable = xen_efi_set_variable,
-   .query_variable_info  = xen_efi_query_variable_info,
-   .update_capsule   = xen_efi_update_capsule,
-   .query_capsule_caps   = xen_efi_query_capsule_caps,
-   .get_next_high_mono_count = xen_efi_get_next_high_mono_count,
-   .reset_system = xen_efi_reset_system,
-   .set_virtual_address_map  = NULL, /* Not used under Xen. */
-   .flags= 0 /* Initialized later. */
-};
-
 static efi_system_table_t __init *xen_efi_probe(void)
 {
struct xen_platform_op op = {
@@ -102,7 +70,18 @@ static efi_system_table_t __init *xen_ef
 
/* Here we know that Xen runs on EFI platform. */
 
-   efi = efi_xen;
+   efi.get_time = xen_efi_get_time;
+   efi.set_time = xen_efi_set_time;
+   efi.get_wakeup_time  = xen_efi_get_wakeup_time;
+   efi.set_wakeup_time  = xen_efi_set_wakeup_time;
+   efi.get_variable = xen_efi_get_variable;
+   efi.get_next_variable= xen_efi_get_next_variable;
+   efi.set_variable = xen_efi_set_variable;
+   efi.query_variable_info  = xen_efi_query_variable_info;
+   efi.update_capsule   = xen_efi_update_capsule;
+   efi.query_capsule_caps   = xen_efi_query_capsule_caps;
+   efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
+   efi.reset_system = xen_efi_reset_system;
 
efi_systab_xen.tables = info->cfg.addr;
efi_systab_xen.nr_tables = info->cfg.nent;


--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4.11 38/88] efi: Process the MEMATTR table only if EFI_MEMMAP is enabled

[Greg Kroah-Hartman]

4.11-stable review patch.  If anyone has any objections, please let me know.

--

From: Daniel Kiper 

commit 457ea3f7e97881f937136ce0ba1f29f82b9abdb0 upstream.

Otherwise e.g. Xen dom0 on x86_64 EFI platforms crashes.

In theory we can check EFI_PARAVIRT too, however,
EFI_MEMMAP looks more targeted and covers more cases.

Signed-off-by: Daniel Kiper 
Reviewed-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: andrew.coop...@citrix.com
Cc: boris.ostrov...@oracle.com
Cc: jgr...@suse.com
Cc: linux-efi@vger.kernel.org
Cc: m...@codeblueprint.co.uk
Cc: xen-de...@lists.xenproject.org
Link: 
http://lkml.kernel.org/r/1498128697-12943-2-git-send-email-daniel.ki...@oracle.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/firmware/efi/efi.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -528,7 +528,8 @@ int __init efi_config_parse_tables(void
}
}
 
-   efi_memattr_init();
+   if (efi_enabled(EFI_MEMMAP))
+   efi_memattr_init();
 
/* Parse the EFI Properties table if it exists */
if (efi.properties_table != EFI_INVALID_TABLE_ADDR) {


--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen

[Greg Kroah-Hartman]

On Wed, Jul 19, 2017 at 12:37:47PM +0200, Daniel Kiper wrote:
> Hey Greg,
> 
> On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > 4.12-stable review patch.  If anyone has any objections, please let me know.
> 
> Why did you skip this patch for 4.11? IMO it should be applied there too.

Are you sure it actually applied?  (hint, it did not...)

If you want it in 4.11, or older kernels, please provide a working
backport.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen

[Greg Kroah-Hartman]

On Wed, Jul 19, 2017 at 01:12:14PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 19, 2017 at 12:37:47PM +0200, Daniel Kiper wrote:
> > Hey Greg,
> > 
> > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > 4.12-stable review patch.  If anyone has any objections, please let me 
> > > know.
> > 
> > Why did you skip this patch for 4.11? IMO it should be applied there too.
> 
> Are you sure it actually applied?  (hint, it did not...)
> 
> If you want it in 4.11, or older kernels, please provide a working
> backport.

And, in the future, if you want it to be applied to older kernels, or be
notified if it can not be, please add a kernel version number in the
stable marking:
Cc: sta...@vger.kernel.org # 4.0+
or use the Fixes: tag:
Fixes: SHASHAHSA ("short description")
which I pick up on and let you know if the patch does not actually apply
back to the kernel that the fixes: tag was in.

hope this helps,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen

[Greg Kroah-Hartman]

On Thu, Jul 20, 2017 at 10:39:10AM +0200, Ingo Molnar wrote:
> 
> * Daniel Kiper  wrote:
> 
> > Hey Greg,
> > 
> > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > 4.12-stable review patch.  If anyone has any objections, please let me 
> > > know.
> > 
> > Why did you skip this patch for 4.11? IMO it should be applied there too.
> 
> The thing is, this patch should probaly not even be in v4.12, as it should 
> only 
> make any difference if there's a separate _bug_ in the kernel.
> 
> This patch makes things more robust going forward, but I question that it 
> needs to 
> be in -stable.

Yeah, good point, I'm going to go drop it entirely from the 4.12-stable
tree as it obviously isn't stable material, sorry for not catching that
before.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/6] staging: unisys: Switch to use new generic UUID API

[Greg Kroah-Hartman]

On Wed, Jul 26, 2017 at 01:01:41PM +0300, Andy Shevchenko wrote:
> On Wed, 2017-07-19 at 21:28 +0300, Andy Shevchenko wrote:
> > There are new types and helpers that are supposed to be used in new
> > code.
> > 
> > As a preparation to get rid of legacy types and API functions do
> > the conversion here.
> > 
> > While here, re-indent couple of lines to increase readability.
> 
> This looks like no user space UUID API is involved, can be routed via
> either tree (uuid or staging).
> 
> Anyone to comment?

Doesn't apply to the staging tree at all :(
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/6] staging: unisys: Switch to use new generic UUID API

[Greg Kroah-Hartman]

On Sun, Jul 30, 2017 at 08:26:48PM +0300, Andy Shevchenko wrote:
> On Sun, Jul 30, 2017 at 6:32 PM, Greg Kroah-Hartman
>  wrote:
> > On Wed, Jul 26, 2017 at 01:01:41PM +0300, Andy Shevchenko wrote:
> >> On Wed, 2017-07-19 at 21:28 +0300, Andy Shevchenko wrote:
> >> > There are new types and helpers that are supposed to be used in new
> >> > code.
> >> >
> >> > As a preparation to get rid of legacy types and API functions do
> >> > the conversion here.
> >> >
> >> > While here, re-indent couple of lines to increase readability.
> >>
> >> This looks like no user space UUID API is involved, can be routed via
> >> either tree (uuid or staging).
> >>
> >> Anyone to comment?
> >
> > Doesn't apply to the staging tree at all :(
> 
> No surprises, it was cooked against uuid tree in the first place.
> If you agree to take it through staging tree I will prepare a rebased version.
> Does it sound good?

You can take it through the uuid tree if it's easier for you, but then
someone will have to deal with the merge issues...

If it's easier, I can take it to prevent the merge problems.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/6] staging: unisys: Switch to use new generic UUID API

[Greg Kroah-Hartman]

On Wed, Aug 30, 2017 at 02:38:45PM +0200, Christoph Hellwig wrote:
> On Mon, Jul 31, 2017 at 08:20:25PM +0300, Andy Shevchenko wrote:
> > Yep! There are so many conflicts that would be better just to push
> > through your tree.
> > 
> > I have just sent a v2 of this patch separately.
> 
> Greg, did you pick that patch up?

Yes, it's already in my tree and in linux-next.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Greg Kroah-Hartman]

On Tue, Nov 14, 2017 at 07:21:38AM -0500, Mimi Zohar wrote:
> On Mon, 2017-11-13 at 14:09 -0800, Linus Torvalds wrote:
> > On Mon, Nov 13, 2017 at 1:44 PM, David Howells  wrote:
> > >
> > > Whilst that may be true, we either have to check signatures on every bit 
> > > of
> > > firmware that the appropriate driver doesn't say is meant to be signed or 
> > > not
> > > bother.
> > 
> > I vote for "not bother".
> > 
> > Seriously, if you have firmware in /lib/firmware, and you don't trust
> > it, what the hell are you doing?
> 
> I might "trust" the files in /lib/firmware, but I also want to make
> sure that they haven't changed.  File signatures provide file
> provenance and integrity guarantees.

Then "verify" them with signatures that you generate yourself.  Like
dm-verify does for the partition that you put the firmware on.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html