Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1715397 > unrolled thread

[GIT PULL 00/14] EFI changes for v4.14

Started byArd Biesheuvel <ard.biesheuvel@linaro.org>
First post2017-08-18 22:00 +0200
Last post2017-08-21 11:40 +0200
Articles 20 on this page of 30 — 5 participants

Back to article view | Back to linux.kernel


Contents

  [GIT PULL 00/14] EFI changes for v4.14 Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-08-18 22:00 +0200
    [PATCH 03/14] efi/libstub: arm64: force 'hidden' visibility for section markers Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-08-18 22:00 +0200
      [tip:efi/core] efi/libstub/arm64: Force 'hidden' visibility for  section markers tip-bot for Ard Biesheuvel <tipbot@zytor.com> - 2017-08-21 11:30 +0200
    [PATCH 05/14] efi: arm/arm64: Add missing assignment of efi.config_table Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-08-18 22:00 +0200
      [tip:efi/core] efi/arm/arm64: Add missing assignment of  efi.config_table tip-bot for Ard Biesheuvel <tipbot@zytor.com> - 2017-08-21 11:30 +0200
    [PATCH 01/14] efi: arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-08-18 22:00 +0200
      [tip:efi/core] efi/arm: Don't mark ACPI reclaim memory as  MEMBLOCK_NOMAP tip-bot for Ard Biesheuvel <tipbot@zytor.com> - 2017-08-21 11:30 +0200
    [PATCH 06/14] efi/reboot: Fall back to original power-off method if EFI_RESET_SHUTDOWN returns Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-08-18 22:00 +0200
      [tip:efi/core] efi/reboot: Fall back to original power-off method  if EFI_RESET_SHUTDOWN returns tip-bot for Hans de Goede <tipbot@zytor.com> - 2017-08-21 11:30 +0200
    [PATCH 04/14] efi/libstub: arm64: set -fpie when building the EFI stub Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-08-18 22:00 +0200
      [tip:efi/core] efi/libstub/arm64: Set -fpie when building the EFI  stub tip-bot for Ard Biesheuvel <tipbot@zytor.com> - 2017-08-21 11:30 +0200
    [PATCH 09/14] arm: efi: remove pointless dummy .reloc section Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-08-18 22:00 +0200
      [tip:efi/core] arm/efi: Remove pointless dummy .reloc section tip-bot for Ard Biesheuvel <tipbot@zytor.com> - 2017-08-21 11:30 +0200
    [PATCH 07/14] drivers/fbdev: efifb: allow BAR to be moved instead of claiming it Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-08-18 22:00 +0200
      [tip:efi/core] drivers/fbdev/efifb: Allow BAR to be moved instead  of claiming it tip-bot for Ard Biesheuvel <tipbot@zytor.com> - 2017-08-21 11:30 +0200
    [PATCH 11/14] arm: efi: split zImage code and data into separate PE/COFF sections Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-08-18 22:00 +0200
      [tip:efi/core] arm/efi: Split zImage code and data into separate  PE/COFF sections tip-bot for Ard Biesheuvel <tipbot@zytor.com> - 2017-08-21 11:30 +0200
    [PATCH 02/14] efi/libstub: arm64: use hidden attribute for struct screen_info reference Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-08-18 22:00 +0200
      [tip:efi/core] efi/libstub/arm64: Use hidden attribute for struct  screen_info reference tip-bot for Ard Biesheuvel <tipbot@zytor.com> - 2017-08-21 11:30 +0200
    [PATCH 12/14] firmware: dcdbas: constify attribute_group structures. Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-08-18 22:00 +0200
      [tip:efi/core] firmware/dcdbas: Constify attribute_group structures tip-bot for Arvind Yadav <tipbot@zytor.com> - 2017-08-21 11:40 +0200
    [PATCH 13/14] firmware: efi: constify attribute_group structures. Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-08-18 22:00 +0200
      [tip:efi/core] firmware/efi: Constify attribute_group structures tip-bot for Arvind Yadav <tipbot@zytor.com> - 2017-08-21 11:30 +0200
    [PATCH 14/14] firmware: efi: esrt: constify attribute_group structures. Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-08-18 22:00 +0200
      [tip:efi/core] firmware/efi/esrt: Constify attribute_group  structures tip-bot for Arvind Yadav <tipbot@zytor.com> - 2017-08-21 11:30 +0200
    [PATCH 10/14] arm: efi: replace open coded constants with symbolic ones Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-08-18 22:00 +0200
      [tip:efi/core] arm/efi: Replace open coded constants with symbolic  ones tip-bot for Ard Biesheuvel <tipbot@zytor.com> - 2017-08-21 11:30 +0200
    [PATCH 08/14] arm: efi: remove forbidden values from the PE/COFF header Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-08-18 22:00 +0200
      [tip:efi/core] arm/efi: Remove forbidden values from the PE/COFF  header tip-bot for Ard Biesheuvel <tipbot@zytor.com> - 2017-08-21 11:30 +0200
    Re: [GIT PULL 00/14] EFI changes for v4.14 Ingo Molnar <mingo@kernel.org> - 2017-08-21 11:40 +0200

Page 1 of 2  [1] 2  Next page →


#1715397 — [GIT PULL 00/14] EFI changes for v4.14

FromArd Biesheuvel <ard.biesheuvel@linaro.org>
Date2017-08-18 22:00 +0200
Subject[GIT PULL 00/14] EFI changes for v4.14
Message-ID<ufVB0-89n-3@gated-at.bofh.it>
Hi all,

These are the changes we have queued up in the EFI tree for v4.14. Please
pull.

Russell has been cc'ed twice on the patches that touch the linker script
of the ARM decompressor, and has elected not to respond, so I assume he
has no objections.

The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877:

  Linux v4.13-rc1 (2017-07-15 15:22:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-next

for you to fetch changes up to f6a3116a8881cff8543e1cf028dea6955831ec30:

  firmware: efi: esrt: constify attribute_group structures. (2017-08-18 19:55:50 +0100)

----------------------------------------------------------------
EFI changes for v4.14:
- don't mark ACPI reclaim regions as NOMAP on ARM
- update the compiler flags for the arm64 version of the EFI stub so that
  we can be confident that no absolute relocations are emitted, even when
  using clang
- update the EFI framebuffer address if points to a BAR that gets moved
  by the PCI resource allocation code
- fallback to other poweroff method if EFI poweroff fails (and returns)
- use separate PE/COFF section headers for the RX and RW parts of the ARM
  stub loader so that the firmware can use strict mapping permissions
- constify some struct attribute_group instances

----------------------------------------------------------------
Ard Biesheuvel (10):
      efi: arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP
      efi/libstub: arm64: use hidden attribute for struct screen_info reference
      efi/libstub: arm64: force 'hidden' visibility for section markers
      efi/libstub: arm64: set -fpie when building the EFI stub
      efi: arm/arm64: Add missing assignment of efi.config_table
      drivers/fbdev: efifb: allow BAR to be moved instead of claiming it
      arm: efi: remove forbidden values from the PE/COFF header
      arm: efi: remove pointless dummy .reloc section
      arm: efi: replace open coded constants with symbolic ones
      arm: efi: split zImage code and data into separate PE/COFF sections

Arvind Yadav (3):
      firmware: dcdbas: constify attribute_group structures.
      firmware: efi: constify attribute_group structures.
      firmware: efi: esrt: constify attribute_group structures.

Hans de Goede (1):
      efi/reboot: Fall back to original power-off method if EFI_RESET_SHUTDOWN returns

 arch/arm/boot/compressed/efi-header.S     | 160 +++++++++++++++---------------
 arch/arm/boot/compressed/vmlinux.lds.S    |  30 ++++--
 arch/arm64/include/asm/efi.h              |   3 +
 drivers/firmware/dcdbas.c                 |   2 +-
 drivers/firmware/efi/arm-init.c           |   8 ++
 drivers/firmware/efi/efi.c                |   2 +-
 drivers/firmware/efi/esrt.c               |   2 +-
 drivers/firmware/efi/libstub/Makefile     |   2 +-
 drivers/firmware/efi/libstub/arm64-stub.c |  10 +-
 drivers/firmware/efi/reboot.c             |  12 ++-
 drivers/video/fbdev/efifb.c               |  31 +++---
 11 files changed, 158 insertions(+), 104 deletions(-)

[toc] | [next] | [standalone]


#1715399 — [PATCH 03/14] efi/libstub: arm64: force 'hidden' visibility for section markers

FromArd Biesheuvel <ard.biesheuvel@linaro.org>
Date2017-08-18 22:00 +0200
Subject[PATCH 03/14] efi/libstub: arm64: force 'hidden' visibility for section markers
Message-ID<ufVB0-89n-5@gated-at.bofh.it>
In reply to#1715397
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

Cc: Matt Fleming <matt@codeblueprint.co.uk>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 drivers/firmware/efi/libstub/arm64-stub.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c
index b4c2589d7c91..f7a6970e9abc 100644
--- 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 <asm/sections.h>
+#pragma GCC visibility pop
+
 #include <linux/efi.h>
 #include <asm/efi.h>
-#include <asm/sections.h>
 #include <asm/sysreg.h>
 
 #include "efistub.h"
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]


#1716236 — [tip:efi/core] efi/libstub/arm64: Force 'hidden' visibility for section markers

Fromtip-bot for Ard Biesheuvel <tipbot@zytor.com>
Date2017-08-21 11:30 +0200
Subject[tip:efi/core] efi/libstub/arm64: Force 'hidden' visibility for section markers
Message-ID<ugRbZ-2zH-37@gated-at.bofh.it>
In reply to#1715399
Commit-ID:  0426a4e68f18d75515414361de9e3e1445d2644e
Gitweb:     http://git.kernel.org/tip/0426a4e68f18d75515414361de9e3e1445d2644e
Author:     Ard Biesheuvel <ard.biesheuvel@linaro.org>
AuthorDate: Fri, 18 Aug 2017 20:49:36 +0100
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 21 Aug 2017 09:43:49 +0200

efi/libstub/arm64: Force 'hidden' visibility for section markers

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 <mka@chromium.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20170818194947.19347-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 drivers/firmware/efi/libstub/arm64-stub.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c
index b4c2589..f7a6970 100644
--- 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 <asm/sections.h>
+#pragma GCC visibility pop
+
 #include <linux/efi.h>
 #include <asm/efi.h>
-#include <asm/sections.h>
 #include <asm/sysreg.h>
 
 #include "efistub.h"

[toc] | [prev] | [next] | [standalone]


#1715401 — [PATCH 05/14] efi: arm/arm64: Add missing assignment of efi.config_table

FromArd Biesheuvel <ard.biesheuvel@linaro.org>
Date2017-08-18 22:00 +0200
Subject[PATCH 05/14] efi: arm/arm64: Add missing assignment of efi.config_table
Message-ID<ufVB0-89n-9@gated-at.bofh.it>
In reply to#1715397
The ARM EFI init code never assigns the config_table member of the
efi struct, which means the sysfs device node is missing, and other
in-kernel users will not work correctly. So add the missing assignment.

Note that, for now, the runtime and fw_vendor members are still
omitted. This is deliberate: exposing physical addresses via sysfs nodes
encourages behavior that we would like to avoid on ARM (given how it is
more finicky about using correct memory attributes when mapping memory
in userland that may be mapped by the kernel already as well)

Cc: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 drivers/firmware/efi/arm-init.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 0aa4ce7b4fbb..80d1a885def5 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -145,6 +145,9 @@ static int __init uefi_init(void)
 					 sizeof(efi_config_table_t),
 					 arch_tables);
 
+	if (!retval)
+		efi.config_table = (unsigned long)efi.systab->tables;
+
 	early_memunmap(config_tables, table_size);
 out:
 	early_memunmap(efi.systab,  sizeof(efi_system_table_t));
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]


#1716235 — [tip:efi/core] efi/arm/arm64: Add missing assignment of efi.config_table

Fromtip-bot for Ard Biesheuvel <tipbot@zytor.com>
Date2017-08-21 11:30 +0200
Subject[tip:efi/core] efi/arm/arm64: Add missing assignment of efi.config_table
Message-ID<ugRbZ-2zH-33@gated-at.bofh.it>
In reply to#1715401
Commit-ID:  9a9de5c044be14c3337ef45174ac8baa568a0f93
Gitweb:     http://git.kernel.org/tip/9a9de5c044be14c3337ef45174ac8baa568a0f93
Author:     Ard Biesheuvel <ard.biesheuvel@linaro.org>
AuthorDate: Fri, 18 Aug 2017 20:49:38 +0100
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 21 Aug 2017 09:43:49 +0200

efi/arm/arm64: Add missing assignment of efi.config_table

The ARM EFI init code never assigns the config_table member of the
efi struct, which means the sysfs device node is missing, and other
in-kernel users will not work correctly. So add the missing assignment.

Note that, for now, the runtime and fw_vendor members are still
omitted. This is deliberate: exposing physical addresses via sysfs nodes
encourages behavior that we would like to avoid on ARM (given how it is
more finicky about using correct memory attributes when mapping memory
in userland that may be mapped by the kernel already as well).

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20170818194947.19347-6-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 drivers/firmware/efi/arm-init.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 0aa4ce7..80d1a88 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -145,6 +145,9 @@ static int __init uefi_init(void)
 					 sizeof(efi_config_table_t),
 					 arch_tables);
 
+	if (!retval)
+		efi.config_table = (unsigned long)efi.systab->tables;
+
 	early_memunmap(config_tables, table_size);
 out:
 	early_memunmap(efi.systab,  sizeof(efi_system_table_t));

[toc] | [prev] | [next] | [standalone]


#1715402 — [PATCH 01/14] efi: arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP

FromArd Biesheuvel <ard.biesheuvel@linaro.org>
Date2017-08-18 22:00 +0200
Subject[PATCH 01/14] efi: arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP
Message-ID<ufVB0-89n-15@gated-at.bofh.it>
In reply to#1715397
On ARM, regions of memory that are described by UEFI as having special
significance to the firmware itself are omitted from the linear mapping.
This is necessary since we cannot guarantee that alternate mappings of
the same physical region will use attributes that are compatible with
the ones we use for the linear mapping, and aliases with mismatched
attributes are prohibited by the architecture.

The above does not apply to ACPI reclaim regions: such regions have no
special significance to the firmware, and it is up to the OS to decide
whether or not to preserve them after it has consumed their contents,
and for how long, after which time the OS can use the memory in any way
it likes. In the Linux case, such regions are preserved indefinitely,
and are simply treated the same way as other 'reserved' memory types.

Punching holes into the linear mapping causes page table fragmentation,
which increases TLB pressure, and so we should avoid doing so if we can.
So add a special case for regions of type EFI_ACPI_RECLAIM_MEMORY, and
memblock_reserve() them instead of marking them MEMBLOCK_NOMAP.

Acked-by: Mark Rutland <mark.rutland@arm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 drivers/firmware/efi/arm-init.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 1027d7b44358..0aa4ce7b4fbb 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -159,6 +159,7 @@ static __init int is_usable_memory(efi_memory_desc_t *md)
 	switch (md->type) {
 	case EFI_LOADER_CODE:
 	case EFI_LOADER_DATA:
+	case EFI_ACPI_RECLAIM_MEMORY:
 	case EFI_BOOT_SERVICES_CODE:
 	case EFI_BOOT_SERVICES_DATA:
 	case EFI_CONVENTIONAL_MEMORY:
@@ -211,6 +212,10 @@ static __init void reserve_regions(void)
 
 			if (!is_usable_memory(md))
 				memblock_mark_nomap(paddr, size);
+
+			/* keep ACPI reclaim memory intact for kexec etc. */
+			if (md->type == EFI_ACPI_RECLAIM_MEMORY)
+				memblock_reserve(paddr, size);
 		}
 	}
 }
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]


#1716229 — [tip:efi/core] efi/arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP

Fromtip-bot for Ard Biesheuvel <tipbot@zytor.com>
Date2017-08-21 11:30 +0200
Subject[tip:efi/core] efi/arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP
Message-ID<ugRbY-2zH-19@gated-at.bofh.it>
In reply to#1715402
Commit-ID:  f56ab9a5b73ca2aee777ccdf2d355ae2dd31db5a
Gitweb:     http://git.kernel.org/tip/f56ab9a5b73ca2aee777ccdf2d355ae2dd31db5a
Author:     Ard Biesheuvel <ard.biesheuvel@linaro.org>
AuthorDate: Fri, 18 Aug 2017 20:49:34 +0100
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 21 Aug 2017 09:43:49 +0200

efi/arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP

On ARM, regions of memory that are described by UEFI as having special
significance to the firmware itself are omitted from the linear mapping.
This is necessary since we cannot guarantee that alternate mappings of
the same physical region will use attributes that are compatible with
the ones we use for the linear mapping, and aliases with mismatched
attributes are prohibited by the architecture.

The above does not apply to ACPI reclaim regions: such regions have no
special significance to the firmware, and it is up to the OS to decide
whether or not to preserve them after it has consumed their contents,
and for how long, after which time the OS can use the memory in any way
it likes. In the Linux case, such regions are preserved indefinitely,
and are simply treated the same way as other 'reserved' memory types.

Punching holes into the linear mapping causes page table fragmentation,
which increases TLB pressure, and so we should avoid doing so if we can.
So add a special case for regions of type EFI_ACPI_RECLAIM_MEMORY, and
memblock_reserve() them instead of marking them MEMBLOCK_NOMAP.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20170818194947.19347-2-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 drivers/firmware/efi/arm-init.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 1027d7b4..0aa4ce7 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -159,6 +159,7 @@ static __init int is_usable_memory(efi_memory_desc_t *md)
 	switch (md->type) {
 	case EFI_LOADER_CODE:
 	case EFI_LOADER_DATA:
+	case EFI_ACPI_RECLAIM_MEMORY:
 	case EFI_BOOT_SERVICES_CODE:
 	case EFI_BOOT_SERVICES_DATA:
 	case EFI_CONVENTIONAL_MEMORY:
@@ -211,6 +212,10 @@ static __init void reserve_regions(void)
 
 			if (!is_usable_memory(md))
 				memblock_mark_nomap(paddr, size);
+
+			/* keep ACPI reclaim memory intact for kexec etc. */
+			if (md->type == EFI_ACPI_RECLAIM_MEMORY)
+				memblock_reserve(paddr, size);
 		}
 	}
 }

[toc] | [prev] | [next] | [standalone]


#1715404 — [PATCH 06/14] efi/reboot: Fall back to original power-off method if EFI_RESET_SHUTDOWN returns

FromArd Biesheuvel <ard.biesheuvel@linaro.org>
Date2017-08-18 22:00 +0200
Subject[PATCH 06/14] efi/reboot: Fall back to original power-off method if EFI_RESET_SHUTDOWN returns
Message-ID<ufVB0-89n-11@gated-at.bofh.it>
In reply to#1715397
From: Hans de Goede <hdegoede@redhat.com>

Commit 44be28e9dd98 ("x86/reboot: Add EFI reboot quirk for ACPI Hardware
Reduced flag") sets pm_power_off to efi_power_off() when the
acpi_gbl_reduced_hardware flag is set.

According to its commit message this is necessary because: "BayTrail-T
class of hardware requires EFI in order to powerdown and reboot and no
other reliable method exists"

But I have a Bay Trail CR tablet where the EFI_RESET_SHUTDOWN call does
not work, it simply returns without doing anything (AFAICT).

So it seems that some Bay Trail devices must use EFI for power-off, while
for others only ACPI works.

Note that efi_power_off() only gets used if the platform code defines
efi_poweroff_required() and that returns true, this currently only ever
happens on x86.

Since on the devices which need ACPI for power-off the EFI_RESET_SHUTDOWN
call simply returns, this patch makes the efi-reboot code remember the
old pm_power_off handler and if EFI_RESET_SHUTDOWN returns it falls back
to calling that.

This seems preferable to dmi-quirking our way out of this, since there
are likely quite a few devices suffering from this.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: Mark Salter <msalter@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Len Brown <lenb@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Peter Jones <pjones@redhat.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 drivers/firmware/efi/reboot.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/reboot.c b/drivers/firmware/efi/reboot.c
index 62ead9b9d871..7117e2d0c7f9 100644
--- a/drivers/firmware/efi/reboot.c
+++ b/drivers/firmware/efi/reboot.c
@@ -5,6 +5,8 @@
 #include <linux/efi.h>
 #include <linux/reboot.h>
 
+void (*orig_pm_power_off)(void);
+
 int efi_reboot_quirk_mode = -1;
 
 void efi_reboot(enum reboot_mode reboot_mode, const char *__unused)
@@ -51,6 +53,12 @@ bool __weak efi_poweroff_required(void)
 static void efi_power_off(void)
 {
 	efi.reset_system(EFI_RESET_SHUTDOWN, EFI_SUCCESS, 0, NULL);
+	/*
+	 * The above call should not return, if it does fall back to
+	 * the original power off method (typically ACPI poweroff).
+	 */
+	if (orig_pm_power_off)
+		orig_pm_power_off();
 }
 
 static int __init efi_shutdown_init(void)
@@ -58,8 +66,10 @@ static int __init efi_shutdown_init(void)
 	if (!efi_enabled(EFI_RUNTIME_SERVICES))
 		return -ENODEV;
 
-	if (efi_poweroff_required())
+	if (efi_poweroff_required()) {
+		orig_pm_power_off = pm_power_off;
 		pm_power_off = efi_power_off;
+	}
 
 	return 0;
 }
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]


#1716243 — [tip:efi/core] efi/reboot: Fall back to original power-off method if EFI_RESET_SHUTDOWN returns

Fromtip-bot for Hans de Goede <tipbot@zytor.com>
Date2017-08-21 11:30 +0200
Subject[tip:efi/core] efi/reboot: Fall back to original power-off method if EFI_RESET_SHUTDOWN returns
Message-ID<ugRbZ-2zH-51@gated-at.bofh.it>
In reply to#1715404
Commit-ID:  b6a3780dad74f6e3d1d45eca843ae623cc3216a8
Gitweb:     http://git.kernel.org/tip/b6a3780dad74f6e3d1d45eca843ae623cc3216a8
Author:     Hans de Goede <hdegoede@redhat.com>
AuthorDate: Fri, 18 Aug 2017 20:49:39 +0100
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 21 Aug 2017 09:43:50 +0200

efi/reboot: Fall back to original power-off method if EFI_RESET_SHUTDOWN returns

Commit:

  44be28e9dd98 ("x86/reboot: Add EFI reboot quirk for ACPI Hardware Reduced flag")

sets pm_power_off to efi_power_off() when the acpi_gbl_reduced_hardware
flag is set.

According to its commit message this is necessary because: "BayTrail-T
class of hardware requires EFI in order to powerdown and reboot and no
other reliable method exists".

But I have a Bay Trail CR tablet where the EFI_RESET_SHUTDOWN call does
not work, it simply returns without doing anything (AFAICT).

So it seems that some Bay Trail devices must use EFI for power-off, while
for others only ACPI works.

Note that efi_power_off() only gets used if the platform code defines
efi_poweroff_required() and that returns true, this currently only ever
happens on x86.

Since on the devices which need ACPI for power-off the EFI_RESET_SHUTDOWN
call simply returns, this patch makes the efi-reboot code remember the
old pm_power_off handler and if EFI_RESET_SHUTDOWN returns it falls back
to calling that.

This seems preferable to dmi-quirking our way out of this, since there
are likely quite a few devices suffering from this.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Salter <msalter@redhat.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20170818194947.19347-7-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 drivers/firmware/efi/reboot.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/reboot.c b/drivers/firmware/efi/reboot.c
index 62ead9b..7117e2d 100644
--- a/drivers/firmware/efi/reboot.c
+++ b/drivers/firmware/efi/reboot.c
@@ -5,6 +5,8 @@
 #include <linux/efi.h>
 #include <linux/reboot.h>
 
+void (*orig_pm_power_off)(void);
+
 int efi_reboot_quirk_mode = -1;
 
 void efi_reboot(enum reboot_mode reboot_mode, const char *__unused)
@@ -51,6 +53,12 @@ bool __weak efi_poweroff_required(void)
 static void efi_power_off(void)
 {
 	efi.reset_system(EFI_RESET_SHUTDOWN, EFI_SUCCESS, 0, NULL);
+	/*
+	 * The above call should not return, if it does fall back to
+	 * the original power off method (typically ACPI poweroff).
+	 */
+	if (orig_pm_power_off)
+		orig_pm_power_off();
 }
 
 static int __init efi_shutdown_init(void)
@@ -58,8 +66,10 @@ static int __init efi_shutdown_init(void)
 	if (!efi_enabled(EFI_RUNTIME_SERVICES))
 		return -ENODEV;
 
-	if (efi_poweroff_required())
+	if (efi_poweroff_required()) {
+		orig_pm_power_off = pm_power_off;
 		pm_power_off = efi_power_off;
+	}
 
 	return 0;
 }

[toc] | [prev] | [next] | [standalone]


#1715405 — [PATCH 04/14] efi/libstub: arm64: set -fpie when building the EFI stub

FromArd Biesheuvel <ard.biesheuvel@linaro.org>
Date2017-08-18 22:00 +0200
Subject[PATCH 04/14] efi/libstub: arm64: set -fpie when building the EFI stub
Message-ID<ufVB0-89n-17@gated-at.bofh.it>
In reply to#1715397
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.

Cc: Matt Fleming <matt@codeblueprint.co.uk>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 drivers/firmware/efi/libstub/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index 37e24f525162..cf81e6cf5ae8 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -10,7 +10,7 @@ cflags-$(CONFIG_X86)		+= -m$(BITS) -D__KERNEL__ -O2 \
 				   -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
 
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]


#1716224 — [tip:efi/core] efi/libstub/arm64: Set -fpie when building the EFI stub

Fromtip-bot for Ard Biesheuvel <tipbot@zytor.com>
Date2017-08-21 11:30 +0200
Subject[tip:efi/core] efi/libstub/arm64: Set -fpie when building the EFI stub
Message-ID<ugRbX-2zH-5@gated-at.bofh.it>
In reply to#1715405
Commit-ID:  91ee5b21ee026c49e4e7483de69b55b8b47042be
Gitweb:     http://git.kernel.org/tip/91ee5b21ee026c49e4e7483de69b55b8b47042be
Author:     Ard Biesheuvel <ard.biesheuvel@linaro.org>
AuthorDate: Fri, 18 Aug 2017 20:49:37 +0100
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 21 Aug 2017 09:43:49 +0200

efi/libstub/arm64: Set -fpie when building the EFI stub

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 <mka@chromium.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20170818194947.19347-5-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 drivers/firmware/efi/libstub/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index 37e24f5..cf81e6c 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -10,7 +10,7 @@ cflags-$(CONFIG_X86)		+= -m$(BITS) -D__KERNEL__ -O2 \
 				   -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
 

[toc] | [prev] | [next] | [standalone]


#1715407 — [PATCH 09/14] arm: efi: remove pointless dummy .reloc section

FromArd Biesheuvel <ard.biesheuvel@linaro.org>
Date2017-08-18 22:00 +0200
Subject[PATCH 09/14] arm: efi: remove pointless dummy .reloc section
Message-ID<ufVB0-89n-21@gated-at.bofh.it>
In reply to#1715397
The kernel's EFI PE/COFF header contains a dummy .reloc section, and
an explanatory comment that claims that this is required for the EFI
application loader to accept the Image as a relocatable image (i.e.,
one that can be loaded at any offset and fixed up in place)

This was inherited from the x86 implementation, which has elaborate host
tooling to mangle the PE/COFF header post-link time, and which populates
the .reloc section with a single dummy base relocation. On ARM, no such
tooling exists, and the .reloc section remains empty, and is never even
exposed via the BaseRelocationTable directory entry, which is where the
PE/COFF loader looks for it.

The PE/COFF spec is unclear about relocatable images that do not require
any fixups, but the EDK2 implementation, which is the de facto reference
for PE/COFF in the UEFI space, clearly does not care, and explicitly
mentions (in a comment) that relocatable images with no base relocations
are perfectly fine, as long as they don't have the RELOCS_STRIPPED
attribute set (which is not the case for our PE/COFF image)

So simply remove the .reloc section altogether.

Cc: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm/boot/compressed/efi-header.S | 18 +-----------------
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/arch/arm/boot/compressed/efi-header.S b/arch/arm/boot/compressed/efi-header.S
index 4169b900d9d4..309d6198d335 100644
--- a/arch/arm/boot/compressed/efi-header.S
+++ b/arch/arm/boot/compressed/efi-header.S
@@ -41,7 +41,7 @@ pe_header:
 
 coff_header:
 		.short	0x01c2			@ ARM or Thumb
-		.short	2			@ nr_sections
+		.short	1			@ nr_sections
 		.long	0 			@ TimeDateStamp
 		.long	0			@ PointerToSymbolTable
 		.long	0			@ NumberOfSymbols
@@ -96,22 +96,6 @@ extra_header_fields:
 		.quad	0			@ BaseRelocationTable
 
 section_table:
-		@
-		@ The EFI application loader requires a relocation section
-		@ because EFI applications must be relocatable. This is a
-		@ dummy section as far as we are concerned.
-		@
-		.ascii	".reloc\0\0"
-		.long	0			@ VirtualSize
-		.long	0			@ VirtualAddress
-		.long	0			@ SizeOfRawData
-		.long	0			@ PointerToRawData
-		.long	0			@ PointerToRelocations
-		.long	0			@ PointerToLineNumbers
-		.short	0			@ NumberOfRelocations
-		.short	0			@ NumberOfLineNumbers
-		.long	0x42000040		@ Characteristics
-
 		.ascii	".text\0\0\0"
 		.long	_end - __efi_start	@ VirtualSize
 		.long	__efi_start		@ VirtualAddress
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]


#1716226 — [tip:efi/core] arm/efi: Remove pointless dummy .reloc section

Fromtip-bot for Ard Biesheuvel <tipbot@zytor.com>
Date2017-08-21 11:30 +0200
Subject[tip:efi/core] arm/efi: Remove pointless dummy .reloc section
Message-ID<ugRbY-2zH-13@gated-at.bofh.it>
In reply to#1715407
Commit-ID:  574cea724cd81f4063491ed1c0534d81a094a913
Gitweb:     http://git.kernel.org/tip/574cea724cd81f4063491ed1c0534d81a094a913
Author:     Ard Biesheuvel <ard.biesheuvel@linaro.org>
AuthorDate: Fri, 18 Aug 2017 20:49:42 +0100
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 21 Aug 2017 09:43:50 +0200

arm/efi: Remove pointless dummy .reloc section

The kernel's EFI PE/COFF header contains a dummy .reloc section, and
an explanatory comment that claims that this is required for the EFI
application loader to accept the Image as a relocatable image (i.e.,
one that can be loaded at any offset and fixed up in place)

This was inherited from the x86 implementation, which has elaborate host
tooling to mangle the PE/COFF header post-link time, and which populates
the .reloc section with a single dummy base relocation. On ARM, no such
tooling exists, and the .reloc section remains empty, and is never even
exposed via the BaseRelocationTable directory entry, which is where the
PE/COFF loader looks for it.

The PE/COFF spec is unclear about relocatable images that do not require
any fixups, but the EDK2 implementation, which is the de facto reference
for PE/COFF in the UEFI space, clearly does not care, and explicitly
mentions (in a comment) that relocatable images with no base relocations
are perfectly fine, as long as they don't have the RELOCS_STRIPPED
attribute set (which is not the case for our PE/COFF image)

So simply remove the .reloc section altogether.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20170818194947.19347-10-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/arm/boot/compressed/efi-header.S | 18 +-----------------
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/arch/arm/boot/compressed/efi-header.S b/arch/arm/boot/compressed/efi-header.S
index 4169b90..309d619 100644
--- a/arch/arm/boot/compressed/efi-header.S
+++ b/arch/arm/boot/compressed/efi-header.S
@@ -41,7 +41,7 @@ pe_header:
 
 coff_header:
 		.short	0x01c2			@ ARM or Thumb
-		.short	2			@ nr_sections
+		.short	1			@ nr_sections
 		.long	0 			@ TimeDateStamp
 		.long	0			@ PointerToSymbolTable
 		.long	0			@ NumberOfSymbols
@@ -96,22 +96,6 @@ extra_header_fields:
 		.quad	0			@ BaseRelocationTable
 
 section_table:
-		@
-		@ The EFI application loader requires a relocation section
-		@ because EFI applications must be relocatable. This is a
-		@ dummy section as far as we are concerned.
-		@
-		.ascii	".reloc\0\0"
-		.long	0			@ VirtualSize
-		.long	0			@ VirtualAddress
-		.long	0			@ SizeOfRawData
-		.long	0			@ PointerToRawData
-		.long	0			@ PointerToRelocations
-		.long	0			@ PointerToLineNumbers
-		.short	0			@ NumberOfRelocations
-		.short	0			@ NumberOfLineNumbers
-		.long	0x42000040		@ Characteristics
-
 		.ascii	".text\0\0\0"
 		.long	_end - __efi_start	@ VirtualSize
 		.long	__efi_start		@ VirtualAddress

[toc] | [prev] | [next] | [standalone]


#1715408 — [PATCH 07/14] drivers/fbdev: efifb: allow BAR to be moved instead of claiming it

FromArd Biesheuvel <ard.biesheuvel@linaro.org>
Date2017-08-18 22:00 +0200
Subject[PATCH 07/14] drivers/fbdev: efifb: allow BAR to be moved instead of claiming it
Message-ID<ufVB0-89n-23@gated-at.bofh.it>
In reply to#1715397
On UEFI systems, the firmware may expose a Graphics Output Protocol (GOP)
instance to which the efifb driver attempts to attach in order to provide
a minimal, unaccelerated framebuffer. The GOP protocol itself is not very
sophisticated, and only describes the offset and size of the framebuffer
in memory, and the pixel format.

If the GOP framebuffer is provided by a PCI device, it will have been
configured and enabled by the UEFI firmware, and the GOP protocol will
simply point into a live BAR region. However, the GOP protocol itself does
not describe this relation, and so we have to take care not to reconfigure
the BAR without taking efifb's dependency on it into account.

Commit 55d728a40d36 ("efi/fb: Avoid reconfiguration of BAR that covers
the framebuffer") attempted to do so by claiming the BAR resource early
on, which prevents the PCI resource allocation routines from changing it.
However, it turns out that this only works if the PCI device is not
behind any bridges, since the bridge resources need to be claimed first.

So instead, allow the BAR to be moved, but make the efifb driver deal
with that gracefully. So record the resource that covers the BAR early
on, and if it turns out to have moved by the time we probe the efifb
driver, update the framebuffer address accordingly.

While this is less likely to occur on x86, given that the firmware's
PCI resource allocation is more likely to be preserved, this is a
worthwhile sanity check to have in place, and so let's remove the
preprocessor conditional that makes it !X86 only.

Cc: Matt Fleming <matt@codeblueprint.co.uk>
Reviewed-by: Peter Jones <pjones@redhat.com>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 drivers/video/fbdev/efifb.c | 31 ++++++++++++++++++-------------
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index ff01bed7112f..994b5f3a4d73 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -146,6 +146,10 @@ ATTRIBUTE_GROUPS(efifb);
 
 static bool pci_dev_disabled;	/* FB base matches BAR of a disabled device */
 
+static struct pci_dev *efifb_pci_dev;	/* dev with BAR covering the efifb */
+static struct resource *bar_resource;
+static u64 bar_offset;
+
 static int efifb_probe(struct platform_device *dev)
 {
 	struct fb_info *info;
@@ -200,6 +204,13 @@ static int efifb_probe(struct platform_device *dev)
 		efifb_fix.smem_start |= ext_lfb_base;
 	}
 
+	if (bar_resource &&
+	    bar_resource->start + bar_offset != efifb_fix.smem_start) {
+		dev_info(&efifb_pci_dev->dev,
+			 "BAR has moved, updating efifb address\n");
+		efifb_fix.smem_start = bar_resource->start + bar_offset;
+	}
+
 	efifb_defined.bits_per_pixel = screen_info.lfb_depth;
 	efifb_defined.xres = screen_info.lfb_width;
 	efifb_defined.yres = screen_info.lfb_height;
@@ -364,15 +375,13 @@ static struct platform_driver efifb_driver = {
 
 builtin_platform_driver(efifb_driver);
 
-#if defined(CONFIG_PCI) && !defined(CONFIG_X86)
-
-static bool pci_bar_found;	/* did we find a BAR matching the efifb base? */
+#if defined(CONFIG_PCI)
 
-static void claim_efifb_bar(struct pci_dev *dev, int idx)
+static void record_efifb_bar_resource(struct pci_dev *dev, int idx, u64 offset)
 {
 	u16 word;
 
-	pci_bar_found = true;
+	efifb_pci_dev = dev;
 
 	pci_read_config_word(dev, PCI_COMMAND, &word);
 	if (!(word & PCI_COMMAND_MEMORY)) {
@@ -383,12 +392,8 @@ static void claim_efifb_bar(struct pci_dev *dev, int idx)
 		return;
 	}
 
-	if (pci_claim_resource(dev, idx)) {
-		pci_dev_disabled = true;
-		dev_err(&dev->dev,
-			"BAR %d: failed to claim resource for efifb!\n", idx);
-		return;
-	}
+	bar_resource = &dev->resource[idx];
+	bar_offset = offset;
 
 	dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx);
 }
@@ -399,7 +404,7 @@ static void efifb_fixup_resources(struct pci_dev *dev)
 	u64 size = screen_info.lfb_size;
 	int i;
 
-	if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
+	if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
 		return;
 
 	if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
@@ -415,7 +420,7 @@ static void efifb_fixup_resources(struct pci_dev *dev)
 			continue;
 
 		if (res->start <= base && res->end >= base + size - 1) {
-			claim_efifb_bar(dev, i);
+			record_efifb_bar_resource(dev, i, base - res->start);
 			break;
 		}
 	}
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]


#1716231 — [tip:efi/core] drivers/fbdev/efifb: Allow BAR to be moved instead of claiming it

Fromtip-bot for Ard Biesheuvel <tipbot@zytor.com>
Date2017-08-21 11:30 +0200
Subject[tip:efi/core] drivers/fbdev/efifb: Allow BAR to be moved instead of claiming it
Message-ID<ugRbY-2zH-23@gated-at.bofh.it>
In reply to#1715408
Commit-ID:  dcf8f5ce31656534efada252f6a563c09b295983
Gitweb:     http://git.kernel.org/tip/dcf8f5ce31656534efada252f6a563c09b295983
Author:     Ard Biesheuvel <ard.biesheuvel@linaro.org>
AuthorDate: Fri, 18 Aug 2017 20:49:40 +0100
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 21 Aug 2017 09:43:50 +0200

drivers/fbdev/efifb: Allow BAR to be moved instead of claiming it

On UEFI systems, the firmware may expose a Graphics Output Protocol (GOP)
instance to which the efifb driver attempts to attach in order to provide
a minimal, unaccelerated framebuffer. The GOP protocol itself is not very
sophisticated, and only describes the offset and size of the framebuffer
in memory, and the pixel format.

If the GOP framebuffer is provided by a PCI device, it will have been
configured and enabled by the UEFI firmware, and the GOP protocol will
simply point into a live BAR region. However, the GOP protocol itself does
not describe this relation, and so we have to take care not to reconfigure
the BAR without taking efifb's dependency on it into account.

Commit:

  55d728a40d36 ("efi/fb: Avoid reconfiguration of BAR that covers the framebuffer")

attempted to do so by claiming the BAR resource early on, which prevents the
PCI resource allocation routines from changing it.  However, it turns out
that this only works if the PCI device is not behind any bridges, since
the bridge resources need to be claimed first.

So instead, allow the BAR to be moved, but make the efifb driver deal
with that gracefully. So record the resource that covers the BAR early
on, and if it turns out to have moved by the time we probe the efifb
driver, update the framebuffer address accordingly.

While this is less likely to occur on x86, given that the firmware's
PCI resource allocation is more likely to be preserved, this is a
worthwhile sanity check to have in place, and so let's remove the
preprocessor conditional that makes it !X86 only.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Peter Jones <pjones@redhat.com>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20170818194947.19347-8-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 drivers/video/fbdev/efifb.c | 31 ++++++++++++++++++-------------
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 1e784ad..3a01064 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -149,6 +149,10 @@ ATTRIBUTE_GROUPS(efifb);
 
 static bool pci_dev_disabled;	/* FB base matches BAR of a disabled device */
 
+static struct pci_dev *efifb_pci_dev;	/* dev with BAR covering the efifb */
+static struct resource *bar_resource;
+static u64 bar_offset;
+
 static int efifb_probe(struct platform_device *dev)
 {
 	struct fb_info *info;
@@ -203,6 +207,13 @@ static int efifb_probe(struct platform_device *dev)
 		efifb_fix.smem_start |= ext_lfb_base;
 	}
 
+	if (bar_resource &&
+	    bar_resource->start + bar_offset != efifb_fix.smem_start) {
+		dev_info(&efifb_pci_dev->dev,
+			 "BAR has moved, updating efifb address\n");
+		efifb_fix.smem_start = bar_resource->start + bar_offset;
+	}
+
 	efifb_defined.bits_per_pixel = screen_info.lfb_depth;
 	efifb_defined.xres = screen_info.lfb_width;
 	efifb_defined.yres = screen_info.lfb_height;
@@ -370,15 +381,13 @@ static struct platform_driver efifb_driver = {
 
 builtin_platform_driver(efifb_driver);
 
-#if defined(CONFIG_PCI) && !defined(CONFIG_X86)
-
-static bool pci_bar_found;	/* did we find a BAR matching the efifb base? */
+#if defined(CONFIG_PCI)
 
-static void claim_efifb_bar(struct pci_dev *dev, int idx)
+static void record_efifb_bar_resource(struct pci_dev *dev, int idx, u64 offset)
 {
 	u16 word;
 
-	pci_bar_found = true;
+	efifb_pci_dev = dev;
 
 	pci_read_config_word(dev, PCI_COMMAND, &word);
 	if (!(word & PCI_COMMAND_MEMORY)) {
@@ -389,12 +398,8 @@ static void claim_efifb_bar(struct pci_dev *dev, int idx)
 		return;
 	}
 
-	if (pci_claim_resource(dev, idx)) {
-		pci_dev_disabled = true;
-		dev_err(&dev->dev,
-			"BAR %d: failed to claim resource for efifb!\n", idx);
-		return;
-	}
+	bar_resource = &dev->resource[idx];
+	bar_offset = offset;
 
 	dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx);
 }
@@ -405,7 +410,7 @@ static void efifb_fixup_resources(struct pci_dev *dev)
 	u64 size = screen_info.lfb_size;
 	int i;
 
-	if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
+	if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
 		return;
 
 	if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
@@ -421,7 +426,7 @@ static void efifb_fixup_resources(struct pci_dev *dev)
 			continue;
 
 		if (res->start <= base && res->end >= base + size - 1) {
-			claim_efifb_bar(dev, i);
+			record_efifb_bar_resource(dev, i, base - res->start);
 			break;
 		}
 	}

[toc] | [prev] | [next] | [standalone]


#1715409 — [PATCH 11/14] arm: efi: split zImage code and data into separate PE/COFF sections

FromArd Biesheuvel <ard.biesheuvel@linaro.org>
Date2017-08-18 22:00 +0200
Subject[PATCH 11/14] arm: efi: split zImage code and data into separate PE/COFF sections
Message-ID<ufVB1-89n-25@gated-at.bofh.it>
In reply to#1715397
To prevent unintended modifications to the kernel text (malicious or
otherwise) while running the EFI stub, describe the kernel image as
two separate sections: a .text section with read-execute permissions,
covering .text, .rodata, .piggytext and the GOT sections (which the
stub does not care about anyway), and a .data section with read-write
permissions, covering .data and .bss.

This relies on the firmware to actually take the section permission
flags into account, but this is something that is currently being
implemented in EDK2, which means we will likely start seeing it in
the wild between one and two years from now.

Cc: Russell King <linux@armlinux.org.uk>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm/boot/compressed/efi-header.S  | 32 +++++++++++++++++++++++---------
 arch/arm/boot/compressed/vmlinux.lds.S | 30 +++++++++++++++++++++++-------
 2 files changed, 46 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/compressed/efi-header.S b/arch/arm/boot/compressed/efi-header.S
index 542e1ad432ae..c94a88ae834d 100644
--- a/arch/arm/boot/compressed/efi-header.S
+++ b/arch/arm/boot/compressed/efi-header.S
@@ -54,20 +54,22 @@ coff_header:
 			IMAGE_FILE_EXECUTABLE_IMAGE | \
 			IMAGE_FILE_LINE_NUMS_STRIPPED	@ Characteristics
 
+#define __pecoff_code_size (__pecoff_data_start - __efi_start)
+
 optional_header:
 		.short	PE_OPT_MAGIC_PE32		@ PE32 format
 		.byte	0x02				@ MajorLinkerVersion
 		.byte	0x14				@ MinorLinkerVersion
-		.long	_end - __efi_start		@ SizeOfCode
-		.long	0				@ SizeOfInitializedData
+		.long	__pecoff_code_size		@ SizeOfCode
+		.long	__pecoff_data_size		@ SizeOfInitializedData
 		.long	0				@ SizeOfUninitializedData
 		.long	efi_stub_entry - start		@ AddressOfEntryPoint
 		.long	start_offset			@ BaseOfCode
-		.long	0				@ BaseOfData
+		.long	__pecoff_data_start - start	@ BaseOfData
 
 extra_header_fields:
 		.long	0				@ ImageBase
-		.long	SZ_512				@ SectionAlignment
+		.long	SZ_4K				@ SectionAlignment
 		.long	SZ_512				@ FileAlignment
 		.short	0				@ MajorOsVersion
 		.short	0				@ MinorOsVersion
@@ -77,7 +79,7 @@ extra_header_fields:
 		.short	0				@ MinorSubsystemVersion
 		.long	0				@ Win32VersionValue
 
-		.long	_end - start			@ SizeOfImage
+		.long	__pecoff_end - start		@ SizeOfImage
 		.long	start_offset			@ SizeOfHeaders
 		.long	0				@ CheckSum
 		.short	IMAGE_SUBSYSTEM_EFI_APPLICATION	@ Subsystem
@@ -98,9 +100,9 @@ extra_header_fields:
 
 section_table:
 		.ascii	".text\0\0\0"
-		.long	_end - __efi_start		@ VirtualSize
+		.long	__pecoff_code_size		@ VirtualSize
 		.long	__efi_start			@ VirtualAddress
-		.long	_edata - __efi_start		@ SizeOfRawData
+		.long	__pecoff_code_size		@ SizeOfRawData
 		.long	__efi_start			@ PointerToRawData
 		.long	0				@ PointerToRelocations
 		.long	0				@ PointerToLineNumbers
@@ -108,12 +110,24 @@ section_table:
 		.short	0				@ NumberOfLineNumbers
 		.long	IMAGE_SCN_CNT_CODE | \
 			IMAGE_SCN_MEM_READ | \
-			IMAGE_SCN_MEM_WRITE | \
 			IMAGE_SCN_MEM_EXECUTE		@ Characteristics
 
+		.ascii	".data\0\0\0"
+		.long	__pecoff_data_size		@ VirtualSize
+		.long	__pecoff_data_start - start	@ VirtualAddress
+		.long	__pecoff_data_rawsize		@ SizeOfRawData
+		.long	__pecoff_data_start - start	@ PointerToRawData
+		.long	0				@ PointerToRelocations
+		.long	0				@ PointerToLineNumbers
+		.short	0				@ NumberOfRelocations
+		.short	0				@ NumberOfLineNumbers
+		.long	IMAGE_SCN_CNT_INITIALIZED_DATA | \
+			IMAGE_SCN_MEM_READ | \
+			IMAGE_SCN_MEM_WRITE		@ Characteristics
+
 		.set	section_count, (. - section_table) / 40
 
-		.align	9
+		.align	12
 __efi_start:
 #endif
 		.endm
diff --git a/arch/arm/boot/compressed/vmlinux.lds.S b/arch/arm/boot/compressed/vmlinux.lds.S
index 81c493156ce8..7a4c59154361 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.S
+++ b/arch/arm/boot/compressed/vmlinux.lds.S
@@ -48,13 +48,6 @@ SECTIONS
     *(.rodata)
     *(.rodata.*)
   }
-  .data : {
-    /*
-     * The EFI stub always executes from RAM, and runs strictly before the
-     * decompressor, so we can make an exception for its r/w data, and keep it
-     */
-    *(.data.efistub)
-  }
   .piggydata : {
     *(.piggydata)
   }
@@ -70,6 +63,26 @@ SECTIONS
   /* ensure the zImage file size is always a multiple of 64 bits */
   /* (without a dummy byte, ld just ignores the empty section) */
   .pad			: { BYTE(0); . = ALIGN(8); }
+
+#ifdef CONFIG_EFI_STUB
+  .data : ALIGN(4096) {
+    __pecoff_data_start = .;
+    /*
+     * The EFI stub always executes from RAM, and runs strictly before the
+     * decompressor, so we can make an exception for its r/w data, and keep it
+     */
+    *(.data.efistub)
+    __pecoff_data_end = .;
+
+    /*
+     * PE/COFF mandates a file size which is a multiple of 512 bytes if the
+     * section size equals or exceeds 4 KB
+     */
+    . = ALIGN(512);
+  }
+  __pecoff_data_rawsize = . - ADDR(.data);
+#endif
+
   _edata = .;
 
   _magic_sig = ZIMAGE_MAGIC(0x016f2818);
@@ -84,6 +97,9 @@ SECTIONS
   . = ALIGN(8);		/* the stack must be 64-bit aligned */
   .stack		: { *(.stack) }
 
+  PROVIDE(__pecoff_data_size = ALIGN(512) - ADDR(.data));
+  PROVIDE(__pecoff_end = ALIGN(512));
+
   .stab 0		: { *(.stab) }
   .stabstr 0		: { *(.stabstr) }
   .stab.excl 0		: { *(.stab.excl) }
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]


#1716240 — [tip:efi/core] arm/efi: Split zImage code and data into separate PE/COFF sections

Fromtip-bot for Ard Biesheuvel <tipbot@zytor.com>
Date2017-08-21 11:30 +0200
Subject[tip:efi/core] arm/efi: Split zImage code and data into separate PE/COFF sections
Message-ID<ugRbZ-2zH-43@gated-at.bofh.it>
In reply to#1715409
Commit-ID:  e4bae4d0b5f368dda5bbf1374dca74c1b542d841
Gitweb:     http://git.kernel.org/tip/e4bae4d0b5f368dda5bbf1374dca74c1b542d841
Author:     Ard Biesheuvel <ard.biesheuvel@linaro.org>
AuthorDate: Fri, 18 Aug 2017 20:49:44 +0100
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 21 Aug 2017 09:43:51 +0200

arm/efi: Split zImage code and data into separate PE/COFF sections

To prevent unintended modifications to the kernel text (malicious or
otherwise) while running the EFI stub, describe the kernel image as
two separate sections: a .text section with read-execute permissions,
covering .text, .rodata, .piggytext and the GOT sections (which the
stub does not care about anyway), and a .data section with read-write
permissions, covering .data and .bss.

This relies on the firmware to actually take the section permission
flags into account, but this is something that is currently being
implemented in EDK2, which means we will likely start seeing it in
the wild between one and two years from now.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20170818194947.19347-12-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/arm/boot/compressed/efi-header.S  | 32 +++++++++++++++++++++++---------
 arch/arm/boot/compressed/vmlinux.lds.S | 30 +++++++++++++++++++++++-------
 2 files changed, 46 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/compressed/efi-header.S b/arch/arm/boot/compressed/efi-header.S
index 542e1ad..c94a88a 100644
--- a/arch/arm/boot/compressed/efi-header.S
+++ b/arch/arm/boot/compressed/efi-header.S
@@ -54,20 +54,22 @@ coff_header:
 			IMAGE_FILE_EXECUTABLE_IMAGE | \
 			IMAGE_FILE_LINE_NUMS_STRIPPED	@ Characteristics
 
+#define __pecoff_code_size (__pecoff_data_start - __efi_start)
+
 optional_header:
 		.short	PE_OPT_MAGIC_PE32		@ PE32 format
 		.byte	0x02				@ MajorLinkerVersion
 		.byte	0x14				@ MinorLinkerVersion
-		.long	_end - __efi_start		@ SizeOfCode
-		.long	0				@ SizeOfInitializedData
+		.long	__pecoff_code_size		@ SizeOfCode
+		.long	__pecoff_data_size		@ SizeOfInitializedData
 		.long	0				@ SizeOfUninitializedData
 		.long	efi_stub_entry - start		@ AddressOfEntryPoint
 		.long	start_offset			@ BaseOfCode
-		.long	0				@ BaseOfData
+		.long	__pecoff_data_start - start	@ BaseOfData
 
 extra_header_fields:
 		.long	0				@ ImageBase
-		.long	SZ_512				@ SectionAlignment
+		.long	SZ_4K				@ SectionAlignment
 		.long	SZ_512				@ FileAlignment
 		.short	0				@ MajorOsVersion
 		.short	0				@ MinorOsVersion
@@ -77,7 +79,7 @@ extra_header_fields:
 		.short	0				@ MinorSubsystemVersion
 		.long	0				@ Win32VersionValue
 
-		.long	_end - start			@ SizeOfImage
+		.long	__pecoff_end - start		@ SizeOfImage
 		.long	start_offset			@ SizeOfHeaders
 		.long	0				@ CheckSum
 		.short	IMAGE_SUBSYSTEM_EFI_APPLICATION	@ Subsystem
@@ -98,9 +100,9 @@ extra_header_fields:
 
 section_table:
 		.ascii	".text\0\0\0"
-		.long	_end - __efi_start		@ VirtualSize
+		.long	__pecoff_code_size		@ VirtualSize
 		.long	__efi_start			@ VirtualAddress
-		.long	_edata - __efi_start		@ SizeOfRawData
+		.long	__pecoff_code_size		@ SizeOfRawData
 		.long	__efi_start			@ PointerToRawData
 		.long	0				@ PointerToRelocations
 		.long	0				@ PointerToLineNumbers
@@ -108,12 +110,24 @@ section_table:
 		.short	0				@ NumberOfLineNumbers
 		.long	IMAGE_SCN_CNT_CODE | \
 			IMAGE_SCN_MEM_READ | \
-			IMAGE_SCN_MEM_WRITE | \
 			IMAGE_SCN_MEM_EXECUTE		@ Characteristics
 
+		.ascii	".data\0\0\0"
+		.long	__pecoff_data_size		@ VirtualSize
+		.long	__pecoff_data_start - start	@ VirtualAddress
+		.long	__pecoff_data_rawsize		@ SizeOfRawData
+		.long	__pecoff_data_start - start	@ PointerToRawData
+		.long	0				@ PointerToRelocations
+		.long	0				@ PointerToLineNumbers
+		.short	0				@ NumberOfRelocations
+		.short	0				@ NumberOfLineNumbers
+		.long	IMAGE_SCN_CNT_INITIALIZED_DATA | \
+			IMAGE_SCN_MEM_READ | \
+			IMAGE_SCN_MEM_WRITE		@ Characteristics
+
 		.set	section_count, (. - section_table) / 40
 
-		.align	9
+		.align	12
 __efi_start:
 #endif
 		.endm
diff --git a/arch/arm/boot/compressed/vmlinux.lds.S b/arch/arm/boot/compressed/vmlinux.lds.S
index 81c4931..7a4c591 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.S
+++ b/arch/arm/boot/compressed/vmlinux.lds.S
@@ -48,13 +48,6 @@ SECTIONS
     *(.rodata)
     *(.rodata.*)
   }
-  .data : {
-    /*
-     * The EFI stub always executes from RAM, and runs strictly before the
-     * decompressor, so we can make an exception for its r/w data, and keep it
-     */
-    *(.data.efistub)
-  }
   .piggydata : {
     *(.piggydata)
   }
@@ -70,6 +63,26 @@ SECTIONS
   /* ensure the zImage file size is always a multiple of 64 bits */
   /* (without a dummy byte, ld just ignores the empty section) */
   .pad			: { BYTE(0); . = ALIGN(8); }
+
+#ifdef CONFIG_EFI_STUB
+  .data : ALIGN(4096) {
+    __pecoff_data_start = .;
+    /*
+     * The EFI stub always executes from RAM, and runs strictly before the
+     * decompressor, so we can make an exception for its r/w data, and keep it
+     */
+    *(.data.efistub)
+    __pecoff_data_end = .;
+
+    /*
+     * PE/COFF mandates a file size which is a multiple of 512 bytes if the
+     * section size equals or exceeds 4 KB
+     */
+    . = ALIGN(512);
+  }
+  __pecoff_data_rawsize = . - ADDR(.data);
+#endif
+
   _edata = .;
 
   _magic_sig = ZIMAGE_MAGIC(0x016f2818);
@@ -84,6 +97,9 @@ SECTIONS
   . = ALIGN(8);		/* the stack must be 64-bit aligned */
   .stack		: { *(.stack) }
 
+  PROVIDE(__pecoff_data_size = ALIGN(512) - ADDR(.data));
+  PROVIDE(__pecoff_end = ALIGN(512));
+
   .stab 0		: { *(.stab) }
   .stabstr 0		: { *(.stabstr) }
   .stab.excl 0		: { *(.stab.excl) }

[toc] | [prev] | [next] | [standalone]


#1715411 — [PATCH 02/14] efi/libstub: arm64: use hidden attribute for struct screen_info reference

FromArd Biesheuvel <ard.biesheuvel@linaro.org>
Date2017-08-18 22:00 +0200
Subject[PATCH 02/14] efi/libstub: arm64: use hidden attribute for struct screen_info reference
Message-ID<ufVB1-89n-27@gated-at.bofh.it>
In reply to#1715397
To prevent the compiler from emitting absolute references to screen_info
when building position independent code, redeclare the symbol with hidden
visibility.

Cc: Matt Fleming <matt@codeblueprint.co.uk>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm64/include/asm/efi.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index 8f3043aba873..464ac850c5e2 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -81,6 +81,9 @@ static inline unsigned long efi_get_max_initrd_addr(unsigned long dram_base,
 #define alloc_screen_info(x...)		&screen_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)
 {
 }
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]


#1716238 — [tip:efi/core] efi/libstub/arm64: Use hidden attribute for struct screen_info reference

Fromtip-bot for Ard Biesheuvel <tipbot@zytor.com>
Date2017-08-21 11:30 +0200
Subject[tip:efi/core] efi/libstub/arm64: Use hidden attribute for struct screen_info reference
Message-ID<ugRbZ-2zH-45@gated-at.bofh.it>
In reply to#1715411
Commit-ID:  760b61d76da6d6a99eb245ab61abf71ca5415cea
Gitweb:     http://git.kernel.org/tip/760b61d76da6d6a99eb245ab61abf71ca5415cea
Author:     Ard Biesheuvel <ard.biesheuvel@linaro.org>
AuthorDate: Fri, 18 Aug 2017 20:49:35 +0100
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 21 Aug 2017 09:43:49 +0200

efi/libstub/arm64: Use hidden attribute for struct screen_info reference

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 <mka@chromium.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20170818194947.19347-3-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/arm64/include/asm/efi.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index 8f3043a..464ac85 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -81,6 +81,9 @@ static inline unsigned long efi_get_max_initrd_addr(unsigned long dram_base,
 #define alloc_screen_info(x...)		&screen_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)
 {
 }

[toc] | [prev] | [next] | [standalone]


#1715413 — [PATCH 12/14] firmware: dcdbas: constify attribute_group structures.

FromArd Biesheuvel <ard.biesheuvel@linaro.org>
Date2017-08-18 22:00 +0200
Subject[PATCH 12/14] firmware: dcdbas: constify attribute_group structures.
Message-ID<ufVB1-89n-35@gated-at.bofh.it>
In reply to#1715397
From: Arvind Yadav <arvind.yadav.cs@gmail.com>

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by <linux/sysfs.h> work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Douglas_Warzecha <douglas_warzecha@dell.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 drivers/firmware/dcdbas.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/dcdbas.c b/drivers/firmware/dcdbas.c
index 2fe1a130189f..c16600f30611 100644
--- a/drivers/firmware/dcdbas.c
+++ b/drivers/firmware/dcdbas.c
@@ -534,7 +534,7 @@ static struct attribute *dcdbas_dev_attrs[] = {
 	NULL
 };
 
-static struct attribute_group dcdbas_attr_group = {
+static const struct attribute_group dcdbas_attr_group = {
 	.attrs = dcdbas_dev_attrs,
 	.bin_attrs = dcdbas_bin_attrs,
 };
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]


Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel


csiph-web