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

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 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 

[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, , true, );
 
list_for_each_entry_safe(entry, aux, , 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, , true, );
 
list_for_each_entry_safe(entry, aux, , list) {

[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 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, , true, );
 
list_for_each_entry_safe(entry, aux, , list) {

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

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 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

[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 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

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 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 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 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,
> +  );
> + 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 rc;
> 

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, , );
> + } 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, , 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(, 0, sizeof(efi_guid_t));
> + convert_buffer_to_efi_guid(mdata + namesize, );
> + memcpy(vendor, , sizeof(efi_guid_t));
> + memset(name, 0, namesize + 2);
> +   

[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, _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 *)_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;
 
/*
 * If no EFI parameters were specified on

[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, )) {
+   if (efi_enabled(EFI_BOOT) &&
+   !efi_mem_desc_lookup(efifb_fix.smem_start, )) {
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, )) {
+   if (efi_enabled(EFI_BOOT) &&
+   !efi_mem_desc_lookup(efifb_fix.smem_start, )) {
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.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, )) {
+   if (efi_enabled(EFI_BOOT) &&
+   !efi_mem_desc_lookup(efifb_fix.smem_start, )) {
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.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 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 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 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 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 = >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 = >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.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 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.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 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 = >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 = >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.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.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 

[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 

[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, 

[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 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 

[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 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 

[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 **));
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 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.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.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.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.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 = _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.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,
-  >var.VendorGuid,
-  0, 0, NULL);
+   if (!__efivars)
+   return -EINVAL;
+
+   status = __efivars->ops->set_variable(entry->var.VariableName,
+ >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(struct 

[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,
-  >var.VendorGuid,
-  0, 0, NULL);
+   if (!__efivars)
+   return -EINVAL;
+
+   status = __efivars->ops->set_variable(entry->var.VariableName,
+ >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(struct 

[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,
-  >var.VendorGuid,
-  0, 0, NULL);
+   if (!__efivars)
+   return -EINVAL;
+
+   status = __efivars->ops->set_variable(entry->var.VariableName,
+ >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(struct 

[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,
-  >var.VendorGuid,
-  0, 0, NULL);
+   if (!__efivars)
+   return -EINVAL;
+
+   status = __efivars->ops->set_variable(entry->var.VariableName,
+ >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(struct 

[PATCH 4.19 038/106] efi/libstub: Disable some warnings for x86{,_64}

[Greg Kroah-Hartman]

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

--

[ Upstream commit 3db5e0ba8b8f4aee631d7ee04b7a11c56cfdc213 ]

When building the kernel with Clang, some disabled warnings appear
because this Makefile overrides KBUILD_CFLAGS for x86{,_64}. Add them to
this list so that the build is clean again.

-Wpointer-sign was disabled for the whole kernel before the beginning of Git 
history.

-Waddress-of-packed-member was disabled for the whole kernel and for
the early boot code in these commits:

  bfb38988c51e ("kbuild: clang: Disable 'address-of-packed-member' warning")
  20c6c1890455 ("x86/boot: Disable the address-of-packed-member compiler 
warning").

-Wgnu was disabled for the whole kernel and for the early boot code in
these commits:

  61163efae020 ("kbuild: LLVMLinux: Add Kbuild support for building kernel with 
Clang")
  6c3b56b19730 ("x86/boot: Disable Clang warnings about GNU extensions").

 [ mingo: Made the changelog more readable. ]

Tested-by: Sedat Dilek 
Signed-off-by: Nathan Chancellor 
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Sedat Dilek 
Cc: Andy Lutomirski 
Cc: Arend van Spriel 
Cc: Bhupesh Sharma 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: Eric Snowberg 
Cc: Hans de Goede 
Cc: Joe Perches 
Cc: Jon Hunter 
Cc: Julien Thierry 
Cc: Linus Torvalds 
Cc: Marc Zyngier 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Sai Praneeth Prakhya 
Cc: Thomas Gleixner 
Cc: YiFei Zhu 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20181129171230.18699-8-ard.biesheu...@linaro.org
Link: https://github.com/ClangBuiltLinux/linux/issues/112
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/efi/libstub/Makefile | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/libstub/Makefile 
b/drivers/firmware/efi/libstub/Makefile
index c51627660dbb..d9845099635e 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -9,7 +9,10 @@ cflags-$(CONFIG_X86_32):= -march=i386
 cflags-$(CONFIG_X86_64):= -mcmodel=small
 cflags-$(CONFIG_X86)   += -m$(BITS) -D__KERNEL__ -O2 \
   -fPIC -fno-strict-aliasing -mno-red-zone \
-  -mno-mmx -mno-sse -fshort-wchar
+  -mno-mmx -mno-sse -fshort-wchar \
+  -Wno-pointer-sign \
+  $(call cc-disable-warning, 
address-of-packed-member) \
+  $(call cc-disable-warning, gnu)
 
 # arm64 uses the full KBUILD_CFLAGS so it's necessary to explicitly
 # disable the stackleak plugin
-- 
2.19.1

[PATCH 4.20 050/127] efi/libstub: Disable some warnings for x86{,_64}

[Greg Kroah-Hartman]

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

--

[ Upstream commit 3db5e0ba8b8f4aee631d7ee04b7a11c56cfdc213 ]

When building the kernel with Clang, some disabled warnings appear
because this Makefile overrides KBUILD_CFLAGS for x86{,_64}. Add them to
this list so that the build is clean again.

-Wpointer-sign was disabled for the whole kernel before the beginning of Git 
history.

-Waddress-of-packed-member was disabled for the whole kernel and for
the early boot code in these commits:

  bfb38988c51e ("kbuild: clang: Disable 'address-of-packed-member' warning")
  20c6c1890455 ("x86/boot: Disable the address-of-packed-member compiler 
warning").

-Wgnu was disabled for the whole kernel and for the early boot code in
these commits:

  61163efae020 ("kbuild: LLVMLinux: Add Kbuild support for building kernel with 
Clang")
  6c3b56b19730 ("x86/boot: Disable Clang warnings about GNU extensions").

 [ mingo: Made the changelog more readable. ]

Tested-by: Sedat Dilek 
Signed-off-by: Nathan Chancellor 
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Sedat Dilek 
Cc: Andy Lutomirski 
Cc: Arend van Spriel 
Cc: Bhupesh Sharma 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: Eric Snowberg 
Cc: Hans de Goede 
Cc: Joe Perches 
Cc: Jon Hunter 
Cc: Julien Thierry 
Cc: Linus Torvalds 
Cc: Marc Zyngier 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Sai Praneeth Prakhya 
Cc: Thomas Gleixner 
Cc: YiFei Zhu 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20181129171230.18699-8-ard.biesheu...@linaro.org
Link: https://github.com/ClangBuiltLinux/linux/issues/112
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/efi/libstub/Makefile | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/libstub/Makefile 
b/drivers/firmware/efi/libstub/Makefile
index c51627660dbb..d9845099635e 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -9,7 +9,10 @@ cflags-$(CONFIG_X86_32):= -march=i386
 cflags-$(CONFIG_X86_64):= -mcmodel=small
 cflags-$(CONFIG_X86)   += -m$(BITS) -D__KERNEL__ -O2 \
   -fPIC -fno-strict-aliasing -mno-red-zone \
-  -mno-mmx -mno-sse -fshort-wchar
+  -mno-mmx -mno-sse -fshort-wchar \
+  -Wno-pointer-sign \
+  $(call cc-disable-warning, 
address-of-packed-member) \
+  $(call cc-disable-warning, gnu)
 
 # arm64 uses the full KBUILD_CFLAGS so it's necessary to explicitly
 # disable the stackleak plugin
-- 
2.19.1

[PATCH 3.18 14/31] x86/earlyprintk/efi: Fix infinite loop on some screen widths

[Greg Kroah-Hartman]

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

--

[ Upstream commit 79c2206d369b87b19ac29cb47601059b6bf5c291 ]

An affected screen resolution is 1366 x 768, which width is not
divisible by 8, the default font width. On such screens, when longer
lines are earlyprintk'ed, overflow-to-next-line can never trigger,
due to the left-most x-coordinate of the next character always less
than the screen width. Earlyprintk will infinite loop in trying to
print the rest of the string but unable to, due to the line being
full.

This patch makes the trigger consider the right-most x-coordinate,
instead of left-most, as the value to compare against the screen
width threshold.

Signed-off-by: YiFei Zhu 
Signed-off-by: Ard Biesheuvel 
Cc: Andy Lutomirski 
Cc: Arend van Spriel 
Cc: Bhupesh Sharma 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: Eric Snowberg 
Cc: Hans de Goede 
Cc: Joe Perches 
Cc: Jon Hunter 
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: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20181129171230.18699-12-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 arch/x86/platform/efi/early_printk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/early_printk.c 
b/arch/x86/platform/efi/early_printk.c
index 524142117296..82324fc25d5e 100644
--- a/arch/x86/platform/efi/early_printk.c
+++ b/arch/x86/platform/efi/early_printk.c
@@ -179,7 +179,7 @@ early_efi_write(struct console *con, const char *str, 
unsigned int num)
num--;
}
 
-   if (efi_x >= si->lfb_width) {
+   if (efi_x + font->width > si->lfb_width) {
efi_x = 0;
efi_y += font->height;
}
-- 
2.19.1

[PATCH 4.4 21/40] x86/earlyprintk/efi: Fix infinite loop on some screen widths

[Greg Kroah-Hartman]

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

--

[ Upstream commit 79c2206d369b87b19ac29cb47601059b6bf5c291 ]

An affected screen resolution is 1366 x 768, which width is not
divisible by 8, the default font width. On such screens, when longer
lines are earlyprintk'ed, overflow-to-next-line can never trigger,
due to the left-most x-coordinate of the next character always less
than the screen width. Earlyprintk will infinite loop in trying to
print the rest of the string but unable to, due to the line being
full.

This patch makes the trigger consider the right-most x-coordinate,
instead of left-most, as the value to compare against the screen
width threshold.

Signed-off-by: YiFei Zhu 
Signed-off-by: Ard Biesheuvel 
Cc: Andy Lutomirski 
Cc: Arend van Spriel 
Cc: Bhupesh Sharma 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: Eric Snowberg 
Cc: Hans de Goede 
Cc: Joe Perches 
Cc: Jon Hunter 
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: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20181129171230.18699-12-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 arch/x86/platform/efi/early_printk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/early_printk.c 
b/arch/x86/platform/efi/early_printk.c
index 524142117296..82324fc25d5e 100644
--- a/arch/x86/platform/efi/early_printk.c
+++ b/arch/x86/platform/efi/early_printk.c
@@ -179,7 +179,7 @@ early_efi_write(struct console *con, const char *str, 
unsigned int num)
num--;
}
 
-   if (efi_x >= si->lfb_width) {
+   if (efi_x + font->width > si->lfb_width) {
efi_x = 0;
efi_y += font->height;
}
-- 
2.19.1

[PATCH 4.9 34/61] x86/earlyprintk/efi: Fix infinite loop on some screen widths

[Greg Kroah-Hartman]

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

--

[ Upstream commit 79c2206d369b87b19ac29cb47601059b6bf5c291 ]

An affected screen resolution is 1366 x 768, which width is not
divisible by 8, the default font width. On such screens, when longer
lines are earlyprintk'ed, overflow-to-next-line can never trigger,
due to the left-most x-coordinate of the next character always less
than the screen width. Earlyprintk will infinite loop in trying to
print the rest of the string but unable to, due to the line being
full.

This patch makes the trigger consider the right-most x-coordinate,
instead of left-most, as the value to compare against the screen
width threshold.

Signed-off-by: YiFei Zhu 
Signed-off-by: Ard Biesheuvel 
Cc: Andy Lutomirski 
Cc: Arend van Spriel 
Cc: Bhupesh Sharma 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: Eric Snowberg 
Cc: Hans de Goede 
Cc: Joe Perches 
Cc: Jon Hunter 
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: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20181129171230.18699-12-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 arch/x86/platform/efi/early_printk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/early_printk.c 
b/arch/x86/platform/efi/early_printk.c
index 5fdacb322ceb..c3e6be110b7d 100644
--- a/arch/x86/platform/efi/early_printk.c
+++ b/arch/x86/platform/efi/early_printk.c
@@ -179,7 +179,7 @@ early_efi_write(struct console *con, const char *str, 
unsigned int num)
num--;
}
 
-   if (efi_x >= si->lfb_width) {
+   if (efi_x + font->width > si->lfb_width) {
efi_x = 0;
efi_y += font->height;
}
-- 
2.19.1

[PATCH 4.14 40/72] x86/earlyprintk/efi: Fix infinite loop on some screen widths

[Greg Kroah-Hartman]

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

--

[ Upstream commit 79c2206d369b87b19ac29cb47601059b6bf5c291 ]

An affected screen resolution is 1366 x 768, which width is not
divisible by 8, the default font width. On such screens, when longer
lines are earlyprintk'ed, overflow-to-next-line can never trigger,
due to the left-most x-coordinate of the next character always less
than the screen width. Earlyprintk will infinite loop in trying to
print the rest of the string but unable to, due to the line being
full.

This patch makes the trigger consider the right-most x-coordinate,
instead of left-most, as the value to compare against the screen
width threshold.

Signed-off-by: YiFei Zhu 
Signed-off-by: Ard Biesheuvel 
Cc: Andy Lutomirski 
Cc: Arend van Spriel 
Cc: Bhupesh Sharma 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: Eric Snowberg 
Cc: Hans de Goede 
Cc: Joe Perches 
Cc: Jon Hunter 
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: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20181129171230.18699-12-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 arch/x86/platform/efi/early_printk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/early_printk.c 
b/arch/x86/platform/efi/early_printk.c
index 5fdacb322ceb..c3e6be110b7d 100644
--- a/arch/x86/platform/efi/early_printk.c
+++ b/arch/x86/platform/efi/early_printk.c
@@ -179,7 +179,7 @@ early_efi_write(struct console *con, const char *str, 
unsigned int num)
num--;
}
 
-   if (efi_x >= si->lfb_width) {
+   if (efi_x + font->width > si->lfb_width) {
efi_x = 0;
efi_y += font->height;
}
-- 
2.19.1

[PATCH 4.19 13/67] x86/earlyprintk/efi: Fix infinite loop on some screen widths

[Greg Kroah-Hartman]

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

--

[ Upstream commit 79c2206d369b87b19ac29cb47601059b6bf5c291 ]

An affected screen resolution is 1366 x 768, which width is not
divisible by 8, the default font width. On such screens, when longer
lines are earlyprintk'ed, overflow-to-next-line can never trigger,
due to the left-most x-coordinate of the next character always less
than the screen width. Earlyprintk will infinite loop in trying to
print the rest of the string but unable to, due to the line being
full.

This patch makes the trigger consider the right-most x-coordinate,
instead of left-most, as the value to compare against the screen
width threshold.

Signed-off-by: YiFei Zhu 
Signed-off-by: Ard Biesheuvel 
Cc: Andy Lutomirski 
Cc: Arend van Spriel 
Cc: Bhupesh Sharma 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: Eric Snowberg 
Cc: Hans de Goede 
Cc: Joe Perches 
Cc: Jon Hunter 
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: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20181129171230.18699-12-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 arch/x86/platform/efi/early_printk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/early_printk.c 
b/arch/x86/platform/efi/early_printk.c
index 5fdacb322ceb..c3e6be110b7d 100644
--- a/arch/x86/platform/efi/early_printk.c
+++ b/arch/x86/platform/efi/early_printk.c
@@ -179,7 +179,7 @@ early_efi_write(struct console *con, const char *str, 
unsigned int num)
num--;
}
 
-   if (efi_x >= si->lfb_width) {
+   if (efi_x + font->width > si->lfb_width) {
efi_x = 0;
efi_y += font->height;
}
-- 
2.19.1

[PATCH 4.19 104/118] x86/efi: Allocate e820 buffer before calling efi_exit_boot_service

[Greg Kroah-Hartman]

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

--

From: Eric Snowberg 

commit b84a64fad40637b1c9fa4f4dbf847a23e29e672b upstream.

The following commit:

  d64934019f6c ("x86/efi: Use efi_exit_boot_services()")

introduced a regression on systems with large memory maps causing them
to hang on boot. The first "goto get_map" that was removed from
exit_boot() ensured there was enough room for the memory map when
efi_call_early(exit_boot_services) was called. This happens when
(nr_desc > ARRAY_SIZE(params->e820_table).

Chain of events:

  exit_boot()
efi_exit_boot_services()
  efi_get_memory_map  <- at this point the mm can't grow 
over 8 desc
  priv_func()
exit_boot_func()
  allocate_e820ext()  <- new mm grows over 8 desc from e820 
alloc
  efi_call_early(exit_boot_services)  <- mm key doesn't match so retry
  efi_call_early(get_memory_map)  <- not enough room for new mm
  system hangs

This patch allocates the e820 buffer before calling efi_exit_boot_services()
and fixes the regression.

 [ mingo: minor cleanliness edits. ]

Signed-off-by: Eric Snowberg 
Signed-off-by: Ard Biesheuvel 
Cc: 
Cc: Andy Lutomirski 
Cc: Arend van Spriel 
Cc: Bhupesh Sharma 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: Hans de Goede 
Cc: Joe Perches 
Cc: Jon Hunter 
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-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/boot/compressed/eboot.c |   65 ---
 1 file changed, 41 insertions(+), 24 deletions(-)

--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -1,3 +1,4 @@
+
 /* ---
  *
  *   Copyright 2011 Intel Corporation; author Matt Fleming
@@ -634,37 +635,54 @@ static efi_status_t alloc_e820ext(u32 nr
return status;
 }
 
+static efi_status_t allocate_e820(struct boot_params *params,
+ struct setup_data **e820ext,
+ u32 *e820ext_size)
+{
+   unsigned long map_size, desc_size, buff_size;
+   struct efi_boot_memmap boot_map;
+   efi_memory_desc_t *map;
+   efi_status_t status;
+   __u32 nr_desc;
+
+   boot_map.map= 
+   boot_map.map_size   = _size;
+   boot_map.desc_size  = _size;
+   boot_map.desc_ver   = NULL;
+   boot_map.key_ptr= NULL;
+   boot_map.buff_size  = _size;
+
+   status = efi_get_memory_map(sys_table, _map);
+   if (status != EFI_SUCCESS)
+   return status;
+
+   nr_desc = buff_size / desc_size;
+
+   if (nr_desc > ARRAY_SIZE(params->e820_table)) {
+   u32 nr_e820ext = nr_desc - ARRAY_SIZE(params->e820_table);
+
+   status = alloc_e820ext(nr_e820ext, e820ext, e820ext_size);
+   if (status != EFI_SUCCESS)
+   return status;
+   }
+
+   return EFI_SUCCESS;
+}
+
 struct exit_boot_struct {
struct boot_params  *boot_params;
struct efi_info *efi;
-   struct setup_data   *e820ext;
-   __u32   e820ext_size;
 };
 
 static efi_status_t exit_boot_func(efi_system_table_t *sys_table_arg,
   struct efi_boot_memmap *map,
   void *priv)
 {
-   static bool first = true;
const char *signature;
__u32 nr_desc;
efi_status_t status;
struct exit_boot_struct *p = priv;
 
-   if (first) {
-   nr_desc = *map->buff_size / *map->desc_size;
-   if (nr_desc > ARRAY_SIZE(p->boot_params->e820_table)) {
-   u32 nr_e820ext = nr_desc -
-   ARRAY_SIZE(p->boot_params->e820_table);
-
-   status = alloc_e820ext(nr_e820ext, >e820ext,
-  >e820ext_size);
-   if (status != EFI_SUCCESS)
-   return status;
-   }
-   first = false;
-   }
-
signature = efi_is_64bit() ? EFI64_LOADER_SIGNATURE
   : EFI32_LOADER_SIGNATURE;
memcpy(>efi->efi_loader_signature, signature, sizeof(__u32));
@@ -687,8 +705,8 @@ static efi_status_t exit_boot(struct boo
 {
unsigned long map_sz, key, desc_size, buff_size;
efi_memory_desc_t *mem_map;
-   struct setup_data *e820ext;
-   __u32 e820ext_size;
+   struct setup_data *e820ext = NULL;
+  

[PATCH 4.9 49/50] efi/libstub: Make file I/O chunking x86-specific

[Greg Kroah-Hartman]

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

--

From: Ard Biesheuvel 

(commit b3879a4d3a31ef14265a52e8d941cf4b0f6627ae upstream)

The ARM decompressor is finicky when it comes to uninitialized variables
with local linkage, the reason being that it may relocate .text and .bss
independently when executing from ROM. This is only possible if all
references into .bss from .text are absolute, and this happens to be the
case for references emitted under -fpic to symbols with external linkage,
and so all .bss references must involve symbols with external linkage.

When building the ARM stub using clang, the initialized local variable
__chunk_size is optimized into a zero-initialized flag that indicates
whether chunking is in effect or not. This flag is therefore emitted into
.bss, which triggers the ARM decompressor's diagnostics, resulting in a
failed build.

Under UEFI, we never execute the decompressor from ROM, so the diagnostic
makes little sense here. But we can easily work around the issue by making
__chunk_size global instead.

However, given that the file I/O chunking that is controlled by the
__chunk_size variable is intended to work around known bugs on various
x86 implementations of UEFI, we can simply make the chunking an x86
specific feature. This is an improvement by itself, and also removes the
need to parse the efi= options in the stub entirely.

Tested-by: Arnd Bergmann 
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Matt Fleming 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1486380166-31868-8-git-send-email-ard.biesheu...@linaro.org
[ Small readability edits. ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/firmware/efi/libstub/efi-stub-helper.c |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -356,6 +356,14 @@ efi_status_t efi_parse_options(char *cmd
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;
+
+   /*
 * If no EFI parameters were specified on the cmdline we've got
 * nothing to do.
 */
@@ -528,7 +536,8 @@ efi_status_t handle_cmdline_files(efi_sy
size = files[j].size;
while (size) {
unsigned long chunksize;
-   if (size > __chunk_size)
+
+   if (IS_ENABLED(CONFIG_X86) && size > 
__chunk_size)
chunksize = __chunk_size;
else
chunksize = size;

Re: [PATCH 4.9 39/92] efi/arm: Revert deferred unmap of early memmap mapping

[Greg Kroah-Hartman]

On Thu, Nov 29, 2018 at 03:28:44PM +0100, Ard Biesheuvel wrote:
> On Thu, 29 Nov 2018 at 15:21, Greg Kroah-Hartman
>  wrote:
> >
> > 4.9-stable review patch.  If anyone has any objections, please let me know.
> >
> > --
> >
> > [ Upstream commit 33412b8673135b18ea42beb7f5117ed0091798b6 ]
> >
> > Commit:
> >
> >   3ea86495aef2 ("efi/arm: preserve early mapping of UEFI memory map longer 
> > for BGRT")
> >
> > deferred the unmap of the early mapping of the UEFI memory map to
> > accommodate the ACPI BGRT code, which looks up the memory type that
> > backs the BGRT table to validate it against the requirements of the UEFI 
> > spec.
> >
> > Unfortunately, this causes problems on ARM, which does not permit
> > early mappings to persist after paging_init() is called, resulting
> > in a WARN() splat. Since we don't support the BGRT table on ARM anway,
> > let's revert ARM to the old behaviour, which is to take down the
> > early mapping at the end of efi_init().
> >
> > Signed-off-by: Ard Biesheuvel 
> > Cc: Linus Torvalds 
> > Cc: Peter Zijlstra 
> > Cc: Thomas Gleixner 
> > Cc: linux-efi@vger.kernel.org
> > Fixes: 3ea86495aef2 ("efi/arm: preserve early mapping of UEFI memory ...")
> 
> This commit is only in v4.19 as far as I know. Does it even apply?

This commit is in the following releases:
4.9.129 4.14.72 4.18.10 4.19

so it should apply :)

thanks,

greg k-h

[PATCH 4.9 39/92] efi/arm: Revert deferred unmap of early memmap mapping

[Greg Kroah-Hartman]

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

--

[ Upstream commit 33412b8673135b18ea42beb7f5117ed0091798b6 ]

Commit:

  3ea86495aef2 ("efi/arm: preserve early mapping of UEFI memory map longer for 
BGRT")

deferred the unmap of the early mapping of the UEFI memory map to
accommodate the ACPI BGRT code, which looks up the memory type that
backs the BGRT table to validate it against the requirements of the UEFI spec.

Unfortunately, this causes problems on ARM, which does not permit
early mappings to persist after paging_init() is called, resulting
in a WARN() splat. Since we don't support the BGRT table on ARM anway,
let's revert ARM to the old behaviour, which is to take down the
early mapping at the end of efi_init().

Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 3ea86495aef2 ("efi/arm: preserve early mapping of UEFI memory ...")
Link: http://lkml.kernel.org/r/20181114175544.12860-3-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/efi/arm-init.c| 4 
 drivers/firmware/efi/arm-runtime.c | 2 +-
 drivers/firmware/efi/memmap.c  | 3 +++
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 1d1c9693ebfb..8ee91777abce 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -256,6 +256,10 @@ void __init efi_init(void)
(params.mmap & ~PAGE_MASK)));
 
init_screen_info();
+
+   /* ARM does not permit early mappings to persist across paging_init() */
+   if (IS_ENABLED(CONFIG_ARM))
+   efi_memmap_unmap();
 }
 
 static int __init register_gop_device(void)
diff --git a/drivers/firmware/efi/arm-runtime.c 
b/drivers/firmware/efi/arm-runtime.c
index 4d788e0debfe..069c5a4479e6 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -118,7 +118,7 @@ static int __init arm_enable_runtime_services(void)
 {
u64 mapsize;
 
-   if (!efi_enabled(EFI_BOOT) || !efi_enabled(EFI_MEMMAP)) {
+   if (!efi_enabled(EFI_BOOT)) {
pr_info("EFI services will not be available.\n");
return 0;
}
diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
index 78686443cb37..3fd2b450c649 100644
--- a/drivers/firmware/efi/memmap.c
+++ b/drivers/firmware/efi/memmap.c
@@ -117,6 +117,9 @@ int __init efi_memmap_init_early(struct efi_memory_map_data 
*data)
 
 void __init efi_memmap_unmap(void)
 {
+   if (!efi_enabled(EFI_MEMMAP))
+   return;
+
if (!efi.memmap.late) {
unsigned long size;
 
-- 
2.17.1

[PATCH 4.14 061/100] efi/arm: Revert deferred unmap of early memmap mapping

[Greg Kroah-Hartman]

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

--

[ Upstream commit 33412b8673135b18ea42beb7f5117ed0091798b6 ]

Commit:

  3ea86495aef2 ("efi/arm: preserve early mapping of UEFI memory map longer for 
BGRT")

deferred the unmap of the early mapping of the UEFI memory map to
accommodate the ACPI BGRT code, which looks up the memory type that
backs the BGRT table to validate it against the requirements of the UEFI spec.

Unfortunately, this causes problems on ARM, which does not permit
early mappings to persist after paging_init() is called, resulting
in a WARN() splat. Since we don't support the BGRT table on ARM anway,
let's revert ARM to the old behaviour, which is to take down the
early mapping at the end of efi_init().

Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 3ea86495aef2 ("efi/arm: preserve early mapping of UEFI memory ...")
Link: http://lkml.kernel.org/r/20181114175544.12860-3-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/efi/arm-init.c| 4 
 drivers/firmware/efi/arm-runtime.c | 2 +-
 drivers/firmware/efi/memmap.c  | 3 +++
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index a7c522eac640..312f9f32e168 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -265,6 +265,10 @@ void __init efi_init(void)
(params.mmap & ~PAGE_MASK)));
 
init_screen_info();
+
+   /* ARM does not permit early mappings to persist across paging_init() */
+   if (IS_ENABLED(CONFIG_ARM))
+   efi_memmap_unmap();
 }
 
 static int __init register_gop_device(void)
diff --git a/drivers/firmware/efi/arm-runtime.c 
b/drivers/firmware/efi/arm-runtime.c
index 8995a48bd067..ad1530aff633 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -122,7 +122,7 @@ static int __init arm_enable_runtime_services(void)
 {
u64 mapsize;
 
-   if (!efi_enabled(EFI_BOOT) || !efi_enabled(EFI_MEMMAP)) {
+   if (!efi_enabled(EFI_BOOT)) {
pr_info("EFI services will not be available.\n");
return 0;
}
diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
index 5fc70520e04c..1907db2b38d8 100644
--- a/drivers/firmware/efi/memmap.c
+++ b/drivers/firmware/efi/memmap.c
@@ -118,6 +118,9 @@ int __init efi_memmap_init_early(struct efi_memory_map_data 
*data)
 
 void __init efi_memmap_unmap(void)
 {
+   if (!efi_enabled(EFI_MEMMAP))
+   return;
+
if (!efi.memmap.late) {
unsigned long size;
 
-- 
2.17.1

[PATCH 4.19 094/110] efi/arm: Revert deferred unmap of early memmap mapping

[Greg Kroah-Hartman]

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

--

[ Upstream commit 33412b8673135b18ea42beb7f5117ed0091798b6 ]

Commit:

  3ea86495aef2 ("efi/arm: preserve early mapping of UEFI memory map longer for 
BGRT")

deferred the unmap of the early mapping of the UEFI memory map to
accommodate the ACPI BGRT code, which looks up the memory type that
backs the BGRT table to validate it against the requirements of the UEFI spec.

Unfortunately, this causes problems on ARM, which does not permit
early mappings to persist after paging_init() is called, resulting
in a WARN() splat. Since we don't support the BGRT table on ARM anway,
let's revert ARM to the old behaviour, which is to take down the
early mapping at the end of efi_init().

Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 3ea86495aef2 ("efi/arm: preserve early mapping of UEFI memory ...")
Link: http://lkml.kernel.org/r/20181114175544.12860-3-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/efi/arm-init.c| 4 
 drivers/firmware/efi/arm-runtime.c | 2 +-
 drivers/firmware/efi/memmap.c  | 3 +++
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 388a929baf95..1a6a77df8a5e 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -265,6 +265,10 @@ void __init efi_init(void)
(params.mmap & ~PAGE_MASK)));
 
init_screen_info();
+
+   /* ARM does not permit early mappings to persist across paging_init() */
+   if (IS_ENABLED(CONFIG_ARM))
+   efi_memmap_unmap();
 }
 
 static int __init register_gop_device(void)
diff --git a/drivers/firmware/efi/arm-runtime.c 
b/drivers/firmware/efi/arm-runtime.c
index 922cfb813109..a00934d263c5 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -110,7 +110,7 @@ static int __init arm_enable_runtime_services(void)
 {
u64 mapsize;
 
-   if (!efi_enabled(EFI_BOOT) || !efi_enabled(EFI_MEMMAP)) {
+   if (!efi_enabled(EFI_BOOT)) {
pr_info("EFI services will not be available.\n");
return 0;
}
diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
index 5fc70520e04c..1907db2b38d8 100644
--- a/drivers/firmware/efi/memmap.c
+++ b/drivers/firmware/efi/memmap.c
@@ -118,6 +118,9 @@ int __init efi_memmap_init_early(struct efi_memory_map_data 
*data)
 
 void __init efi_memmap_unmap(void)
 {
+   if (!efi_enabled(EFI_MEMMAP))
+   return;
+
if (!efi.memmap.late) {
unsigned long size;
 
-- 
2.17.1

[PATCH 4.4 19/70] efi/libstub/arm64: Set -fpie when building the EFI stub

[Greg Kroah-Hartman]

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

--

From: Ard Biesheuvel 

commit 91ee5b21ee026c49e4e7483de69b55b8b47042be upstream.

Clang may emit absolute symbol references when building in non-PIC mode,
even when using the default 'small' code model, which is already mostly
position independent to begin with, due to its use of adrp/add pairs
that have a relative range of +/- 4 GB. The remedy is to pass the -fpie
flag, which can be done safely now that the code has been updated to avoid
GOT indirections (which may be emitted due to the compiler assuming that
the PIC/PIE code may end up in a shared library that is subject to ELF
symbol preemption)

Passing -fpie when building code that needs to execute at an a priori
unknown offset is arguably an improvement in any case, and given that
the recent visibility changes allow the PIC build to pass with GCC as
well, let's add -fpie for all arm64 builds rather than only for Clang.

Tested-by: Matthias Kaehlcke 
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/20170818194947.19347-5-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/firmware/efi/libstub/Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -10,7 +10,7 @@ cflags-$(CONFIG_X86)  += -m$(BITS) -D__K
   -fPIC -fno-strict-aliasing -mno-red-zone \
   -mno-mmx -mno-sse -DDISABLE_BRANCH_PROFILING
 
-cflags-$(CONFIG_ARM64) := $(subst -pg,,$(KBUILD_CFLAGS))
+cflags-$(CONFIG_ARM64) := $(subst -pg,,$(KBUILD_CFLAGS)) -fpie
 cflags-$(CONFIG_ARM)   := $(subst -pg,,$(KBUILD_CFLAGS)) \
   -fno-builtin -fpic -mno-single-pic-base
 

[PATCH 4.4 18/70] efi/libstub/arm64: Force hidden visibility for section markers

[Greg Kroah-Hartman]

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

--

From: Ard Biesheuvel 

commit 0426a4e68f18d75515414361de9e3e1445d2644e upstream.

To prevent the compiler from emitting absolute references to the section
markers when running in PIC mode, override the visibility to 'hidden' for
all contents of asm/sections.h

Tested-by: Matthias Kaehlcke 
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/20170818194947.19347-4-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
[nc: Fix conflict due to lack of commit 42b55734030c1 in linux-4.4.y]
Signed-off-by: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/firmware/efi/libstub/arm64-stub.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@ -9,9 +9,17 @@
  * published by the Free Software Foundation.
  *
  */
+
+/*
+ * To prevent the compiler from emitting GOT-indirected (and thus absolute)
+ * references to the section markers, override their visibility as 'hidden'
+ */
+#pragma GCC visibility push(hidden)
+#include 
+#pragma GCC visibility pop
+
 #include 
 #include 
-#include 
 
 efi_status_t __init handle_kernel_image(efi_system_table_t *sys_table_arg,
unsigned long *image_addr,

[PATCH 4.9 29/59] efi/libstub/arm64: Force hidden visibility for section markers

[Greg Kroah-Hartman]

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

--

From: Ard Biesheuvel 

commit 0426a4e68f18d75515414361de9e3e1445d2644e upstream.

To prevent the compiler from emitting absolute references to the section
markers when running in PIC mode, override the visibility to 'hidden' for
all contents of asm/sections.h

Tested-by: Matthias Kaehlcke 
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/20170818194947.19347-4-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/firmware/efi/libstub/arm64-stub.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@ -9,9 +9,17 @@
  * published by the Free Software Foundation.
  *
  */
+
+/*
+ * To prevent the compiler from emitting GOT-indirected (and thus absolute)
+ * references to the section markers, override their visibility as 'hidden'
+ */
+#pragma GCC visibility push(hidden)
+#include 
+#pragma GCC visibility pop
+
 #include 
 #include 
-#include 
 #include 
 
 #include "efistub.h"

[PATCH 4.9 28/59] efi/libstub/arm64: Use hidden attribute for struct screen_info reference

[Greg Kroah-Hartman]

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

--

From: Ard Biesheuvel 

commit 760b61d76da6d6a99eb245ab61abf71ca5415cea upstream.

To prevent the compiler from emitting absolute references to screen_info
when building position independent code, redeclare the symbol with hidden
visibility.

Tested-by: Matthias Kaehlcke 
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/20170818194947.19347-3-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/arm64/include/asm/efi.h |3 +++
 1 file changed, 3 insertions(+)

--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -54,6 +54,9 @@ int efi_set_mapping_permissions(struct m
 #define alloc_screen_info(x...)_info
 #define free_screen_info(x...)
 
+/* redeclare as 'hidden' so the compiler will generate relative references */
+extern struct screen_info screen_info 
__attribute__((__visibility__("hidden")));
+
 static inline void efifb_setup_from_dmi(struct screen_info *si, const char 
*opt)
 {
 }

[PATCH 4.9 31/59] efi/libstub/arm64: Set -fpie when building the EFI stub

[Greg Kroah-Hartman]

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

--

From: Ard Biesheuvel 

commit 91ee5b21ee026c49e4e7483de69b55b8b47042be upstream.

Clang may emit absolute symbol references when building in non-PIC mode,
even when using the default 'small' code model, which is already mostly
position independent to begin with, due to its use of adrp/add pairs
that have a relative range of +/- 4 GB. The remedy is to pass the -fpie
flag, which can be done safely now that the code has been updated to avoid
GOT indirections (which may be emitted due to the compiler assuming that
the PIC/PIE code may end up in a shared library that is subject to ELF
symbol preemption)

Passing -fpie when building code that needs to execute at an a priori
unknown offset is arguably an improvement in any case, and given that
the recent visibility changes allow the PIC build to pass with GCC as
well, let's add -fpie for all arm64 builds rather than only for Clang.

Tested-by: Matthias Kaehlcke 
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/20170818194947.19347-5-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/firmware/efi/libstub/Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -10,7 +10,7 @@ cflags-$(CONFIG_X86)  += -m$(BITS) -D__K
   -fPIC -fno-strict-aliasing -mno-red-zone \
   -mno-mmx -mno-sse
 
-cflags-$(CONFIG_ARM64) := $(subst -pg,,$(KBUILD_CFLAGS))
+cflags-$(CONFIG_ARM64) := $(subst -pg,,$(KBUILD_CFLAGS)) -fpie
 cflags-$(CONFIG_ARM)   := $(subst -pg,,$(KBUILD_CFLAGS)) \
   -fno-builtin -fpic -mno-single-pic-base
 

[PATCH 4.9 30/59] efi/libstub: Preserve .debug sections after absolute relocation check

[Greg Kroah-Hartman]

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

--

From: Ard Biesheuvel 

commit 696204faa6e8a318320ebb49d9fa69bc8275644d upstream.

The build commands for the ARM and arm64 EFI stubs strip the .debug
sections and other sections that may legally contain absolute relocations,
in order to inspect the remaining sections for the presence of such
relocations.

This leaves us without debugging symbols in the stub for no good reason,
considering that these sections are omitted from the kernel binary anyway,
and that these relocations are thus only consumed by users of the ELF
binary, such as debuggers.

So move to 'strip' for performing the relocation check, and if it succeeds,
invoke objcopy as before, but leaving the .debug sections in place. Note
that these sections may refer to ksymtab/kcrctab contents, so leave those
in place as well.

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/1485868902-20401-11-git-send-email-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/firmware/efi/libstub/Makefile |   24 
 1 file changed, 16 insertions(+), 8 deletions(-)

--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -11,7 +11,7 @@ cflags-$(CONFIG_X86)  += -m$(BITS) -D__K
   -mno-mmx -mno-sse
 
 cflags-$(CONFIG_ARM64) := $(subst -pg,,$(KBUILD_CFLAGS))
-cflags-$(CONFIG_ARM)   := $(subst -pg,,$(KBUILD_CFLAGS)) -g0 \
+cflags-$(CONFIG_ARM)   := $(subst -pg,,$(KBUILD_CFLAGS)) \
   -fno-builtin -fpic -mno-single-pic-base
 
 cflags-$(CONFIG_EFI_ARMSTUB)   += -I$(srctree)/scripts/dtc/libfdt
@@ -60,7 +60,7 @@ CFLAGS_arm64-stub.o   := -DTEXT_OFFSET=$
 extra-$(CONFIG_EFI_ARMSTUB):= $(lib-y)
 lib-$(CONFIG_EFI_ARMSTUB)  := $(patsubst %.o,%.stub.o,$(lib-y))
 
-STUBCOPY_FLAGS-y   := -R .debug* -R *ksymtab* -R *kcrctab*
+STUBCOPY_RM-y  := -R *ksymtab* -R *kcrctab*
 STUBCOPY_FLAGS-$(CONFIG_ARM64) += --prefix-alloc-sections=.init \
   --prefix-symbols=__efistub_
 STUBCOPY_RELOC-$(CONFIG_ARM64) := R_AARCH64_ABS
@@ -68,17 +68,25 @@ STUBCOPY_RELOC-$(CONFIG_ARM64)  := R_AARC
 $(obj)/%.stub.o: $(obj)/%.o FORCE
$(call if_changed,stubcopy)
 
+#
+# Strip debug sections and some other sections that may legally contain
+# absolute relocations, so that we can inspect the remaining sections for
+# such relocations. If none are found, regenerate the output object, but
+# this time, use objcopy and leave all sections in place.
+#
 quiet_cmd_stubcopy = STUBCPY $@
-  cmd_stubcopy = if $(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@; then \
-$(OBJDUMP) -r $@ | grep $(STUBCOPY_RELOC-y)\
-&& (echo >&2 "$@: absolute symbol references not allowed 
in the EFI stub"; \
-rm -f $@; /bin/false); else /bin/false; fi
+  cmd_stubcopy = if $(STRIP) --strip-debug $(STUBCOPY_RM-y) -o $@ $<; \
+then if $(OBJDUMP) -r $@ | grep $(STUBCOPY_RELOC-y); \
+then (echo >&2 "$@: absolute symbol references not allowed 
in the EFI stub"; \
+  rm -f $@; /bin/false); \
+else $(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@; fi\
+else /bin/false; fi
 
 #
 # ARM discards the .data section because it disallows r/w data in the
 # decompressor. So move our .data to .data.efistub, which is preserved
 # explicitly by the decompressor linker script.
 #
-STUBCOPY_FLAGS-$(CONFIG_ARM)   += --rename-section .data=.data.efistub \
-  -R ___ksymtab+sort -R ___kcrctab+sort
+STUBCOPY_FLAGS-$(CONFIG_ARM)   += --rename-section .data=.data.efistub
+STUBCOPY_RM-$(CONFIG_ARM)  += -R ___ksymtab+sort -R ___kcrctab+sort
 STUBCOPY_RELOC-$(CONFIG_ARM)   := R_ARM_ABS

[PATCH 4.19 170/205] efi/arm/libstub: Pack FDT after populating it

[Greg Kroah-Hartman]

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

--

From: Ard Biesheuvel 

commit 72a58a63a164b4e9d2d914e65caeb551846883f1 upstream.

Commit:

  24d7c494ce46 ("efi/arm-stub: Round up FDT allocation to mapping size")

increased the allocation size for the FDT image created by the stub to a
fixed value of 2 MB, to simplify the former code that made several
attempts with increasing values for the size. This is reasonable
given that the allocation is of type EFI_LOADER_DATA, which is released
to the kernel unless it is explicitly memblock_reserve()d by the early
boot code.

However, this allocation size leaked into the 'size' field of the FDT
header metadata, and so the entire allocation remains occupied by the
device tree binary, even if most of it is not used to store device tree
information.

So call fdt_pack() to shrink the FDT data structure to its minimum size
after populating all the fields, so that the remaining memory is no
longer wasted.

Signed-off-by: Ard Biesheuvel 
Cc:  # v4.12+
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 24d7c494ce46 ("efi/arm-stub: Round up FDT allocation to mapping size")
Link: http://lkml.kernel.org/r/20181114175544.12860-4-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

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

--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -158,6 +158,10 @@ static efi_status_t update_fdt(efi_syste
return efi_status;
}
}
+
+   /* shrink the FDT back to its minimum size */
+   fdt_pack(fdt);
+
return EFI_SUCCESS;
 
 fdt_set_fail:

[PATCH 4.18 143/171] efi/arm/libstub: Pack FDT after populating it

[Greg Kroah-Hartman]

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

--

From: Ard Biesheuvel 

commit 72a58a63a164b4e9d2d914e65caeb551846883f1 upstream.

Commit:

  24d7c494ce46 ("efi/arm-stub: Round up FDT allocation to mapping size")

increased the allocation size for the FDT image created by the stub to a
fixed value of 2 MB, to simplify the former code that made several
attempts with increasing values for the size. This is reasonable
given that the allocation is of type EFI_LOADER_DATA, which is released
to the kernel unless it is explicitly memblock_reserve()d by the early
boot code.

However, this allocation size leaked into the 'size' field of the FDT
header metadata, and so the entire allocation remains occupied by the
device tree binary, even if most of it is not used to store device tree
information.

So call fdt_pack() to shrink the FDT data structure to its minimum size
after populating all the fields, so that the remaining memory is no
longer wasted.

Signed-off-by: Ard Biesheuvel 
Cc:  # v4.12+
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 24d7c494ce46 ("efi/arm-stub: Round up FDT allocation to mapping size")
Link: http://lkml.kernel.org/r/20181114175544.12860-4-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

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

--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -158,6 +158,10 @@ static efi_status_t update_fdt(efi_syste
return efi_status;
}
}
+
+   /* shrink the FDT back to its minimum size */
+   fdt_pack(fdt);
+
return EFI_SUCCESS;
 
 fdt_set_fail:

[PATCH 4.14 106/124] efi/arm/libstub: Pack FDT after populating it

[Greg Kroah-Hartman]

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

--

From: Ard Biesheuvel 

commit 72a58a63a164b4e9d2d914e65caeb551846883f1 upstream.

Commit:

  24d7c494ce46 ("efi/arm-stub: Round up FDT allocation to mapping size")

increased the allocation size for the FDT image created by the stub to a
fixed value of 2 MB, to simplify the former code that made several
attempts with increasing values for the size. This is reasonable
given that the allocation is of type EFI_LOADER_DATA, which is released
to the kernel unless it is explicitly memblock_reserve()d by the early
boot code.

However, this allocation size leaked into the 'size' field of the FDT
header metadata, and so the entire allocation remains occupied by the
device tree binary, even if most of it is not used to store device tree
information.

So call fdt_pack() to shrink the FDT data structure to its minimum size
after populating all the fields, so that the remaining memory is no
longer wasted.

Signed-off-by: Ard Biesheuvel 
Cc:  # v4.12+
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 24d7c494ce46 ("efi/arm-stub: Round up FDT allocation to mapping size")
Link: http://lkml.kernel.org/r/20181114175544.12860-4-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

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

--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -158,6 +158,10 @@ static efi_status_t update_fdt(efi_syste
return efi_status;
}
}
+
+   /* shrink the FDT back to its minimum size */
+   fdt_pack(fdt);
+
return EFI_SUCCESS;
 
 fdt_set_fail:

[PATCH 4.9 079/111] efi/esrt: Only call efi_mem_reserve() for boot services memory

[Greg Kroah-Hartman]

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

--

From: Ard Biesheuvel 

[ Upstream commit 61f0d55569463a1af897117ff47d202b0ccb2e24 ]

The following commit:

  7e1550b8f208 ("efi: Drop type and attribute checks in efi_mem_desc_lookup()")

refactored the implementation of efi_mem_desc_lookup() so that the type
check is moved to the callers, one of which is the x86 version of
efi_arch_mem_reserve(), where we added a modified check that only takes
EFI_BOOT_SERVICES_DATA regions into account.

This is reasonable, since it is the only memory type that requires this,
but doing so uncovered some unexpected behavior in the ESRT code, which
permits the ESRT table to reside in other types of memory than what the
UEFI spec mandates (i.e., EFI_BOOT_SERVICES_DATA), and unconditionally
calls efi_mem_reserve() on the region in question. This may result in
errors such as

  esrt: Reserving ESRT space from 0x9c810318 to 0x9c810350.
  efi: Failed to lookup EFI memory descriptor for 0x9c810318

when the ESRT table is not in EFI_BOOT_SERVICES_DATA memory, but we try
to reserve it nonetheless.

So make the call to efi_mem_reserve() conditional on the memory type.

Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/firmware/efi/esrt.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/firmware/efi/esrt.c
+++ b/drivers/firmware/efi/esrt.c
@@ -333,7 +333,8 @@ void __init efi_esrt_init(void)
 
end = esrt_data + size;
pr_info("Reserving ESRT space from %pa to %pa.\n", _data, );
-   efi_mem_reserve(esrt_data, esrt_data_size);
+   if (md.type == EFI_BOOT_SERVICES_DATA)
+   efi_mem_reserve(esrt_data, esrt_data_size);
 
pr_debug("esrt-init: loaded.\n");
 err_memunmap:

[PATCH 4.18 167/235] efi/esrt: Only call efi_mem_reserve() for boot services memory

[Greg Kroah-Hartman]

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

--

From: Ard Biesheuvel 

[ Upstream commit 61f0d55569463a1af897117ff47d202b0ccb2e24 ]

The following commit:

  7e1550b8f208 ("efi: Drop type and attribute checks in efi_mem_desc_lookup()")

refactored the implementation of efi_mem_desc_lookup() so that the type
check is moved to the callers, one of which is the x86 version of
efi_arch_mem_reserve(), where we added a modified check that only takes
EFI_BOOT_SERVICES_DATA regions into account.

This is reasonable, since it is the only memory type that requires this,
but doing so uncovered some unexpected behavior in the ESRT code, which
permits the ESRT table to reside in other types of memory than what the
UEFI spec mandates (i.e., EFI_BOOT_SERVICES_DATA), and unconditionally
calls efi_mem_reserve() on the region in question. This may result in
errors such as

  esrt: Reserving ESRT space from 0x9c810318 to 0x9c810350.
  efi: Failed to lookup EFI memory descriptor for 0x9c810318

when the ESRT table is not in EFI_BOOT_SERVICES_DATA memory, but we try
to reserve it nonetheless.

So make the call to efi_mem_reserve() conditional on the memory type.

Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/firmware/efi/esrt.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/firmware/efi/esrt.c
+++ b/drivers/firmware/efi/esrt.c
@@ -326,7 +326,8 @@ void __init efi_esrt_init(void)
 
end = esrt_data + size;
pr_info("Reserving ESRT space from %pa to %pa.\n", _data, );
-   efi_mem_reserve(esrt_data, esrt_data_size);
+   if (md.type == EFI_BOOT_SERVICES_DATA)
+   efi_mem_reserve(esrt_data, esrt_data_size);
 
pr_debug("esrt-init: loaded.\n");
 }

[PATCH 4.14 122/173] efi/esrt: Only call efi_mem_reserve() for boot services memory

[Greg Kroah-Hartman]

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

--

From: Ard Biesheuvel 

[ Upstream commit 61f0d55569463a1af897117ff47d202b0ccb2e24 ]

The following commit:

  7e1550b8f208 ("efi: Drop type and attribute checks in efi_mem_desc_lookup()")

refactored the implementation of efi_mem_desc_lookup() so that the type
check is moved to the callers, one of which is the x86 version of
efi_arch_mem_reserve(), where we added a modified check that only takes
EFI_BOOT_SERVICES_DATA regions into account.

This is reasonable, since it is the only memory type that requires this,
but doing so uncovered some unexpected behavior in the ESRT code, which
permits the ESRT table to reside in other types of memory than what the
UEFI spec mandates (i.e., EFI_BOOT_SERVICES_DATA), and unconditionally
calls efi_mem_reserve() on the region in question. This may result in
errors such as

  esrt: Reserving ESRT space from 0x9c810318 to 0x9c810350.
  efi: Failed to lookup EFI memory descriptor for 0x9c810318

when the ESRT table is not in EFI_BOOT_SERVICES_DATA memory, but we try
to reserve it nonetheless.

So make the call to efi_mem_reserve() conditional on the memory type.

Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/firmware/efi/esrt.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/firmware/efi/esrt.c
+++ b/drivers/firmware/efi/esrt.c
@@ -333,7 +333,8 @@ void __init efi_esrt_init(void)
 
end = esrt_data + size;
pr_info("Reserving ESRT space from %pa to %pa.\n", _data, );
-   efi_mem_reserve(esrt_data, esrt_data_size);
+   if (md.type == EFI_BOOT_SERVICES_DATA)
+   efi_mem_reserve(esrt_data, esrt_data_size);
 
pr_debug("esrt-init: loaded.\n");
 err_memunmap:

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Greg Kroah-Hartman]

On Fri, Aug 31, 2018 at 07:24:08AM +0100, Guillaume Tucker wrote:
> On 24/08/18 21:32, Guenter Roeck wrote:
> > On Fri, Aug 24, 2018 at 01:16:18PM -0700, Roland Dreier wrote:
> >>> Sounds great. I'll hold off with sending my RFT series and wait for your
> >>> test results. I think we'll also need d367cef0a7f0c6 ("x86/mm/pat: Fix
> >>> boot crash when 1GB pages are not supported by the CPU").
> >>
> >> Sure, makes sense - I don't have any EFI systems with CPUs old enough
> >> not to support 1G pages but that looks reasonable.  I'll pull that
> >> into my tree as well.
> >>
> > kernelci reported a crash on a CPU which doesn't support 1G pages.
> > See https://kernelci.org/boot/id/5b7d39ea59b514c03796ba9c/
> 
> Looks like this has now been fixed with Andi's patch in 4.4.153:
> 
>   "x86/mm/pat: Fix L1TF stable backport for CPA"
> 
> I can confirm this platform is now booting fine in kernelci:
> 
>   http://lava.streamtester.net/scheduler/job/146195

Wonderful, thanks for letting us know.

greg k-h

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Greg Kroah-Hartman]

On Sat, Aug 25, 2018 at 06:52:32AM -0700, Guenter Roeck wrote:
> Hi Roland,
> 
> On 08/24/2018 01:04 PM, Roland Dreier wrote:
> > > Ok, so what patch should be reverted?  I'm seeing other reports of
> > > problems all around this same area, but I can't figure out exactly what
> > > to do.
> > 
> > Are any of those reports public?  If so can you point me at them, I'm
> > curious if the symptoms match up.
> > 
> > I don't think we want to revert anything.  I think you should pull in
> > edc3b9129cec and at least the first three patches that Ben listed:
> > 
> > 21cdb6b56843 x86/mm: Page align the '_end' symbol to avoid pfn conversion 
> > bugs
> > b61a76f8850d x86/efi: Map RAM into the identity page table for mixed mode
> > 753b11ef8e92 x86/efi: Setup separate EFI page tables in kexec paths
> > 
> > the first patch takes a bit of massaging (mostly because some of it is
> > already touched by 02ff2769edbc, which keeps the changes from
> > edc3b9129cec, and so we can drop a good bit when applying).  The other
> > three apply cleanly.
> > 
> > I'm currently testing that and can send you the state of my tree in a bit.
> > 
> 
> Have you made any progress ? On my side I am still out of luck since I can not
> reproduce the problem.

Perhaps just the patch that Andi posted to the stable list helps out
here?

Roland, can you try just that?

thanks,

greg k-h

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Greg Kroah-Hartman]

On Fri, Aug 24, 2018 at 10:08:28AM -0700, Roland Dreier wrote:
> > See
> > .
> 
> Thanks!  I'm not using SGI UV and I'm not using kexec, so I guess I
> sidestepped most of those issues.  Greg, I think we need to unrevert
> the cpa->pfn change (otherwise the L1TF fix probably gets pretty
> messy) and I guess pull in the other patches that Ben mentions.

Ok, so what patch should be reverted?  I'm seeing other reports of
problems all around this same area, but I can't figure out exactly what
to do.

Guenter, any ideas?

thanks,

greg k-h

Re: [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"

[Greg Kroah-Hartman]

On Wed, Aug 22, 2018 at 05:48:32PM -0700, Roland Dreier wrote:
> On Fri, Dec 15, 2017 at 2:20 AM Greg Kroah-Hartman
>  wrote:
> > This reverts commit 87e2bd898d3a79a8c609f183180adac47879a2a4 which is
> > commit edc3b9129cecd0f0857112136f5b8b1bc1d45918 upstream.
> >
> > Turns there was too many other issues with this patch to make it viable
> > for the stable tree.
> 
> This was sort of a long time ago, but does anyone remember why this
> needed to be reverted from 4.4?

I tried to dig through my old emails, but could not find anything,
sorry.

> The reason I ask is that without this, commit 02ff2769edbc /
> "x86/mm/pat: Make set_memory_np() L1TF safe" in 4.4.148 is broken.
> That patch has
> 
> -   set_pud(pud, __pud(cpa->pfn | _PAGE_PSE |
> -  massage_pgprot(pud_pgprot)));
> +   set_pud(pud, pud_mkhuge(pfn_pud(cpa->pfn,
> +  canon_pgprot(pud_pgprot;
> 
> (and similarly for pmds) but pfn_pud() is operating on page frame
> numbers and __pud(cpa->pfn... in the old code is operating on physical
> addresses.
> 
> This is bad enough that 4.4.148 and all newer 4.4.y crash early in
> boot on some EFI systems that I have.

Ugh, not good.

> For now I am re-applying the "ensure cpa->pfn only contains page frame
> numbers" patch, ported on top of 4.4.151.

I can try to add it back and see what blows up, want me to attempt that?
:)

thanks,

greg k-h

[PATCH 4.17 17/31] x86/efi: Access EFI MMIO data as unencrypted when SEV is active

[Greg Kroah-Hartman]

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

--

From: Brijesh Singh 

commit 9b788f32bee6b0b293a4bdfca4ad4bb0206407fb upstream.

SEV guest fails to update the UEFI runtime variables stored in the
flash.

The following commit:

  1379edd59673 ("x86/efi: Access EFI data as encrypted when SEV is active")

unconditionally maps all the UEFI runtime data as 'encrypted' (C=1).

When SEV is active the UEFI runtime data marked as EFI_MEMORY_MAPPED_IO
should be mapped as 'unencrypted' so that both guest and hypervisor can
access the data.

Signed-off-by: Brijesh Singh 
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Tom Lendacky 
Cc:  # 4.15.x
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 1379edd59673 ("x86/efi: Access EFI data as encrypted ...")
Link: http://lkml.kernel.org/r/20180720012846.23560-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/platform/efi/efi_64.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -417,7 +417,7 @@ static void __init __map_region(efi_memo
if (!(md->attribute & EFI_MEMORY_WB))
flags |= _PAGE_PCD;
 
-   if (sev_active())
+   if (sev_active() && md->type != EFI_MEMORY_MAPPED_IO)
flags |= _PAGE_ENC;
 
pfn = md->phys_addr >> PAGE_SHIFT;


--
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.4 018/107] x86/paravirt: Make native_save_fl() extern inline

[Greg Kroah-Hartman]

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

--

From: Nick Desaulniers 

commit d0a8d9378d16eb3c69bd8e6d23779fbdbee3a8c7 upstream.

native_save_fl() is marked static inline, but by using it as
a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined.

paravirt's use of native_save_fl() also requires that no GPRs other than
%rax are clobbered.

Compilers have different heuristics which they use to emit stack guard
code, the emittance of which can break paravirt's callee saved assumption
by clobbering %rcx.

Marking a function definition extern inline means that if this version
cannot be inlined, then the out-of-line version will be preferred. By
having the out-of-line version be implemented in assembly, it cannot be
instrumented with a stack protector, which might violate custom calling
conventions that code like paravirt rely on.

The semantics of extern inline has changed since gnu89. This means that
folks using GCC versions >= 5.1 may see symbol redefinition errors at
link time for subdirs that override KBUILD_CFLAGS (making the C standard
used implicit) regardless of this patch. This has been cleaned up
earlier in the patch set, but is left as a note in the commit message
for future travelers.

Reports:
 https://lkml.org/lkml/2018/5/7/534
 https://github.com/ClangBuiltLinux/linux/issues/16

Discussion:
 https://bugs.llvm.org/show_bug.cgi?id=37512
 https://lkml.org/lkml/2018/5/24/1371

Thanks to the many folks that participated in the discussion.

[Backport for 4.4. 4.4 is missing commit 784d5699eddc "x86: move exports to
actual definitions" which doesn't apply cleanly, and not really worth
backporting IMO. It's simpler to change this patch from upstream:
  + #include 
rather than
  + #include ]

Debugged-by: Alistair Strachan 
Debugged-by: Matthias Kaehlcke 
Suggested-by: Arnd Bergmann 
Suggested-by: H. Peter Anvin 
Suggested-by: Tom Stellar 
Reported-by: Sedat Dilek 
Tested-by: Sedat Dilek 
Signed-off-by: Nick Desaulniers 
Acked-by: Juergen Gross 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: a...@redhat.com
Cc: akata...@vmware.com
Cc: a...@linux-foundation.org
Cc: andrea.pa...@amarulasolutions.com
Cc: ard.biesheu...@linaro.org
Cc: aryabi...@virtuozzo.com
Cc: astrac...@google.com
Cc: boris.ostrov...@oracle.com
Cc: brijesh.si...@amd.com
Cc: caoj.f...@cn.fujitsu.com
Cc: ge...@linux-m68k.org
Cc: ghackm...@google.com
Cc: gre...@linuxfoundation.org
Cc: jan.kis...@siemens.com
Cc: jarkko.sakki...@linux.intel.com
Cc: j...@perches.com
Cc: jpoim...@redhat.com
Cc: keesc...@google.com
Cc: kirill.shute...@linux.intel.com
Cc: kstew...@linuxfoundation.org
Cc: linux-efi@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: manojgu...@google.com
Cc: mawil...@microsoft.com
Cc: michal.l...@markovi.net
Cc: mj...@google.com
Cc: m...@chromium.org
Cc: pombreda...@nexb.com
Cc: rient...@google.com
Cc: rost...@goodmis.org
Cc: thomas.lenda...@amd.com
Cc: tw...@google.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: will.dea...@arm.com
Cc: yamada.masah...@socionext.com
Link: http://lkml.kernel.org/r/20180621162324.36656-4-ndesaulni...@google.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/irqflags.h |2 +-
 arch/x86/kernel/Makefile|1 +
 arch/x86/kernel/irqflags.S  |   26 ++
 3 files changed, 28 insertions(+), 1 deletion(-)

--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -8,7 +8,7 @@
  * Interrupt control:
  */
 
-static inline unsigned long native_save_fl(void)
+extern inline unsigned long native_save_fl(void)
 {
unsigned long flags;
 
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -41,6 +41,7 @@ obj-y += alternative.o i8253.o pci-nom
 obj-y  += tsc.o tsc_msr.o io_delay.o rtc.o
 obj-y  += pci-iommu_table.o
 obj-y  += resource.o
+obj-y  += irqflags.o
 
 obj-y  += process.o
 obj-y  += fpu/
--- /dev/null
+++ b/arch/x86/kernel/irqflags.S
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include 
+#include 
+#include 
+
+/*
+ * unsigned long native_save_fl(void)
+ */
+ENTRY(native_save_fl)
+   pushf
+   pop %_ASM_AX
+   ret
+ENDPROC(native_save_fl)
+EXPORT_SYMBOL(native_save_fl)
+
+/*
+ * void native_restore_fl(unsigned long flags)
+ * %eax/%rdi: flags
+ */
+ENTRY(native_restore_fl)
+   push %_ASM_ARG1
+   popf
+   ret
+ENDPROC(native_restore_fl)
+EXPORT_SYMBOL(native_restore_fl)


--
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.4 05/31] x86/asm: Add _ASM_ARG* constants for argument registers to

[Greg Kroah-Hartman]

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

--

From: H. Peter Anvin 

commit 0e2e160033283e20f688d8bad5b89460cc5bfcc4 upstream.

i386 and x86-64 uses different registers for arguments; make them
available so we don't have to #ifdef in the actual code.

Native size and specified size (q, l, w, b) versions are provided.

Signed-off-by: H. Peter Anvin 
Signed-off-by: Nick Desaulniers 
Reviewed-by: Sedat Dilek 
Acked-by: Juergen Gross 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: a...@redhat.com
Cc: akata...@vmware.com
Cc: a...@linux-foundation.org
Cc: andrea.pa...@amarulasolutions.com
Cc: ard.biesheu...@linaro.org
Cc: a...@arndb.de
Cc: aryabi...@virtuozzo.com
Cc: astrac...@google.com
Cc: boris.ostrov...@oracle.com
Cc: brijesh.si...@amd.com
Cc: caoj.f...@cn.fujitsu.com
Cc: ge...@linux-m68k.org
Cc: ghackm...@google.com
Cc: gre...@linuxfoundation.org
Cc: jan.kis...@siemens.com
Cc: jarkko.sakki...@linux.intel.com
Cc: j...@perches.com
Cc: jpoim...@redhat.com
Cc: keesc...@google.com
Cc: kirill.shute...@linux.intel.com
Cc: kstew...@linuxfoundation.org
Cc: linux-efi@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: manojgu...@google.com
Cc: mawil...@microsoft.com
Cc: michal.l...@markovi.net
Cc: mj...@google.com
Cc: m...@chromium.org
Cc: pombreda...@nexb.com
Cc: rient...@google.com
Cc: rost...@goodmis.org
Cc: thomas.lenda...@amd.com
Cc: tstel...@redhat.com
Cc: tw...@google.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: will.dea...@arm.com
Cc: yamada.masah...@socionext.com
Link: http://lkml.kernel.org/r/20180621162324.36656-3-ndesaulni...@google.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/asm.h |   59 +
 1 file changed, 59 insertions(+)

--- a/arch/x86/include/asm/asm.h
+++ b/arch/x86/include/asm/asm.h
@@ -44,6 +44,65 @@
 #define _ASM_SI__ASM_REG(si)
 #define _ASM_DI__ASM_REG(di)
 
+#ifndef __x86_64__
+/* 32 bit */
+
+#define _ASM_ARG1  _ASM_AX
+#define _ASM_ARG2  _ASM_DX
+#define _ASM_ARG3  _ASM_CX
+
+#define _ASM_ARG1L eax
+#define _ASM_ARG2L edx
+#define _ASM_ARG3L ecx
+
+#define _ASM_ARG1W ax
+#define _ASM_ARG2W dx
+#define _ASM_ARG3W cx
+
+#define _ASM_ARG1B al
+#define _ASM_ARG2B dl
+#define _ASM_ARG3B cl
+
+#else
+/* 64 bit */
+
+#define _ASM_ARG1  _ASM_DI
+#define _ASM_ARG2  _ASM_SI
+#define _ASM_ARG3  _ASM_DX
+#define _ASM_ARG4  _ASM_CX
+#define _ASM_ARG5  r8
+#define _ASM_ARG6  r9
+
+#define _ASM_ARG1Q rdi
+#define _ASM_ARG2Q rsi
+#define _ASM_ARG3Q rdx
+#define _ASM_ARG4Q rcx
+#define _ASM_ARG5Q r8
+#define _ASM_ARG6Q r9
+
+#define _ASM_ARG1L edi
+#define _ASM_ARG2L esi
+#define _ASM_ARG3L edx
+#define _ASM_ARG4L ecx
+#define _ASM_ARG5L r8d
+#define _ASM_ARG6L r9d
+
+#define _ASM_ARG1W di
+#define _ASM_ARG2W si
+#define _ASM_ARG3W dx
+#define _ASM_ARG4W cx
+#define _ASM_ARG5W r8w
+#define _ASM_ARG6W r9w
+
+#define _ASM_ARG1B dil
+#define _ASM_ARG2B sil
+#define _ASM_ARG3B dl
+#define _ASM_ARG4B cl
+#define _ASM_ARG5B r8b
+#define _ASM_ARG6B r9b
+
+#endif
+
 /* Exception table entry */
 #ifdef __ASSEMBLY__
 # define _ASM_EXTABLE(from,to) \


--
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 05/66] compiler-gcc.h: Add __attribute__((gnu_inline)) to all inline declarations

[Greg Kroah-Hartman]

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

--

From: Nick Desaulniers 

commit d03db2bc26f0e4a6849ad649a09c9c73fccdc656 upstream.

Functions marked extern inline do not emit an externally visible
function when the gnu89 C standard is used. Some KBUILD Makefiles
overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without
an explicit C standard specified, the default is gnu11. Since c99, the
semantics of extern inline have changed such that an externally visible
function is always emitted. This can lead to multiple definition errors
of extern inline functions at link time of compilation units whose build
files have removed an explicit C standard compiler flag for users of GCC
5.1+ or Clang.

Suggested-by: Arnd Bergmann 
Suggested-by: H. Peter Anvin 
Suggested-by: Joe Perches 
Signed-off-by: Nick Desaulniers 
Acked-by: Juergen Gross 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: a...@redhat.com
Cc: akata...@vmware.com
Cc: a...@linux-foundation.org
Cc: andrea.pa...@amarulasolutions.com
Cc: ard.biesheu...@linaro.org
Cc: aryabi...@virtuozzo.com
Cc: astrac...@google.com
Cc: boris.ostrov...@oracle.com
Cc: brijesh.si...@amd.com
Cc: caoj.f...@cn.fujitsu.com
Cc: ge...@linux-m68k.org
Cc: ghackm...@google.com
Cc: gre...@linuxfoundation.org
Cc: jan.kis...@siemens.com
Cc: jarkko.sakki...@linux.intel.com
Cc: jpoim...@redhat.com
Cc: keesc...@google.com
Cc: kirill.shute...@linux.intel.com
Cc: kstew...@linuxfoundation.org
Cc: linux-efi@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: manojgu...@google.com
Cc: mawil...@microsoft.com
Cc: michal.l...@markovi.net
Cc: mj...@google.com
Cc: m...@chromium.org
Cc: pombreda...@nexb.com
Cc: rient...@google.com
Cc: rost...@goodmis.org
Cc: sedat.di...@gmail.com
Cc: thomas.lenda...@amd.com
Cc: tstel...@redhat.com
Cc: tw...@google.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: will.dea...@arm.com
Cc: yamada.masah...@socionext.com
Link: http://lkml.kernel.org/r/20180621162324.36656-2-ndesaulni...@google.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/compiler-gcc.h |   29 ++---
 1 file changed, 22 insertions(+), 7 deletions(-)

--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -65,25 +65,40 @@
 #endif
 
 /*
+ * Feature detection for gnu_inline (gnu89 extern inline semantics). Either
+ * __GNUC_STDC_INLINE__ is defined (not using gnu89 extern inline semantics,
+ * and we opt in to the gnu89 semantics), or __GNUC_STDC_INLINE__ is not
+ * defined so the gnu89 semantics are the default.
+ */
+#ifdef __GNUC_STDC_INLINE__
+# define __gnu_inline  __attribute__((gnu_inline))
+#else
+# define __gnu_inline
+#endif
+
+/*
  * Force always-inline if the user requests it so via the .config,
  * or if gcc is too old.
  * GCC does not warn about unused static inline functions for
  * -Wunused-function.  This turns out to avoid the need for complex #ifdef
  * directives.  Suppress the warning in clang as well by using "unused"
  * function attribute, which is redundant but not harmful for gcc.
+ * Prefer gnu_inline, so that extern inline functions do not emit an
+ * externally visible function. This makes extern inline behave as per gnu89
+ * semantics rather than c99. This prevents multiple symbol definition errors
+ * of extern inline functions at link time.
+ * A lot of inline functions can cause havoc with function tracing.
  */
 #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) ||   \
 !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
-#define inline inline  __attribute__((always_inline,unused)) notrace
-#define __inline__ __inline__  __attribute__((always_inline,unused)) notrace
-#define __inline __inline  __attribute__((always_inline,unused)) notrace
+#define inline \
+   inline __attribute__((always_inline, unused)) notrace __gnu_inline
 #else
-/* A lot of inline functions can cause havoc with function tracing */
-#define inline inline  __attribute__((unused)) notrace
-#define __inline__ __inline__  __attribute__((unused)) notrace
-#define __inline __inline  __attribute__((unused)) notrace
+#define inline inline  __attribute__((unused)) notrace __gnu_inline
 #endif
 
+#define __inline__ inline
+#define __inline inline
 #define __always_inlineinline __attribute__((always_inline))
 #define  noinline  __attribute__((noinline))
 


--
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 06/66] x86/asm: Add _ASM_ARG* constants for argument registers to

[Greg Kroah-Hartman]

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

--

From: H. Peter Anvin 

commit 0e2e160033283e20f688d8bad5b89460cc5bfcc4 upstream.

i386 and x86-64 uses different registers for arguments; make them
available so we don't have to #ifdef in the actual code.

Native size and specified size (q, l, w, b) versions are provided.

Signed-off-by: H. Peter Anvin 
Signed-off-by: Nick Desaulniers 
Reviewed-by: Sedat Dilek 
Acked-by: Juergen Gross 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: a...@redhat.com
Cc: akata...@vmware.com
Cc: a...@linux-foundation.org
Cc: andrea.pa...@amarulasolutions.com
Cc: ard.biesheu...@linaro.org
Cc: a...@arndb.de
Cc: aryabi...@virtuozzo.com
Cc: astrac...@google.com
Cc: boris.ostrov...@oracle.com
Cc: brijesh.si...@amd.com
Cc: caoj.f...@cn.fujitsu.com
Cc: ge...@linux-m68k.org
Cc: ghackm...@google.com
Cc: gre...@linuxfoundation.org
Cc: jan.kis...@siemens.com
Cc: jarkko.sakki...@linux.intel.com
Cc: j...@perches.com
Cc: jpoim...@redhat.com
Cc: keesc...@google.com
Cc: kirill.shute...@linux.intel.com
Cc: kstew...@linuxfoundation.org
Cc: linux-efi@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: manojgu...@google.com
Cc: mawil...@microsoft.com
Cc: michal.l...@markovi.net
Cc: mj...@google.com
Cc: m...@chromium.org
Cc: pombreda...@nexb.com
Cc: rient...@google.com
Cc: rost...@goodmis.org
Cc: thomas.lenda...@amd.com
Cc: tstel...@redhat.com
Cc: tw...@google.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: will.dea...@arm.com
Cc: yamada.masah...@socionext.com
Link: http://lkml.kernel.org/r/20180621162324.36656-3-ndesaulni...@google.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/asm.h |   59 +
 1 file changed, 59 insertions(+)

--- a/arch/x86/include/asm/asm.h
+++ b/arch/x86/include/asm/asm.h
@@ -45,6 +45,65 @@
 #define _ASM_SI__ASM_REG(si)
 #define _ASM_DI__ASM_REG(di)
 
+#ifndef __x86_64__
+/* 32 bit */
+
+#define _ASM_ARG1  _ASM_AX
+#define _ASM_ARG2  _ASM_DX
+#define _ASM_ARG3  _ASM_CX
+
+#define _ASM_ARG1L eax
+#define _ASM_ARG2L edx
+#define _ASM_ARG3L ecx
+
+#define _ASM_ARG1W ax
+#define _ASM_ARG2W dx
+#define _ASM_ARG3W cx
+
+#define _ASM_ARG1B al
+#define _ASM_ARG2B dl
+#define _ASM_ARG3B cl
+
+#else
+/* 64 bit */
+
+#define _ASM_ARG1  _ASM_DI
+#define _ASM_ARG2  _ASM_SI
+#define _ASM_ARG3  _ASM_DX
+#define _ASM_ARG4  _ASM_CX
+#define _ASM_ARG5  r8
+#define _ASM_ARG6  r9
+
+#define _ASM_ARG1Q rdi
+#define _ASM_ARG2Q rsi
+#define _ASM_ARG3Q rdx
+#define _ASM_ARG4Q rcx
+#define _ASM_ARG5Q r8
+#define _ASM_ARG6Q r9
+
+#define _ASM_ARG1L edi
+#define _ASM_ARG2L esi
+#define _ASM_ARG3L edx
+#define _ASM_ARG4L ecx
+#define _ASM_ARG5L r8d
+#define _ASM_ARG6L r9d
+
+#define _ASM_ARG1W di
+#define _ASM_ARG2W si
+#define _ASM_ARG3W dx
+#define _ASM_ARG4W cx
+#define _ASM_ARG5W r8w
+#define _ASM_ARG6W r9w
+
+#define _ASM_ARG1B dil
+#define _ASM_ARG2B sil
+#define _ASM_ARG3B dl
+#define _ASM_ARG4B cl
+#define _ASM_ARG5B r8b
+#define _ASM_ARG6B r9b
+
+#endif
+
 /*
  * Macros to generate condition code outputs from inline assembly,
  * The output operand must be type "bool".


--
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.14 01/92] compiler-gcc.h: Add __attribute__((gnu_inline)) to all inline declarations

[Greg Kroah-Hartman]

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

--

From: Nick Desaulniers 

commit d03db2bc26f0e4a6849ad649a09c9c73fccdc656 upstream.

Functions marked extern inline do not emit an externally visible
function when the gnu89 C standard is used. Some KBUILD Makefiles
overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without
an explicit C standard specified, the default is gnu11. Since c99, the
semantics of extern inline have changed such that an externally visible
function is always emitted. This can lead to multiple definition errors
of extern inline functions at link time of compilation units whose build
files have removed an explicit C standard compiler flag for users of GCC
5.1+ or Clang.

Suggested-by: Arnd Bergmann 
Suggested-by: H. Peter Anvin 
Suggested-by: Joe Perches 
Signed-off-by: Nick Desaulniers 
Acked-by: Juergen Gross 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: a...@redhat.com
Cc: akata...@vmware.com
Cc: a...@linux-foundation.org
Cc: andrea.pa...@amarulasolutions.com
Cc: ard.biesheu...@linaro.org
Cc: aryabi...@virtuozzo.com
Cc: astrac...@google.com
Cc: boris.ostrov...@oracle.com
Cc: brijesh.si...@amd.com
Cc: caoj.f...@cn.fujitsu.com
Cc: ge...@linux-m68k.org
Cc: ghackm...@google.com
Cc: gre...@linuxfoundation.org
Cc: jan.kis...@siemens.com
Cc: jarkko.sakki...@linux.intel.com
Cc: jpoim...@redhat.com
Cc: keesc...@google.com
Cc: kirill.shute...@linux.intel.com
Cc: kstew...@linuxfoundation.org
Cc: linux-efi@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: manojgu...@google.com
Cc: mawil...@microsoft.com
Cc: michal.l...@markovi.net
Cc: mj...@google.com
Cc: m...@chromium.org
Cc: pombreda...@nexb.com
Cc: rient...@google.com
Cc: rost...@goodmis.org
Cc: sedat.di...@gmail.com
Cc: thomas.lenda...@amd.com
Cc: tstel...@redhat.com
Cc: tw...@google.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: will.dea...@arm.com
Cc: yamada.masah...@socionext.com
Link: http://lkml.kernel.org/r/20180621162324.36656-2-ndesaulni...@google.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/compiler-gcc.h |   29 ++---
 1 file changed, 22 insertions(+), 7 deletions(-)

--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -66,25 +66,40 @@
 #endif
 
 /*
+ * Feature detection for gnu_inline (gnu89 extern inline semantics). Either
+ * __GNUC_STDC_INLINE__ is defined (not using gnu89 extern inline semantics,
+ * and we opt in to the gnu89 semantics), or __GNUC_STDC_INLINE__ is not
+ * defined so the gnu89 semantics are the default.
+ */
+#ifdef __GNUC_STDC_INLINE__
+# define __gnu_inline  __attribute__((gnu_inline))
+#else
+# define __gnu_inline
+#endif
+
+/*
  * Force always-inline if the user requests it so via the .config,
  * or if gcc is too old.
  * GCC does not warn about unused static inline functions for
  * -Wunused-function.  This turns out to avoid the need for complex #ifdef
  * directives.  Suppress the warning in clang as well by using "unused"
  * function attribute, which is redundant but not harmful for gcc.
+ * Prefer gnu_inline, so that extern inline functions do not emit an
+ * externally visible function. This makes extern inline behave as per gnu89
+ * semantics rather than c99. This prevents multiple symbol definition errors
+ * of extern inline functions at link time.
+ * A lot of inline functions can cause havoc with function tracing.
  */
 #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) ||   \
 !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
-#define inline inline  __attribute__((always_inline,unused)) notrace
-#define __inline__ __inline__  __attribute__((always_inline,unused)) notrace
-#define __inline __inline  __attribute__((always_inline,unused)) notrace
+#define inline \
+   inline __attribute__((always_inline, unused)) notrace __gnu_inline
 #else
-/* A lot of inline functions can cause havoc with function tracing */
-#define inline inline  __attribute__((unused)) notrace
-#define __inline__ __inline__  __attribute__((unused)) notrace
-#define __inline __inline  __attribute__((unused)) notrace
+#define inline inline  __attribute__((unused)) notrace __gnu_inline
 #endif
 
+#define __inline__ inline
+#define __inline inline
 #define __always_inlineinline __attribute__((always_inline))
 #define  noinline  __attribute__((noinline))
 


--
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.14 03/92] x86/paravirt: Make native_save_fl() extern inline

[Greg Kroah-Hartman]

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

--

From: Nick Desaulniers 

commit d0a8d9378d16eb3c69bd8e6d23779fbdbee3a8c7 upstream.

native_save_fl() is marked static inline, but by using it as
a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined.

paravirt's use of native_save_fl() also requires that no GPRs other than
%rax are clobbered.

Compilers have different heuristics which they use to emit stack guard
code, the emittance of which can break paravirt's callee saved assumption
by clobbering %rcx.

Marking a function definition extern inline means that if this version
cannot be inlined, then the out-of-line version will be preferred. By
having the out-of-line version be implemented in assembly, it cannot be
instrumented with a stack protector, which might violate custom calling
conventions that code like paravirt rely on.

The semantics of extern inline has changed since gnu89. This means that
folks using GCC versions >= 5.1 may see symbol redefinition errors at
link time for subdirs that override KBUILD_CFLAGS (making the C standard
used implicit) regardless of this patch. This has been cleaned up
earlier in the patch set, but is left as a note in the commit message
for future travelers.

Reports:
 https://lkml.org/lkml/2018/5/7/534
 https://github.com/ClangBuiltLinux/linux/issues/16

Discussion:
 https://bugs.llvm.org/show_bug.cgi?id=37512
 https://lkml.org/lkml/2018/5/24/1371

Thanks to the many folks that participated in the discussion.

Debugged-by: Alistair Strachan 
Debugged-by: Matthias Kaehlcke 
Suggested-by: Arnd Bergmann 
Suggested-by: H. Peter Anvin 
Suggested-by: Tom Stellar 
Reported-by: Sedat Dilek 
Tested-by: Sedat Dilek 
Signed-off-by: Nick Desaulniers 
Acked-by: Juergen Gross 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: a...@redhat.com
Cc: akata...@vmware.com
Cc: a...@linux-foundation.org
Cc: andrea.pa...@amarulasolutions.com
Cc: ard.biesheu...@linaro.org
Cc: aryabi...@virtuozzo.com
Cc: astrac...@google.com
Cc: boris.ostrov...@oracle.com
Cc: brijesh.si...@amd.com
Cc: caoj.f...@cn.fujitsu.com
Cc: ge...@linux-m68k.org
Cc: ghackm...@google.com
Cc: gre...@linuxfoundation.org
Cc: jan.kis...@siemens.com
Cc: jarkko.sakki...@linux.intel.com
Cc: j...@perches.com
Cc: jpoim...@redhat.com
Cc: keesc...@google.com
Cc: kirill.shute...@linux.intel.com
Cc: kstew...@linuxfoundation.org
Cc: linux-efi@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: manojgu...@google.com
Cc: mawil...@microsoft.com
Cc: michal.l...@markovi.net
Cc: mj...@google.com
Cc: m...@chromium.org
Cc: pombreda...@nexb.com
Cc: rient...@google.com
Cc: rost...@goodmis.org
Cc: thomas.lenda...@amd.com
Cc: tw...@google.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: will.dea...@arm.com
Cc: yamada.masah...@socionext.com
Link: http://lkml.kernel.org/r/20180621162324.36656-4-ndesaulni...@google.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/irqflags.h |2 +-
 arch/x86/kernel/Makefile|1 +
 arch/x86/kernel/irqflags.S  |   26 ++
 3 files changed, 28 insertions(+), 1 deletion(-)

--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -13,7 +13,7 @@
  * Interrupt control:
  */
 
-static inline unsigned long native_save_fl(void)
+extern inline unsigned long native_save_fl(void)
 {
unsigned long flags;
 
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -58,6 +58,7 @@ obj-y += alternative.o i8253.o pci-nom
 obj-y  += tsc.o tsc_msr.o io_delay.o rtc.o
 obj-y  += pci-iommu_table.o
 obj-y  += resource.o
+obj-y  += irqflags.o
 
 obj-y  += process.o
 obj-y  += fpu/
--- /dev/null
+++ b/arch/x86/kernel/irqflags.S
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include 
+#include 
+#include 
+
+/*
+ * unsigned long native_save_fl(void)
+ */
+ENTRY(native_save_fl)
+   pushf
+   pop %_ASM_AX
+   ret
+ENDPROC(native_save_fl)
+EXPORT_SYMBOL(native_save_fl)
+
+/*
+ * void native_restore_fl(unsigned long flags)
+ * %eax/%rdi: flags
+ */
+ENTRY(native_restore_fl)
+   push %_ASM_ARG1
+   popf
+   ret
+ENDPROC(native_restore_fl)
+EXPORT_SYMBOL(native_restore_fl)


--
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.17 002/101] x86/asm: Add _ASM_ARG* constants for argument registers to

[Greg Kroah-Hartman]

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

--

From: H. Peter Anvin 

commit 0e2e160033283e20f688d8bad5b89460cc5bfcc4 upstream.

i386 and x86-64 uses different registers for arguments; make them
available so we don't have to #ifdef in the actual code.

Native size and specified size (q, l, w, b) versions are provided.

Signed-off-by: H. Peter Anvin 
Signed-off-by: Nick Desaulniers 
Reviewed-by: Sedat Dilek 
Acked-by: Juergen Gross 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: a...@redhat.com
Cc: akata...@vmware.com
Cc: a...@linux-foundation.org
Cc: andrea.pa...@amarulasolutions.com
Cc: ard.biesheu...@linaro.org
Cc: a...@arndb.de
Cc: aryabi...@virtuozzo.com
Cc: astrac...@google.com
Cc: boris.ostrov...@oracle.com
Cc: brijesh.si...@amd.com
Cc: caoj.f...@cn.fujitsu.com
Cc: ge...@linux-m68k.org
Cc: ghackm...@google.com
Cc: gre...@linuxfoundation.org
Cc: jan.kis...@siemens.com
Cc: jarkko.sakki...@linux.intel.com
Cc: j...@perches.com
Cc: jpoim...@redhat.com
Cc: keesc...@google.com
Cc: kirill.shute...@linux.intel.com
Cc: kstew...@linuxfoundation.org
Cc: linux-efi@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: manojgu...@google.com
Cc: mawil...@microsoft.com
Cc: michal.l...@markovi.net
Cc: mj...@google.com
Cc: m...@chromium.org
Cc: pombreda...@nexb.com
Cc: rient...@google.com
Cc: rost...@goodmis.org
Cc: thomas.lenda...@amd.com
Cc: tstel...@redhat.com
Cc: tw...@google.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: will.dea...@arm.com
Cc: yamada.masah...@socionext.com
Link: http://lkml.kernel.org/r/20180621162324.36656-3-ndesaulni...@google.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/asm.h |   59 +
 1 file changed, 59 insertions(+)

--- a/arch/x86/include/asm/asm.h
+++ b/arch/x86/include/asm/asm.h
@@ -46,6 +46,65 @@
 #define _ASM_SI__ASM_REG(si)
 #define _ASM_DI__ASM_REG(di)
 
+#ifndef __x86_64__
+/* 32 bit */
+
+#define _ASM_ARG1  _ASM_AX
+#define _ASM_ARG2  _ASM_DX
+#define _ASM_ARG3  _ASM_CX
+
+#define _ASM_ARG1L eax
+#define _ASM_ARG2L edx
+#define _ASM_ARG3L ecx
+
+#define _ASM_ARG1W ax
+#define _ASM_ARG2W dx
+#define _ASM_ARG3W cx
+
+#define _ASM_ARG1B al
+#define _ASM_ARG2B dl
+#define _ASM_ARG3B cl
+
+#else
+/* 64 bit */
+
+#define _ASM_ARG1  _ASM_DI
+#define _ASM_ARG2  _ASM_SI
+#define _ASM_ARG3  _ASM_DX
+#define _ASM_ARG4  _ASM_CX
+#define _ASM_ARG5  r8
+#define _ASM_ARG6  r9
+
+#define _ASM_ARG1Q rdi
+#define _ASM_ARG2Q rsi
+#define _ASM_ARG3Q rdx
+#define _ASM_ARG4Q rcx
+#define _ASM_ARG5Q r8
+#define _ASM_ARG6Q r9
+
+#define _ASM_ARG1L edi
+#define _ASM_ARG2L esi
+#define _ASM_ARG3L edx
+#define _ASM_ARG4L ecx
+#define _ASM_ARG5L r8d
+#define _ASM_ARG6L r9d
+
+#define _ASM_ARG1W di
+#define _ASM_ARG2W si
+#define _ASM_ARG3W dx
+#define _ASM_ARG4W cx
+#define _ASM_ARG5W r8w
+#define _ASM_ARG6W r9w
+
+#define _ASM_ARG1B dil
+#define _ASM_ARG2B sil
+#define _ASM_ARG3B dl
+#define _ASM_ARG4B cl
+#define _ASM_ARG5B r8b
+#define _ASM_ARG6B r9b
+
+#endif
+
 /*
  * Macros to generate condition code outputs from inline assembly,
  * The output operand must be type "bool".


--
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.17 003/101] x86/paravirt: Make native_save_fl() extern inline

[Greg Kroah-Hartman]

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

--

From: Nick Desaulniers 

commit d0a8d9378d16eb3c69bd8e6d23779fbdbee3a8c7 upstream.

native_save_fl() is marked static inline, but by using it as
a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined.

paravirt's use of native_save_fl() also requires that no GPRs other than
%rax are clobbered.

Compilers have different heuristics which they use to emit stack guard
code, the emittance of which can break paravirt's callee saved assumption
by clobbering %rcx.

Marking a function definition extern inline means that if this version
cannot be inlined, then the out-of-line version will be preferred. By
having the out-of-line version be implemented in assembly, it cannot be
instrumented with a stack protector, which might violate custom calling
conventions that code like paravirt rely on.

The semantics of extern inline has changed since gnu89. This means that
folks using GCC versions >= 5.1 may see symbol redefinition errors at
link time for subdirs that override KBUILD_CFLAGS (making the C standard
used implicit) regardless of this patch. This has been cleaned up
earlier in the patch set, but is left as a note in the commit message
for future travelers.

Reports:
 https://lkml.org/lkml/2018/5/7/534
 https://github.com/ClangBuiltLinux/linux/issues/16

Discussion:
 https://bugs.llvm.org/show_bug.cgi?id=37512
 https://lkml.org/lkml/2018/5/24/1371

Thanks to the many folks that participated in the discussion.

Debugged-by: Alistair Strachan 
Debugged-by: Matthias Kaehlcke 
Suggested-by: Arnd Bergmann 
Suggested-by: H. Peter Anvin 
Suggested-by: Tom Stellar 
Reported-by: Sedat Dilek 
Tested-by: Sedat Dilek 
Signed-off-by: Nick Desaulniers 
Acked-by: Juergen Gross 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: a...@redhat.com
Cc: akata...@vmware.com
Cc: a...@linux-foundation.org
Cc: andrea.pa...@amarulasolutions.com
Cc: ard.biesheu...@linaro.org
Cc: aryabi...@virtuozzo.com
Cc: astrac...@google.com
Cc: boris.ostrov...@oracle.com
Cc: brijesh.si...@amd.com
Cc: caoj.f...@cn.fujitsu.com
Cc: ge...@linux-m68k.org
Cc: ghackm...@google.com
Cc: gre...@linuxfoundation.org
Cc: jan.kis...@siemens.com
Cc: jarkko.sakki...@linux.intel.com
Cc: j...@perches.com
Cc: jpoim...@redhat.com
Cc: keesc...@google.com
Cc: kirill.shute...@linux.intel.com
Cc: kstew...@linuxfoundation.org
Cc: linux-efi@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: manojgu...@google.com
Cc: mawil...@microsoft.com
Cc: michal.l...@markovi.net
Cc: mj...@google.com
Cc: m...@chromium.org
Cc: pombreda...@nexb.com
Cc: rient...@google.com
Cc: rost...@goodmis.org
Cc: thomas.lenda...@amd.com
Cc: tw...@google.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: will.dea...@arm.com
Cc: yamada.masah...@socionext.com
Link: http://lkml.kernel.org/r/20180621162324.36656-4-ndesaulni...@google.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/irqflags.h |2 +-
 arch/x86/kernel/Makefile|1 +
 arch/x86/kernel/irqflags.S  |   26 ++
 3 files changed, 28 insertions(+), 1 deletion(-)

--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -13,7 +13,7 @@
  * Interrupt control:
  */
 
-static inline unsigned long native_save_fl(void)
+extern inline unsigned long native_save_fl(void)
 {
unsigned long flags;
 
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -61,6 +61,7 @@ obj-y += alternative.o i8253.o hw_brea
 obj-y  += tsc.o tsc_msr.o io_delay.o rtc.o
 obj-y  += pci-iommu_table.o
 obj-y  += resource.o
+obj-y  += irqflags.o
 
 obj-y  += process.o
 obj-y  += fpu/
--- /dev/null
+++ b/arch/x86/kernel/irqflags.S
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include 
+#include 
+#include 
+
+/*
+ * unsigned long native_save_fl(void)
+ */
+ENTRY(native_save_fl)
+   pushf
+   pop %_ASM_AX
+   ret
+ENDPROC(native_save_fl)
+EXPORT_SYMBOL(native_save_fl)
+
+/*
+ * void native_restore_fl(unsigned long flags)
+ * %eax/%rdi: flags
+ */
+ENTRY(native_restore_fl)
+   push %_ASM_ARG1
+   popf
+   ret
+ENDPROC(native_restore_fl)
+EXPORT_SYMBOL(native_restore_fl)


--
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.17 001/101] compiler-gcc.h: Add __attribute__((gnu_inline)) to all inline declarations

[Greg Kroah-Hartman]

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

--

From: Nick Desaulniers 

commit d03db2bc26f0e4a6849ad649a09c9c73fccdc656 upstream.

Functions marked extern inline do not emit an externally visible
function when the gnu89 C standard is used. Some KBUILD Makefiles
overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without
an explicit C standard specified, the default is gnu11. Since c99, the
semantics of extern inline have changed such that an externally visible
function is always emitted. This can lead to multiple definition errors
of extern inline functions at link time of compilation units whose build
files have removed an explicit C standard compiler flag for users of GCC
5.1+ or Clang.

Suggested-by: Arnd Bergmann 
Suggested-by: H. Peter Anvin 
Suggested-by: Joe Perches 
Signed-off-by: Nick Desaulniers 
Acked-by: Juergen Gross 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: a...@redhat.com
Cc: akata...@vmware.com
Cc: a...@linux-foundation.org
Cc: andrea.pa...@amarulasolutions.com
Cc: ard.biesheu...@linaro.org
Cc: aryabi...@virtuozzo.com
Cc: astrac...@google.com
Cc: boris.ostrov...@oracle.com
Cc: brijesh.si...@amd.com
Cc: caoj.f...@cn.fujitsu.com
Cc: ge...@linux-m68k.org
Cc: ghackm...@google.com
Cc: gre...@linuxfoundation.org
Cc: jan.kis...@siemens.com
Cc: jarkko.sakki...@linux.intel.com
Cc: jpoim...@redhat.com
Cc: keesc...@google.com
Cc: kirill.shute...@linux.intel.com
Cc: kstew...@linuxfoundation.org
Cc: linux-efi@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: manojgu...@google.com
Cc: mawil...@microsoft.com
Cc: michal.l...@markovi.net
Cc: mj...@google.com
Cc: m...@chromium.org
Cc: pombreda...@nexb.com
Cc: rient...@google.com
Cc: rost...@goodmis.org
Cc: sedat.di...@gmail.com
Cc: thomas.lenda...@amd.com
Cc: tstel...@redhat.com
Cc: tw...@google.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: will.dea...@arm.com
Cc: yamada.masah...@socionext.com
Link: http://lkml.kernel.org/r/20180621162324.36656-2-ndesaulni...@google.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/compiler-gcc.h |   29 ++---
 1 file changed, 22 insertions(+), 7 deletions(-)

--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -66,25 +66,40 @@
 #endif
 
 /*
+ * Feature detection for gnu_inline (gnu89 extern inline semantics). Either
+ * __GNUC_STDC_INLINE__ is defined (not using gnu89 extern inline semantics,
+ * and we opt in to the gnu89 semantics), or __GNUC_STDC_INLINE__ is not
+ * defined so the gnu89 semantics are the default.
+ */
+#ifdef __GNUC_STDC_INLINE__
+# define __gnu_inline  __attribute__((gnu_inline))
+#else
+# define __gnu_inline
+#endif
+
+/*
  * Force always-inline if the user requests it so via the .config,
  * or if gcc is too old.
  * GCC does not warn about unused static inline functions for
  * -Wunused-function.  This turns out to avoid the need for complex #ifdef
  * directives.  Suppress the warning in clang as well by using "unused"
  * function attribute, which is redundant but not harmful for gcc.
+ * Prefer gnu_inline, so that extern inline functions do not emit an
+ * externally visible function. This makes extern inline behave as per gnu89
+ * semantics rather than c99. This prevents multiple symbol definition errors
+ * of extern inline functions at link time.
+ * A lot of inline functions can cause havoc with function tracing.
  */
 #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) ||   \
 !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
-#define inline inline  __attribute__((always_inline,unused)) notrace
-#define __inline__ __inline__  __attribute__((always_inline,unused)) notrace
-#define __inline __inline  __attribute__((always_inline,unused)) notrace
+#define inline \
+   inline __attribute__((always_inline, unused)) notrace __gnu_inline
 #else
-/* A lot of inline functions can cause havoc with function tracing */
-#define inline inline  __attribute__((unused)) notrace
-#define __inline__ __inline__  __attribute__((unused)) notrace
-#define __inline __inline  __attribute__((unused)) notrace
+#define inline inline  __attribute__((unused)) notrace __gnu_inline
 #endif
 
+#define __inline__ inline
+#define __inline inline
 #define __always_inlineinline __attribute__((always_inline))
 #define  noinline  __attribute__((noinline))
 


--
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.14 02/92] x86/asm: Add _ASM_ARG* constants for argument registers to

[Greg Kroah-Hartman]

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

--

From: H. Peter Anvin 

commit 0e2e160033283e20f688d8bad5b89460cc5bfcc4 upstream.

i386 and x86-64 uses different registers for arguments; make them
available so we don't have to #ifdef in the actual code.

Native size and specified size (q, l, w, b) versions are provided.

Signed-off-by: H. Peter Anvin 
Signed-off-by: Nick Desaulniers 
Reviewed-by: Sedat Dilek 
Acked-by: Juergen Gross 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: a...@redhat.com
Cc: akata...@vmware.com
Cc: a...@linux-foundation.org
Cc: andrea.pa...@amarulasolutions.com
Cc: ard.biesheu...@linaro.org
Cc: a...@arndb.de
Cc: aryabi...@virtuozzo.com
Cc: astrac...@google.com
Cc: boris.ostrov...@oracle.com
Cc: brijesh.si...@amd.com
Cc: caoj.f...@cn.fujitsu.com
Cc: ge...@linux-m68k.org
Cc: ghackm...@google.com
Cc: gre...@linuxfoundation.org
Cc: jan.kis...@siemens.com
Cc: jarkko.sakki...@linux.intel.com
Cc: j...@perches.com
Cc: jpoim...@redhat.com
Cc: keesc...@google.com
Cc: kirill.shute...@linux.intel.com
Cc: kstew...@linuxfoundation.org
Cc: linux-efi@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: manojgu...@google.com
Cc: mawil...@microsoft.com
Cc: michal.l...@markovi.net
Cc: mj...@google.com
Cc: m...@chromium.org
Cc: pombreda...@nexb.com
Cc: rient...@google.com
Cc: rost...@goodmis.org
Cc: thomas.lenda...@amd.com
Cc: tstel...@redhat.com
Cc: tw...@google.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: will.dea...@arm.com
Cc: yamada.masah...@socionext.com
Link: http://lkml.kernel.org/r/20180621162324.36656-3-ndesaulni...@google.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/asm.h |   59 +
 1 file changed, 59 insertions(+)

--- a/arch/x86/include/asm/asm.h
+++ b/arch/x86/include/asm/asm.h
@@ -46,6 +46,65 @@
 #define _ASM_SI__ASM_REG(si)
 #define _ASM_DI__ASM_REG(di)
 
+#ifndef __x86_64__
+/* 32 bit */
+
+#define _ASM_ARG1  _ASM_AX
+#define _ASM_ARG2  _ASM_DX
+#define _ASM_ARG3  _ASM_CX
+
+#define _ASM_ARG1L eax
+#define _ASM_ARG2L edx
+#define _ASM_ARG3L ecx
+
+#define _ASM_ARG1W ax
+#define _ASM_ARG2W dx
+#define _ASM_ARG3W cx
+
+#define _ASM_ARG1B al
+#define _ASM_ARG2B dl
+#define _ASM_ARG3B cl
+
+#else
+/* 64 bit */
+
+#define _ASM_ARG1  _ASM_DI
+#define _ASM_ARG2  _ASM_SI
+#define _ASM_ARG3  _ASM_DX
+#define _ASM_ARG4  _ASM_CX
+#define _ASM_ARG5  r8
+#define _ASM_ARG6  r9
+
+#define _ASM_ARG1Q rdi
+#define _ASM_ARG2Q rsi
+#define _ASM_ARG3Q rdx
+#define _ASM_ARG4Q rcx
+#define _ASM_ARG5Q r8
+#define _ASM_ARG6Q r9
+
+#define _ASM_ARG1L edi
+#define _ASM_ARG2L esi
+#define _ASM_ARG3L edx
+#define _ASM_ARG4L ecx
+#define _ASM_ARG5L r8d
+#define _ASM_ARG6L r9d
+
+#define _ASM_ARG1W di
+#define _ASM_ARG2W si
+#define _ASM_ARG3W dx
+#define _ASM_ARG4W cx
+#define _ASM_ARG5W r8w
+#define _ASM_ARG6W r9w
+
+#define _ASM_ARG1B dil
+#define _ASM_ARG2B sil
+#define _ASM_ARG3B dl
+#define _ASM_ARG4B cl
+#define _ASM_ARG5B r8b
+#define _ASM_ARG6B r9b
+
+#endif
+
 /*
  * Macros to generate condition code outputs from inline assembly,
  * The output operand must be type "bool".


--
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 07/66] x86/paravirt: Make native_save_fl() extern inline

[Greg Kroah-Hartman]

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

--

From: Nick Desaulniers 

commit d0a8d9378d16eb3c69bd8e6d23779fbdbee3a8c7 upstream.

native_save_fl() is marked static inline, but by using it as
a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined.

paravirt's use of native_save_fl() also requires that no GPRs other than
%rax are clobbered.

Compilers have different heuristics which they use to emit stack guard
code, the emittance of which can break paravirt's callee saved assumption
by clobbering %rcx.

Marking a function definition extern inline means that if this version
cannot be inlined, then the out-of-line version will be preferred. By
having the out-of-line version be implemented in assembly, it cannot be
instrumented with a stack protector, which might violate custom calling
conventions that code like paravirt rely on.

The semantics of extern inline has changed since gnu89. This means that
folks using GCC versions >= 5.1 may see symbol redefinition errors at
link time for subdirs that override KBUILD_CFLAGS (making the C standard
used implicit) regardless of this patch. This has been cleaned up
earlier in the patch set, but is left as a note in the commit message
for future travelers.

Reports:
 https://lkml.org/lkml/2018/5/7/534
 https://github.com/ClangBuiltLinux/linux/issues/16

Discussion:
 https://bugs.llvm.org/show_bug.cgi?id=37512
 https://lkml.org/lkml/2018/5/24/1371

Thanks to the many folks that participated in the discussion.

Debugged-by: Alistair Strachan 
Debugged-by: Matthias Kaehlcke 
Suggested-by: Arnd Bergmann 
Suggested-by: H. Peter Anvin 
Suggested-by: Tom Stellar 
Reported-by: Sedat Dilek 
Tested-by: Sedat Dilek 
Signed-off-by: Nick Desaulniers 
Acked-by: Juergen Gross 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: a...@redhat.com
Cc: akata...@vmware.com
Cc: a...@linux-foundation.org
Cc: andrea.pa...@amarulasolutions.com
Cc: ard.biesheu...@linaro.org
Cc: aryabi...@virtuozzo.com
Cc: astrac...@google.com
Cc: boris.ostrov...@oracle.com
Cc: brijesh.si...@amd.com
Cc: caoj.f...@cn.fujitsu.com
Cc: ge...@linux-m68k.org
Cc: ghackm...@google.com
Cc: gre...@linuxfoundation.org
Cc: jan.kis...@siemens.com
Cc: jarkko.sakki...@linux.intel.com
Cc: j...@perches.com
Cc: jpoim...@redhat.com
Cc: keesc...@google.com
Cc: kirill.shute...@linux.intel.com
Cc: kstew...@linuxfoundation.org
Cc: linux-efi@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: manojgu...@google.com
Cc: mawil...@microsoft.com
Cc: michal.l...@markovi.net
Cc: mj...@google.com
Cc: m...@chromium.org
Cc: pombreda...@nexb.com
Cc: rient...@google.com
Cc: rost...@goodmis.org
Cc: thomas.lenda...@amd.com
Cc: tw...@google.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: will.dea...@arm.com
Cc: yamada.masah...@socionext.com
Link: http://lkml.kernel.org/r/20180621162324.36656-4-ndesaulni...@google.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/irqflags.h |2 +-
 arch/x86/kernel/Makefile|1 +
 arch/x86/kernel/irqflags.S  |   26 ++
 3 files changed, 28 insertions(+), 1 deletion(-)

--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -12,7 +12,7 @@
  * Interrupt control:
  */
 
-static inline unsigned long native_save_fl(void)
+extern inline unsigned long native_save_fl(void)
 {
unsigned long flags;
 
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -56,6 +56,7 @@ obj-y += alternative.o i8253.o pci-nom
 obj-y  += tsc.o tsc_msr.o io_delay.o rtc.o
 obj-y  += pci-iommu_table.o
 obj-y  += resource.o
+obj-y  += irqflags.o
 
 obj-y  += process.o
 obj-y  += fpu/
--- /dev/null
+++ b/arch/x86/kernel/irqflags.S
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include 
+#include 
+#include 
+
+/*
+ * unsigned long native_save_fl(void)
+ */
+ENTRY(native_save_fl)
+   pushf
+   pop %_ASM_AX
+   ret
+ENDPROC(native_save_fl)
+EXPORT_SYMBOL(native_save_fl)
+
+/*
+ * void native_restore_fl(unsigned long flags)
+ * %eax/%rdi: flags
+ */
+ENTRY(native_restore_fl)
+   push %_ASM_ARG1
+   popf
+   ret
+ENDPROC(native_restore_fl)
+EXPORT_SYMBOL(native_restore_fl)


--
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.4 04/31] compiler-gcc.h: Add __attribute__((gnu_inline)) to all inline declarations

[Greg Kroah-Hartman]

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

--

From: Nick Desaulniers 

commit d03db2bc26f0e4a6849ad649a09c9c73fccdc656 upstream.

Functions marked extern inline do not emit an externally visible
function when the gnu89 C standard is used. Some KBUILD Makefiles
overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without
an explicit C standard specified, the default is gnu11. Since c99, the
semantics of extern inline have changed such that an externally visible
function is always emitted. This can lead to multiple definition errors
of extern inline functions at link time of compilation units whose build
files have removed an explicit C standard compiler flag for users of GCC
5.1+ or Clang.

Suggested-by: Arnd Bergmann 
Suggested-by: H. Peter Anvin 
Suggested-by: Joe Perches 
Signed-off-by: Nick Desaulniers 
Acked-by: Juergen Gross 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: a...@redhat.com
Cc: akata...@vmware.com
Cc: a...@linux-foundation.org
Cc: andrea.pa...@amarulasolutions.com
Cc: ard.biesheu...@linaro.org
Cc: aryabi...@virtuozzo.com
Cc: astrac...@google.com
Cc: boris.ostrov...@oracle.com
Cc: brijesh.si...@amd.com
Cc: caoj.f...@cn.fujitsu.com
Cc: ge...@linux-m68k.org
Cc: ghackm...@google.com
Cc: gre...@linuxfoundation.org
Cc: jan.kis...@siemens.com
Cc: jarkko.sakki...@linux.intel.com
Cc: jpoim...@redhat.com
Cc: keesc...@google.com
Cc: kirill.shute...@linux.intel.com
Cc: kstew...@linuxfoundation.org
Cc: linux-efi@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: manojgu...@google.com
Cc: mawil...@microsoft.com
Cc: michal.l...@markovi.net
Cc: mj...@google.com
Cc: m...@chromium.org
Cc: pombreda...@nexb.com
Cc: rient...@google.com
Cc: rost...@goodmis.org
Cc: sedat.di...@gmail.com
Cc: thomas.lenda...@amd.com
Cc: tstel...@redhat.com
Cc: tw...@google.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: will.dea...@arm.com
Cc: yamada.masah...@socionext.com
Link: http://lkml.kernel.org/r/20180621162324.36656-2-ndesaulni...@google.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/compiler-gcc.h |   29 ++---
 1 file changed, 22 insertions(+), 7 deletions(-)

--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -65,25 +65,40 @@
 #endif
 
 /*
+ * Feature detection for gnu_inline (gnu89 extern inline semantics). Either
+ * __GNUC_STDC_INLINE__ is defined (not using gnu89 extern inline semantics,
+ * and we opt in to the gnu89 semantics), or __GNUC_STDC_INLINE__ is not
+ * defined so the gnu89 semantics are the default.
+ */
+#ifdef __GNUC_STDC_INLINE__
+# define __gnu_inline  __attribute__((gnu_inline))
+#else
+# define __gnu_inline
+#endif
+
+/*
  * Force always-inline if the user requests it so via the .config,
  * or if gcc is too old.
  * GCC does not warn about unused static inline functions for
  * -Wunused-function.  This turns out to avoid the need for complex #ifdef
  * directives.  Suppress the warning in clang as well by using "unused"
  * function attribute, which is redundant but not harmful for gcc.
+ * Prefer gnu_inline, so that extern inline functions do not emit an
+ * externally visible function. This makes extern inline behave as per gnu89
+ * semantics rather than c99. This prevents multiple symbol definition errors
+ * of extern inline functions at link time.
+ * A lot of inline functions can cause havoc with function tracing.
  */
 #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) ||   \
 !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
-#define inline inline  __attribute__((always_inline,unused)) notrace
-#define __inline__ __inline__  __attribute__((always_inline,unused)) notrace
-#define __inline __inline  __attribute__((always_inline,unused)) notrace
+#define inline \
+   inline __attribute__((always_inline, unused)) notrace __gnu_inline
 #else
-/* A lot of inline functions can cause havoc with function tracing */
-#define inline inline  __attribute__((unused)) notrace
-#define __inline__ __inline__  __attribute__((unused)) notrace
-#define __inline __inline  __attribute__((unused)) notrace
+#define inline inline  __attribute__((unused)) notrace __gnu_inline
 #endif
 
+#define __inline__ inline
+#define __inline inline
 #define __always_inlineinline __attribute__((always_inline))
 #define  noinline  __attribute__((noinline))
 


--
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.17 083/220] efi/libstub/tpm: Initialize efi_physical_addr_t vars to zero for mixed mode

[Greg Kroah-Hartman]

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

--

From: Hans de Goede 

commit 52e1cf2d19c2e62e6a81b8de3f7320d033917dd5 upstream.

Commit:

  79832f0b5f71 ("efi/libstub/tpm: Initialize pointer variables to zero for 
mixed mode")

fixes a problem with the tpm code on mixed mode (64-bit kernel on 32-bit UEFI),
where 64-bit pointer variables are not fully initialized by the 32-bit EFI code.

A similar problem applies to the efi_physical_addr_t variables which
are written by the ->get_event_log() EFI call. Even though efi_physical_addr_t
is 64-bit everywhere, it seems that some 32-bit UEFI implementations only
fill in the lower 32 bits when passed a pointer to an efi_physical_addr_t
to fill.

This commit initializes these to 0 to, to ensure the upper 32 bits are
0 in mixed mode. This fixes recent kernels sometimes hanging during
early boot on mixed mode UEFI systems.

Signed-off-by: Hans de Goede 
Signed-off-by: Ard Biesheuvel 
Cc:  # v4.16+
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180622064222.11633-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

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

--- a/drivers/firmware/efi/libstub/tpm.c
+++ b/drivers/firmware/efi/libstub/tpm.c
@@ -64,7 +64,7 @@ void efi_retrieve_tpm2_eventlog_1_2(efi_
efi_guid_t tcg2_guid = EFI_TCG2_PROTOCOL_GUID;
efi_guid_t linux_eventlog_guid = LINUX_EFI_TPM_EVENT_LOG_GUID;
efi_status_t status;
-   efi_physical_addr_t log_location, log_last_entry;
+   efi_physical_addr_t log_location = 0, log_last_entry = 0;
struct linux_efi_tpm_eventlog *log_tbl = NULL;
unsigned long first_entry_addr, last_entry_addr;
size_t log_size, last_entry_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.16 274/279] efi/libstub/arm64: Handle randomized TEXT_OFFSET

[Greg Kroah-Hartman]

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

--

From: Mark Rutland 

[ Upstream commit 4f74d72aa7067e75af92fbab077e6d7d0210be66 ]

When CONFIG_RANDOMIZE_TEXT_OFFSET=y, TEXT_OFFSET is an arbitrary
multiple of PAGE_SIZE in the interval [0, 2MB).

The EFI stub does not account for the potential misalignment of
TEXT_OFFSET relative to EFI_KIMG_ALIGN, and produces a randomized
physical offset which is always a round multiple of EFI_KIMG_ALIGN.
This may result in statically allocated objects whose alignment exceeds
PAGE_SIZE to appear misaligned in memory. This has been observed to
result in spurious stack overflow reports and failure to make use of
the IRQ stacks, and theoretically could result in a number of other
issues.

We can OR in the low bits of TEXT_OFFSET to ensure that we have the
necessary offset (and hence preserve the misalignment of TEXT_OFFSET
relative to EFI_KIMG_ALIGN), so let's do that.

Reported-by: Kim Phillips 
Tested-by: Kim Phillips 
[ardb: clarify comment and commit log, drop unneeded parens]
Signed-off-by: Mark Rutland 
Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 6f26b3671184c36d ("arm64: kaslr: increase randomization granularity")
Link: http://lkml.kernel.org/r/20180518140841.9731-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/firmware/efi/libstub/arm64-stub.c |   10 ++
 1 file changed, 10 insertions(+)

--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@ -98,6 +98,16 @@ efi_status_t handle_kernel_image(efi_sys
 (phys_seed >> 32) & mask : TEXT_OFFSET;
 
/*
+* With CONFIG_RANDOMIZE_TEXT_OFFSET=y, TEXT_OFFSET may not
+* be a multiple of EFI_KIMG_ALIGN, and we must ensure that
+* we preserve the misalignment of 'offset' relative to
+* EFI_KIMG_ALIGN so that statically allocated objects whose
+* alignment exceeds PAGE_SIZE appear correctly aligned in
+* memory.
+*/
+   offset |= TEXT_OFFSET % EFI_KIMG_ALIGN;
+
+   /*
 * If KASLR is enabled, and we have some randomness available,
 * locate the kernel at a randomized offset in physical memory.
 */


--
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.14 345/496] x86/mm: Fix bogus warning during EFI bootup, use boot_cpu_has() instead of this_cpu_has() in build_cr3_noflush()

[Greg Kroah-Hartman]

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

--

From: Sai Praneeth <sai.praneeth.prak...@intel.com>

[ Upstream commit 162ee5a8ab49be40d253f90e94aef712470a3a24 ]

Linus reported the following boot warning:

  WARNING: CPU: 0 PID: 0 at arch/x86/include/asm/tlbflush.h:134 
load_new_mm_cr3+0x114/0x170
  [...]
  Call Trace:
  switch_mm_irqs_off+0x267/0x590
  switch_mm+0xe/0x20
  efi_switch_mm+0x3e/0x50
  efi_enter_virtual_mode+0x43f/0x4da
  start_kernel+0x3bf/0x458
  secondary_startup_64+0xa5/0xb0

... after merging:

  03781e40890c: x86/efi: Use efi_switch_mm() rather than manually twiddling 
with %cr3

When the platform supports PCID and if CONFIG_DEBUG_VM=y is enabled,
build_cr3_noflush() (called via switch_mm()) does a sanity check to see
if X86_FEATURE_PCID is set.

Presently, build_cr3_noflush() uses "this_cpu_has(X86_FEATURE_PCID)" to
perform the check but this_cpu_has() works only after SMP is initialized
(i.e. per cpu cpu_info's should be populated) and this happens to be very
late in the boot process (during rest_init()).

As efi_runtime_services() are called during (early) kernel boot time
and run time, modify build_cr3_noflush() to use boot_cpu_has() all the
time. As suggested by Dave Hansen, this should be OK because all CPU's have
same capabilities on x86.

With this change the warning is fixed.

( Dave also suggested that we put a warning in this_cpu_has() if it's used
  early in the boot process. This is still work in progress as it affects
  MCE. )

Reported-by: Linus Torvalds <torva...@linux-foundation.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Andy Lutomirski <l...@kernel.org>
Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
Cc: Borislav Petkov <b...@alien8.de>
Cc: Dave Hansen <dave.han...@intel.com>
Cc: Lee Chun-Yi <j...@suse.com>
Cc: Matt Fleming <m...@codeblueprint.co.uk>
Cc: Michael S. Tsirkin <m...@redhat.com>
Cc: Peter Zijlstra <a.p.zijls...@chello.nl>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Ravi Shankar <ravi.v.shan...@intel.com>
Cc: Ricardo Neri <ricardo.n...@intel.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Tony Luck <tony.l...@intel.com>
Cc: linux-efi@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1522870459-7432-1-git-send-email-sai.praneeth.prak...@intel.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 arch/x86/include/asm/tlbflush.h |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -131,7 +131,12 @@ static inline unsigned long build_cr3(pg
 static inline unsigned long build_cr3_noflush(pgd_t *pgd, u16 asid)
 {
VM_WARN_ON_ONCE(asid > MAX_ASID_AVAILABLE);
-   VM_WARN_ON_ONCE(!this_cpu_has(X86_FEATURE_PCID));
+   /*
+* Use boot_cpu_has() instead of this_cpu_has() as this function
+* might be called during early boot. This should work even after
+* boot because all CPU's the have same capabilities:
+*/
+   VM_WARN_ON_ONCE(!boot_cpu_has(X86_FEATURE_PCID));
return __sme_pa(pgd) | kern_pcid(asid) | CR3_NOFLUSH;
 }
 


--
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.14 431/496] efi/arm*: Only register page tables when they exist

[Greg Kroah-Hartman]

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

--

From: Mark Rutland <mark.rutl...@arm.com>

[ Upstream commit 6b31a2fa1e8f7bc6c2a474b4a12dad7a145cf83d ]

Currently the arm/arm64 runtime code registers the runtime servies
pagetables with ptdump regardless of whether runtime services page
tables have been created.

As efi_mm.pgd is NULL in these cases, attempting to dump the efi page
tables results in a NULL pointer dereference in the ptdump code:

/sys/kernel/debug# cat efi_page_tables
[  479.522600] Unable to handle kernel NULL pointer dereference at virtual 
address 
[  479.522715] Mem abort info:
[  479.522764]   ESR = 0x9606
[  479.522850]   Exception class = DABT (current EL), IL = 32 bits
[  479.522899]   SET = 0, FnV = 0
[  479.522937]   EA = 0, S1PTW = 0
[  479.528200] Data abort info:
[  479.528230]   ISV = 0, ISS = 0x0006
[  479.528317]   CM = 0, WnR = 0
[  479.528317] user pgtable: 4k pages, 48-bit VAs, pgd = 64ab0cb0
[  479.528449] [] *pgd=fbbe4003, *pud=fb66e003, 
*pmd=
[  479.528600] Internal error: Oops: 9606 [#1] PREEMPT SMP
[  479.528664] Modules linked in:
[  479.528699] CPU: 0 PID: 2457 Comm: cat Not tainted 
4.15.0-rc3-00065-g2ad2ee7ecb5c-dirty #7
[  479.528799] Hardware name: FVP Base (DT)
[  479.528899] pstate: 0049 (nzcv daif +PAN -UAO)
[  479.528941] pc : walk_pgd.isra.1+0x20/0x1d0
[  479.529011] lr : ptdump_walk_pgd+0x30/0x50
[  479.529105] sp : 0bf4bc20
[  479.529185] x29: 0bf4bc20 x28: 9d22e000
[  479.529271] x27: 0002 x26: 80007b4c63c0
[  479.529358] x25: 014000c0 x24: 80007c098900
[  479.529445] x23: 0bf4beb8 x22: 
[  479.529532] x21: 0bf4bd70 x20: 0001
[  479.529618] x19: 0bf4bcb0 x18: 
[  479.529760] x17: 0041a1c8 x16: 082139d8
[  479.529800] x15: 9d3c6030 x14: 9d2527f4
[  479.529924] x13: 03f3 x12: 0038
[  479.53] x11: 0003 x10: 0101010101010101
[  479.530099] x9 : 17e94050 x8 : 003f
[  479.530226] x7 :  x6 : 
[  479.530313] x5 : 0001 x4 : 
[  479.530416] x3 : 09069fd8 x2 : 
[  479.530500] x1 :  x0 : 
[  479.530599] Process cat (pid: 2457, stack limit = 0x5d1b0e6f)
[  479.530660] Call trace:
[  479.530746]  walk_pgd.isra.1+0x20/0x1d0
[  479.530833]  ptdump_walk_pgd+0x30/0x50
[  479.530907]  ptdump_show+0x10/0x20
[  479.530920]  seq_read+0xc8/0x470
[  479.531023]  full_proxy_read+0x60/0x90
[  479.531100]  __vfs_read+0x18/0x100
[  479.531180]  vfs_read+0x88/0x160
[  479.531267]  SyS_read+0x48/0xb0
[  479.531299]  el0_svc_naked+0x20/0x24
[  479.531400] Code: 91400420 f90033a0 a90707a2 f9403fa0 (f940)
[  479.531499] ---[ end trace bfe8e28d8acb2b67 ]---
Segmentation fault

Let's avoid this problem by only registering the tables after their
successful creation, which is also less confusing when EFI runtime
services are not in use.

Reported-by: Will Deacon <will.dea...@arm.com>
Signed-off-by: Mark Rutland <mark.rutl...@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Acked-by: Will Deacon <will.dea...@arm.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Matt Fleming <m...@codeblueprint.co.uk>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180308080020.22828-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/firmware/efi/arm-runtime.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -54,6 +54,9 @@ static struct ptdump_info efi_ptdump_inf
 
 static int __init ptdump_init(void)
 {
+   if (!efi_enabled(EFI_RUNTIME_SERVICES))
+   return 0;
+
return ptdump_debugfs_register(_ptdump_info, "efi_page_tables");
 }
 device_initcall(ptdump_init);


--
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.16 078/272] x86/mm: Fix bogus warning during EFI bootup, use boot_cpu_has() instead of this_cpu_has() in build_cr3_noflush()

[Greg Kroah-Hartman]

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

--

From: Sai Praneeth <sai.praneeth.prak...@intel.com>

[ Upstream commit 162ee5a8ab49be40d253f90e94aef712470a3a24 ]

Linus reported the following boot warning:

  WARNING: CPU: 0 PID: 0 at arch/x86/include/asm/tlbflush.h:134 
load_new_mm_cr3+0x114/0x170
  [...]
  Call Trace:
  switch_mm_irqs_off+0x267/0x590
  switch_mm+0xe/0x20
  efi_switch_mm+0x3e/0x50
  efi_enter_virtual_mode+0x43f/0x4da
  start_kernel+0x3bf/0x458
  secondary_startup_64+0xa5/0xb0

... after merging:

  03781e40890c: x86/efi: Use efi_switch_mm() rather than manually twiddling 
with %cr3

When the platform supports PCID and if CONFIG_DEBUG_VM=y is enabled,
build_cr3_noflush() (called via switch_mm()) does a sanity check to see
if X86_FEATURE_PCID is set.

Presently, build_cr3_noflush() uses "this_cpu_has(X86_FEATURE_PCID)" to
perform the check but this_cpu_has() works only after SMP is initialized
(i.e. per cpu cpu_info's should be populated) and this happens to be very
late in the boot process (during rest_init()).

As efi_runtime_services() are called during (early) kernel boot time
and run time, modify build_cr3_noflush() to use boot_cpu_has() all the
time. As suggested by Dave Hansen, this should be OK because all CPU's have
same capabilities on x86.

With this change the warning is fixed.

( Dave also suggested that we put a warning in this_cpu_has() if it's used
  early in the boot process. This is still work in progress as it affects
  MCE. )

Reported-by: Linus Torvalds <torva...@linux-foundation.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Andy Lutomirski <l...@kernel.org>
Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
Cc: Borislav Petkov <b...@alien8.de>
Cc: Dave Hansen <dave.han...@intel.com>
Cc: Lee Chun-Yi <j...@suse.com>
Cc: Matt Fleming <m...@codeblueprint.co.uk>
Cc: Michael S. Tsirkin <m...@redhat.com>
Cc: Peter Zijlstra <a.p.zijls...@chello.nl>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Ravi Shankar <ravi.v.shan...@intel.com>
Cc: Ricardo Neri <ricardo.n...@intel.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Tony Luck <tony.l...@intel.com>
Cc: linux-efi@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1522870459-7432-1-git-send-email-sai.praneeth.prak...@intel.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 arch/x86/include/asm/tlbflush.h |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -131,7 +131,12 @@ static inline unsigned long build_cr3(pg
 static inline unsigned long build_cr3_noflush(pgd_t *pgd, u16 asid)
 {
VM_WARN_ON_ONCE(asid > MAX_ASID_AVAILABLE);
-   VM_WARN_ON_ONCE(!this_cpu_has(X86_FEATURE_PCID));
+   /*
+* Use boot_cpu_has() instead of this_cpu_has() as this function
+* might be called during early boot. This should work even after
+* boot because all CPU's the have same capabilities:
+*/
+   VM_WARN_ON_ONCE(!boot_cpu_has(X86_FEATURE_PCID));
return __sme_pa(pgd) | kern_pcid(asid) | CR3_NOFLUSH;
 }
 


--
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.16 191/272] efi/arm*: Only register page tables when they exist

[Greg Kroah-Hartman]

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

--

From: Mark Rutland <mark.rutl...@arm.com>

[ Upstream commit 6b31a2fa1e8f7bc6c2a474b4a12dad7a145cf83d ]

Currently the arm/arm64 runtime code registers the runtime servies
pagetables with ptdump regardless of whether runtime services page
tables have been created.

As efi_mm.pgd is NULL in these cases, attempting to dump the efi page
tables results in a NULL pointer dereference in the ptdump code:

/sys/kernel/debug# cat efi_page_tables
[  479.522600] Unable to handle kernel NULL pointer dereference at virtual 
address 
[  479.522715] Mem abort info:
[  479.522764]   ESR = 0x9606
[  479.522850]   Exception class = DABT (current EL), IL = 32 bits
[  479.522899]   SET = 0, FnV = 0
[  479.522937]   EA = 0, S1PTW = 0
[  479.528200] Data abort info:
[  479.528230]   ISV = 0, ISS = 0x0006
[  479.528317]   CM = 0, WnR = 0
[  479.528317] user pgtable: 4k pages, 48-bit VAs, pgd = 64ab0cb0
[  479.528449] [] *pgd=fbbe4003, *pud=fb66e003, 
*pmd=
[  479.528600] Internal error: Oops: 9606 [#1] PREEMPT SMP
[  479.528664] Modules linked in:
[  479.528699] CPU: 0 PID: 2457 Comm: cat Not tainted 
4.15.0-rc3-00065-g2ad2ee7ecb5c-dirty #7
[  479.528799] Hardware name: FVP Base (DT)
[  479.528899] pstate: 0049 (nzcv daif +PAN -UAO)
[  479.528941] pc : walk_pgd.isra.1+0x20/0x1d0
[  479.529011] lr : ptdump_walk_pgd+0x30/0x50
[  479.529105] sp : 0bf4bc20
[  479.529185] x29: 0bf4bc20 x28: 9d22e000
[  479.529271] x27: 0002 x26: 80007b4c63c0
[  479.529358] x25: 014000c0 x24: 80007c098900
[  479.529445] x23: 0bf4beb8 x22: 
[  479.529532] x21: 0bf4bd70 x20: 0001
[  479.529618] x19: 0bf4bcb0 x18: 
[  479.529760] x17: 0041a1c8 x16: 082139d8
[  479.529800] x15: 9d3c6030 x14: 9d2527f4
[  479.529924] x13: 03f3 x12: 0038
[  479.53] x11: 0003 x10: 0101010101010101
[  479.530099] x9 : 17e94050 x8 : 003f
[  479.530226] x7 :  x6 : 
[  479.530313] x5 : 0001 x4 : 
[  479.530416] x3 : 09069fd8 x2 : 
[  479.530500] x1 :  x0 : 
[  479.530599] Process cat (pid: 2457, stack limit = 0x5d1b0e6f)
[  479.530660] Call trace:
[  479.530746]  walk_pgd.isra.1+0x20/0x1d0
[  479.530833]  ptdump_walk_pgd+0x30/0x50
[  479.530907]  ptdump_show+0x10/0x20
[  479.530920]  seq_read+0xc8/0x470
[  479.531023]  full_proxy_read+0x60/0x90
[  479.531100]  __vfs_read+0x18/0x100
[  479.531180]  vfs_read+0x88/0x160
[  479.531267]  SyS_read+0x48/0xb0
[  479.531299]  el0_svc_naked+0x20/0x24
[  479.531400] Code: 91400420 f90033a0 a90707a2 f9403fa0 (f940)
[  479.531499] ---[ end trace bfe8e28d8acb2b67 ]---
Segmentation fault

Let's avoid this problem by only registering the tables after their
successful creation, which is also less confusing when EFI runtime
services are not in use.

Reported-by: Will Deacon <will.dea...@arm.com>
Signed-off-by: Mark Rutland <mark.rutl...@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Acked-by: Will Deacon <will.dea...@arm.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Matt Fleming <m...@codeblueprint.co.uk>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180308080020.22828-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/firmware/efi/arm-runtime.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -54,6 +54,9 @@ static struct ptdump_info efi_ptdump_inf
 
 static int __init ptdump_init(void)
 {
+   if (!efi_enabled(EFI_RUNTIME_SERVICES))
+   return 0;
+
return ptdump_debugfs_register(_ptdump_info, "efi_page_tables");
 }
 device_initcall(ptdump_init);


--
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 3.18 34/45] efi: Avoid potential crashes, fix the struct efi_pci_io_protocol_32 definition for mixed mode

[Greg Kroah-Hartman]

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

--

From: Ard Biesheuvel <ard.biesheu...@linaro.org>

commit 0b3225ab9407f557a8e20f23f37aa7236c10a9b1 upstream.

Mixed mode allows a kernel built for x86_64 to interact with 32-bit
EFI firmware, but requires us to define all struct definitions carefully
when it comes to pointer sizes.

'struct efi_pci_io_protocol_32' currently uses a 'void *' for the
'romimage' field, which will be interpreted as a 64-bit field
on such kernels, potentially resulting in bogus memory references
and subsequent crashes.

Tested-by: Hans de Goede <hdego...@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Cc: <sta...@vger.kernel.org>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Matt Fleming <m...@codeblueprint.co.uk>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180504060003.19618-13-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
 arch/x86/boot/compressed/eboot.c |6 --
 include/linux/efi.h  |8 
 2 files changed, 8 insertions(+), 6 deletions(-)

--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -365,7 +365,8 @@ __setup_efi_pci32(efi_pci_io_protocol_32
if (status != EFI_SUCCESS)
goto free_struct;
 
-   memcpy(rom->romdata, pci->romimage, pci->romsize);
+   memcpy(rom->romdata, (void *)(unsigned long)pci->romimage,
+  pci->romsize);
return status;
 
 free_struct:
@@ -471,7 +472,8 @@ __setup_efi_pci64(efi_pci_io_protocol_64
if (status != EFI_SUCCESS)
goto free_struct;
 
-   memcpy(rom->romdata, pci->romimage, pci->romsize);
+   memcpy(rom->romdata, (void *)(unsigned long)pci->romimage,
+  pci->romsize);
return status;
 
 free_struct:
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -360,8 +360,8 @@ typedef struct {
u32 attributes;
u32 get_bar_attributes;
u32 set_bar_attributes;
-   uint64_t romsize;
-   void *romimage;
+   u64 romsize;
+   u32 romimage;
 } efi_pci_io_protocol_32;
 
 typedef struct {
@@ -380,8 +380,8 @@ typedef struct {
u64 attributes;
u64 get_bar_attributes;
u64 set_bar_attributes;
-   uint64_t romsize;
-   void *romimage;
+   u64 romsize;
+   u64 romimage;
 } efi_pci_io_protocol_64;
 
 typedef struct {


--
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