On Wed, 22 Jan 2025 at 13:25, Joel Granados wrote:
>
> On Tue, Jan 21, 2025 at 02:40:16PM +0100, Alexander Gordeev wrote:
> > On Fri, Jan 10, 2025 at 03:16:08PM +0100, Joel Granados wrote:
> >
> > Hi Joel,
> >
> > > Add the const qualifier to all the ctl_tables in the tree except for
> > > watchdo
On Wed, 11 Dec 2024 at 14:46, Greg Kroah-Hartman
wrote:
>
> On Wed, Dec 11, 2024 at 02:39:33PM +0100, Marek Marczykowski-Górecki wrote:
> > On Wed, Dec 11, 2024 at 01:37:52PM +0100, Ard Biesheuvel wrote:
> > > (cc Greg)
> > >
> > > On Wed, 11 Dec 20
(cc Greg)
On Wed, 11 Dec 2024 at 13:30, Marek Marczykowski-Górecki
wrote:
>
> On Wed, Dec 11, 2024 at 01:24:08PM +0100, Ard Biesheuvel wrote:
> > On Wed, 11 Dec 2024 at 12:53, Jürgen Groß wrote:
> > >
> > > Jason, Ard,
> > >
> > > I guess there
On Wed, 11 Dec 2024 at 12:53, Jürgen Groß wrote:
>
> Jason, Ard,
>
> I guess there are some prereq patches missing in stable 6.6.y branch?
>
>
> Juergen
>
> On 11.12.24 12:41, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > With Linux 6.6.64 I get the following crash on domU boot:
> >
> > (XEN)
On Tue, 29 Oct 2024 at 13:54, Jürgen Groß wrote:
>
> On 29.10.24 13:50, Ard Biesheuvel wrote:
> > On Wed, 9 Oct 2024 at 18:09, Ard Biesheuvel wrote:
> >>
..
> >
> > Ping?
>
> I have queued this series for 6.13.
>
Thanks!
On Wed, 9 Oct 2024 at 18:09, Ard Biesheuvel wrote:
>
> From: Ard Biesheuvel
>
> This series was broken out of the series I sent recently [0], after
> Jason pointed out that my Xen startup code changes conflict with his
> changes to make the PVH startup code position independent
From: Ard Biesheuvel
The .head.text section contains code that may execute from a different
address than it was linked at. This is fragile, given that the x86 ABI
can refer to global symbols via absolute or relative references, and the
toolchain assumes that these are interchangeable, which they
From: Ard Biesheuvel
Since commit
d9ec1158056b ("x86/boot/64: Use RIP_REL_REF() to assign 'phys_base'")
phys_base is assigned directly rather than added to, so it is no longer
necessary to clear it after use.
Reviewed-by: Jason Andryuk
Tested-by: Jason Andryuk
From: Ard Biesheuvel
Calling C code via a different mapping than it was linked at is
problematic, because the compiler assumes that RIP-relative and absolute
symbol references are interchangeable. GCC in particular may use
RIP-relative per-CPU variable references even when not using -fpic.
So
From: Ard Biesheuvel
Xen puts virtual and physical addresses into ELF notes that are treated
by the linker as relocatable by default. Doing so is not only pointless,
given that the ELF notes are only intended for consumption by Xen before
the kernel boots. It is also a KASLR leak, given that the
From: Ard Biesheuvel
The limit field in a GDT descriptor is an inclusive bound, and therefore
one less than the size of the covered range.
Reviewed-by: Jason Andryuk
Tested-by: Jason Andryuk
Signed-off-by: Ard Biesheuvel
---
arch/x86/platform/pvh/head.S | 2 +-
1 file changed, 1 insertion
From: Ard Biesheuvel
This series was broken out of the series I sent recently [0], after
Jason pointed out that my Xen startup code changes conflict with his
changes to make the PVH startup code position independent.
Jason's work reduces the delta of my changes, and given that my other
s
On Sat, 28 Sept 2024 at 15:41, Brian Gerst wrote:
>
> On Wed, Sep 25, 2024 at 2:33 PM Uros Bizjak wrote:
> >
> > On Wed, Sep 25, 2024 at 5:02 PM Ard Biesheuvel wrote:
> > >
> > > From: Ard Biesheuvel
> > >
> > > Specify the gua
On Wed, 2 Oct 2024 at 22:02, Linus Torvalds
wrote:
>
> On Wed, 2 Oct 2024 at 08:31, Ard Biesheuvel wrote:
> >
> > I guess you are referring to the use of a GOT? That is a valid
> > concern, but it does not apply here. With hidden visibility and
> > compiler comm
On Wed, 2 Oct 2024 at 23:25, Jason Andryuk wrote:
>
> On 2024-09-30 03:15, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel
> >
> > Xen puts virtual and physical addresses into ELF notes that are treated
> > by the linker as relocatable by default. Doing so is not
Hi Peter,
Thanks for taking a look.
On Tue, 1 Oct 2024 at 23:13, H. Peter Anvin wrote:
>
> On 9/25/24 08:01, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel
> >
> > As an intermediate step towards enabling PIE linking for the 64-bit x86
> > kernel, enable PIE co
On Tue, 1 Oct 2024 at 09:18, Josh Poimboeuf wrote:
>
> On Wed, Sep 25, 2024 at 05:01:24PM +0200, Ard Biesheuvel wrote:
> > + if (insn->type == INSN_CALL_DYNAMIC) {
> > + if (!reloc)
> > +
On Tue, 1 Oct 2024 at 07:33, Josh Poimboeuf wrote:
>
> On Wed, Sep 25, 2024 at 05:01:04PM +0200, Ard Biesheuvel wrote:
> > + if (r_type == R_X86_64_GOTPCREL) {
> > + Elf_Shdr *s = &secs[sec->shdr.sh_info].shdr;
> > +
From: Ard Biesheuvel
Xen puts virtual and physical addresses into ELF notes that are treated
by the linker as relocatable by default. Doing so is not only pointless,
given that the ELF notes are only intended for consumption by Xen before
the kernel boots. It is also a KASLR leak, given that the
From: Ard Biesheuvel
Since commit
d9ec1158056b ("x86/boot/64: Use RIP_REL_REF() to assign 'phys_base'")
phys_base is assigned directly rather than added to, so it is no longer
necessary to clear it after use.
Reviewed-by: Jason Andryuk
Tested-by: Jason Andryuk
From: Ard Biesheuvel
Calling C code via a different mapping than it was linked at is
problematic, because the compiler assumes that RIP-relative and absolute
symbol references are interchangeable. GCC in particular may use
RIP-relative per-CPU variable references even when not using -fpic.
So
From: Ard Biesheuvel
The .head.text section contains code that may execute from a different
address than it was linked at. This is fragile, given that the x86 ABI
can refer to global symbols via absolute or relative references, and the
toolchain assumes that these are interchangeable, which they
From: Ard Biesheuvel
The limit field in a GDT descriptor is an inclusive bound, and therefore
one less than the size of the covered range.
Reviewed-by: Jason Andryuk
Tested-by: Jason Andryuk
Signed-off-by: Ard Biesheuvel
---
arch/x86/platform/pvh/head.S | 2 +-
1 file changed, 1 insertion
From: Ard Biesheuvel
This series was broken out of the series I sent last week [0], after
Jason pointed out that my Xen startup code changes conflict with his
changes to make the PVH startup code position independent.
Jason's work reduces the delta of my changes, and given that my other
s
On Fri, 27 Sept 2024 at 07:49, Ard Biesheuvel wrote:
>
> On Fri, 27 Sept 2024 at 03:47, Jason Andryuk wrote:
> >
> > On 2024-09-26 06:41, Ard Biesheuvel wrote:
> > > From: Ard Biesheuvel
> > >
> > > Xen puts virtual and physical addresses into ELF
On Fri, 27 Sept 2024 at 03:47, Jason Andryuk wrote:
>
> On 2024-09-26 06:41, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel
> >
> > Xen puts virtual and physical addresses into ELF notes that are treated
> > by the linker as relocatable by default. Doing so is not
On Wed, 25 Sept 2024 at 22:25, Vegard Nossum wrote:
>
>
> On 25/09/2024 17:01, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel
> >
> > Build the kernel as a Position Independent Executable (PIE). This
> > results in more efficient relocation processing for th
On Thu, 26 Sept 2024 at 12:41, Ard Biesheuvel wrote:
>
> From: Ard Biesheuvel
>
> Calling C code via a different mapping than it was linked at is
> problematic, because the compiler assumes that RIP-relative and absolute
> symbol references are interchangeable. GCC in partic
From: Ard Biesheuvel
The size field in a GDT descriptor is offset by 1, so subtract 1 from
the calculated range.
Signed-off-by: Ard Biesheuvel
---
arch/x86/platform/pvh/head.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform
From: Ard Biesheuvel
Xen puts virtual and physical addresses into ELF notes that are treated
by the linker as relocatable by default. Doing so is not only pointless,
given that the ELF notes are only intended for consumption by Xen before
the kernel boots. It is also a KASLR leak, given that the
From: Ard Biesheuvel
The .head.text section contains code that may execute from a different
address than it was linked at. This is fragile, given that the x86 ABI
can refer to global symbols via absolute or relative references, and the
toolchain assumes that these are interchangeable, which they
From: Ard Biesheuvel
Since commit
d9ec1158056b ("x86/boot/64: Use RIP_REL_REF() to assign 'phys_base'")
phys_base is assigned directly rather than added to, so it is no longer
necessary to clear it after use.
Signed-off-by: Ard Biesheuvel
---
arch/x86/platform/pvh/h
From: Ard Biesheuvel
Calling C code via a different mapping than it was linked at is
problematic, because the compiler assumes that RIP-relative and absolute
symbol references are interchangeable. GCC in particular may use
RIP-relative per-CPU variable references even when not using -fpic.
So
From: Ard Biesheuvel
This series was broken out of the series I sent yesterday [0], after
Jason pointed out that my Xen startup code changes conflict with his
changes to make the PVH startup code position independent.
Jason's work reduces the delta of my changes, and given that my other
s
On Wed, 25 Sept 2024 at 23:11, Jason Andryuk wrote:
>
> Hi Ard,
>
> On 2024-09-25 11:01, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel
> >
> > The .head.text section contains code that may execute from a different
> > address than it was linked at. Thi
On Wed, 25 Sept 2024 at 21:39, Uros Bizjak wrote:
>
> On Wed, Sep 25, 2024 at 9:14 PM Ard Biesheuvel wrote:
> >
> > On Wed, 25 Sept 2024 at 20:54, Uros Bizjak wrote:
> > >
> > > On Wed, Sep 25, 2024 at 5:02 PM Ard Biesheuvel
> > >
On Wed, 25 Sept 2024 at 20:54, Uros Bizjak wrote:
>
> On Wed, Sep 25, 2024 at 5:02 PM Ard Biesheuvel wrote:
> >
> > From: Ard Biesheuvel
> >
> > Build the kernel as a Position Independent Executable (PIE). This
> > results in more efficient relocation process
On Wed, 25 Sept 2024 at 17:54, Ian Rogers wrote:
>
> On Wed, Sep 25, 2024 at 8:02 AM Ard Biesheuvel wrote:
> >
> > From: Ard Biesheuvel
> >
> > Specify the guard symbol for the stack cookie explicitly, rather than
> > positioning it exactly 40 bytes int
On Wed, 25 Sept 2024 at 18:39, Linus Torvalds
wrote:
>
> On Wed, 25 Sept 2024 at 08:16, Ard Biesheuvel wrote:
> >
> > Instead of pushing an immediate absolute address, which is incompatible
> > with PIE codegen or linking, use a LEA instruction to take the address
&g
From: Ard Biesheuvel
The relocs tool is no longer used on vmlinux, which is the only 64-bit
ELF executable that it used to operate on in the 64-bit build. (It is
still used for parts of the decompressor)
So drop the 64-bit handling - it is dead code now.
Signed-off-by: Ard Biesheuvel
From: Ard Biesheuvel
Build the kernel as a Position Independent Executable (PIE). This
results in more efficient relocation processing for the virtual
displacement of the kernel (for KASLR). More importantly, it instructs
the linker to generate what is actually needed (a program that can be
From: Ard Biesheuvel
Instead of pushing an immediate absolute address, which is incompatible
with PIE codegen or linking, use a LEA instruction to take the address
into a register.
Signed-off-by: Ard Biesheuvel
---
arch/x86/kernel/rethook.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
From: Ard Biesheuvel
Calling C code via a different mapping than it was linked at is
problematic, because the compiler assumes that RIP-relative and absolute
symbol references are interchangeable. GCC in particular may use
RIP-relative per-CPU variable references even when not using -fpic.
So
From: Ard Biesheuvel
Due to the placement of per-CPU variables in a special, 0x0 based
disjoint memory segment in the ELF binary, the KASLR relocation tool
needed to perform special processing for references to such variables,
as they were not affected by KASLR displacement.
This meant that
From: Ard Biesheuvel
Specify the guard symbol for the stack cookie explicitly, rather than
positioning it exactly 40 bytes into the per-CPU area. Doing so removes
the need for the per-CPU region to be absolute rather than relative to
the placement of the per-CPU template region in the kernel
From: Ard Biesheuvel
In some cases, LLVM's lld linker may emit the following symbol into the
symbol table
? _GLOBAL_OFFSET_TABLE_
and its presence throws off the relative base logic in kallsyms. Since
0x0 is never a valid relative base, just ignore it.
Signed-off-by
From: Ard Biesheuvel
Add support for standard dynamic ELF relocations to perform the virtual
relocation of the core kernel at boot. The RELR format results in a 10x
reduction in memory footprint of the relocation data, and can be
generated by the linker directly. This removes the need for
a) a
From: Ard Biesheuvel
Use ordinary RIP-relative references to make the code compatible with
running the linker in PIE mode.
Note that wakeup_long64() runs in the kernel's ordinary virtual mapping
so there is no need to record the address of .Lresume_point in a global
variable. And fi
From: Ard Biesheuvel
Use RIP-relative symbol references to make them compatible with running
the linker in PIE mode.
Signed-off-by: Ard Biesheuvel
---
arch/x86/kernel/head_64.S| 14 +-
arch/x86/kernel/relocate_kernel_64.S | 6 --
2 files changed, 13 insertions
From: Ard Biesheuvel
As an intermediate step towards enabling PIE linking for the 64-bit x86
kernel, enable PIE codegen for all objects that are linked into the
kernel proper.
This substantially reduces the number of relocations that need to be
processed when booting a relocatable KASLR kernel
From: Ard Biesheuvel
Fix up a couple of occurrences in the x86_64 entry code where we take
the absolute address of a symbol while we could use RIP-relative
addressing just the same. This avoids relocation fixups at boot for
these quantities.
Signed-off-by: Ard Biesheuvel
---
arch/x86/entry
From: Ard Biesheuvel
In some cases, the compiler may rely on indirect calls using GOT slots
as memory operands to emit function calls. This leaves it up to the
linker to relax the call to a direct call if possible, i.e., if the
destination address is known at link time and in range, which may
From: Ard Biesheuvel
The .head.text section contains code that may execute from a different
address than it was linked at. This is fragile, given that the x86 ABI
can refer to global symbols via absolute or relative references, and the
toolchain assumes that these are interchangeable, which they
From: Ard Biesheuvel
When running the compiler in PIC/PIE mode, it will emit data objects
that are 'const' in the context of the program into the .data.rel.ro
section if they contain absolute addresses of statically allocated
global objects. This helps the dynamic loader distingui
From: Ard Biesheuvel
The code in .head.text executes from a 1:1 mapping and cannot generally
refer to global variables using their kernel virtual addresses. However,
there are some occurrences of such references that are valid: the kernel
virtual addresses of _text and _end are needed to
From: Ard Biesheuvel
Use RIP-relative accesses and avoid fixups at runtime.
Signed-off-by: Ard Biesheuvel
---
arch/x86/include/asm/sync_core.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/sync_core.h b/arch/x86/include/asm/sync_core.h
index
From: Ard Biesheuvel
SMP on x86_64 no longer needs absolute per-CPU variables, so this
support can be dropped from kallsyms as well, as no other architectures
rely on this functionality.
Signed-off-by: Ard Biesheuvel
---
init/Kconfig| 4 --
kernel/kallsyms.c | 12
From: Ard Biesheuvel
objtool generates ELF sections such as __mcount_loc, which carry
absolute symbol references that need to be fixed up at boot time, based
on the actual virtual placement of the kernel binary.
This involves writing to the section at boot time, and in some cases
(e.g., when
From: Ard Biesheuvel
Use RIP-relative accesses and 32-bit offsets for .tracedata, to avoid
the need for relocation fixups at boot time.
Signed-off-by: Ard Biesheuvel
---
arch/x86/include/asm/pm-trace.h | 4 ++--
drivers/base/power/trace.c | 6 +++---
2 files changed, 5 insertions(+), 5
From: Ard Biesheuvel
For historic reasons, per-CPU symbols on x86_64 are emitted in an
address space that is disjoint from the ordinary kernel VA space,
starting at address 0x0. This splits a per-CPU symbol reference into a
base plus offset, where the base is programmed into the GS segment
From: Ard Biesheuvel
Replace some absolute symbol references with RIP-relative ones, so we
don't need to fix them up at boot.
Signed-off-by: Ard Biesheuvel
---
arch/x86/power/hibernate_asm_64.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/
From: Ard Biesheuvel
Xen puts virtual and physical addresses into ELF notes that are treated
by the linker as relocatable by default. Doing so is not only pointless,
given that the ELF notes are only intended for consumption by Xen before
the kernel boots. It is also a KASLR leak, given that the
From: Ard Biesheuvel
Implicit absolute symbol references (e.g., taking the address of a
global variable) must be avoided in the C code that runs from the early
1:1 mapping of the kernel, given that this is a practice that violates
assumptions on the part of the toolchain. I.e., RIP-relative and
From: Ard Biesheuvel
Some of the early x86_64 startup code is written in C, and executes in
the early 1:1 mapping of the kernel, which is not the address it was
linked at, and this requires special care when accessing global
variables. This is currently being dealt with on an ad-hoc basis
From: Ard Biesheuvel
Avoid absolute references in code, which require fixing up at boot time,
and replace them with RIP-relative ones. In this particular case, due to
the register pressure, they cannot be avoided entirely, so one absolute
reference is retained but the resulting reference via the
From: Ard Biesheuvel
Bump the minimum GCC version to 8.1 to gain unconditional support for
referring to the per-task stack cookie using a symbol rather than
relying on the fixed offset of 40 bytes from %GS, which requires
elaborate hacks to support.
Signed-off-by: Ard Biesheuvel
From: Ard Biesheuvel
The x86_64 port has a number of historical quirks that result in a
reliance on toolchain features that are either poorly specified or
basically implementation details of the toolchain:
- the 'kernel' C model implemented by the compiler is intended for
position
From: Ard Biesheuvel
Instead of relying on fseek() and fread() to traverse the vmlinux file
when processing the ELF relocations, mmap() the whole thing and use
memcpy() or direct references where appropriate:
- the executable and section headers are byte swabbed before use if the
host is big
On Thu, 13 Jul 2023 at 12:48, Xenia Ragiadakou wrote:
>
> Currently, resuming an S3 suspended guest results in the following
> assertion failure:
> ASSERT
> MdePkg/Library/PeiResourcePublicationLib/PeiResourcePublicationLib.c(41):
> MemoryLength > 0
> This happens because some parts of the S3 su
On Thu, 19 Jan 2023 at 20:04, Demi Marie Obenour
wrote:
>
> This patch series fixes handling of EFI tables when running under Xen.
> These fixes allow the ESRT to be loaded when running paravirtualized in
> dom0, making the use of EFI capsule updates possible.
>
> Demi Marie Obenour (5):
> efi:
On Thu, 6 Oct 2022 at 19:22, Demi Marie Obenour
wrote:
>
> On Thu, Oct 06, 2022 at 06:19:35PM +0200, Ard Biesheuvel wrote:
> > On Thu, 6 Oct 2022 at 16:43, Demi Marie Obenour
> > wrote:
> > >
> > > On Thu, Oct 06, 2022 at 09:31:47AM +0200, Ard Biesheuvel wro
On Thu, 6 Oct 2022 at 16:43, Demi Marie Obenour
wrote:
>
> On Thu, Oct 06, 2022 at 09:31:47AM +0200, Ard Biesheuvel wrote:
> > On Thu, 6 Oct 2022 at 03:41, Demi Marie Obenour
> > wrote:
> > >
> > > On Wed, Oct 05, 2022 at 11:28:29PM +0200, Ard Biesheuvel wro
On Thu, 6 Oct 2022 at 03:41, Demi Marie Obenour
wrote:
>
> On Wed, Oct 05, 2022 at 11:28:29PM +0200, Ard Biesheuvel wrote:
> > On Wed, 5 Oct 2022 at 20:11, Demi Marie Obenour
> > wrote:
> > >
> > > On Wed, Oct 05, 2022 at 08:15:07AM +0200, Jan Beulich wrot
On Wed, 5 Oct 2022 at 20:11, Demi Marie Obenour
wrote:
>
> On Wed, Oct 05, 2022 at 08:15:07AM +0200, Jan Beulich wrote:
> > On 04.10.2022 17:46, Demi Marie Obenour wrote:
> > > Linux has a function called efi_mem_reserve() that is used to reserve
> > > EfiBootServicesData memory that contains e.g.
On Mon, 3 Oct 2022 at 18:23, Demi Marie Obenour
wrote:
>
> On Mon, Oct 03, 2022 at 05:59:52PM +0200, Ard Biesheuvel wrote:
> > On Mon, 3 Oct 2022 at 17:29, Demi Marie Obenour
> > wrote:
> > >
> > > On Mon, Oct 03, 2022 at 01:26:24PM +0200, Ard Biesheuvel wro
On Mon, 3 Oct 2022 at 17:29, Demi Marie Obenour
wrote:
>
> On Mon, Oct 03, 2022 at 01:26:24PM +0200, Ard Biesheuvel wrote:
> > Xen on x86 boots dom0 in EFI mode but without providing a memory map.
> > This means that some sanity checks we would like to perform on
> > confi
On Mon, 3 Oct 2022 at 17:18, Demi Marie Obenour
wrote:
>
> On Mon, Oct 03, 2022 at 01:26:23PM +0200, Ard Biesheuvel wrote:
> > The ESRT code currently contains some sanity checks on the memory
> > descriptor it obtains, but these can only trigger when the descriptor is
>
-off-by: Demi Marie Obenour
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/efi.c | 7 ++
drivers/xen/efi.c | 24
include/linux/efi.h| 2 ++
3 files changed, 33 insertions(+)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
pages reaches
beyond the end of the address space. Note that the memory map as a whole
could still be inconsistent, i.e., multiple entries might cover the same
area, or the address could be outside of the addressable VA space, but
validating that goes beyond the scope of these helpers.
Signed-off-by
let's wire that up instead.
Co-developed-by: Demi Marie Obenour
Signed-off-by: Demi Marie Obenour
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/efi.c | 5 ++-
drivers/xen/efi.c | 34
include/linux/efi.h| 1 +
3 files changed, 39 insertions(
The EFI memory map is a description of the memory layout as provided by
the firmware, and only x86 manipulates it in various different ways for
its own memory bookkeeping. So let's move the memmap routines that are
only used by x86 into the x86 arch tree.
Signed-off-by: Ard Biesheuvel
---
o the x86 arch tree, where it
arguably belongs.
Signed-off-by: Ard Biesheuvel
---
arch/x86/Kconfig | 20 +
arch/x86/include/asm/efi.h | 5 ++
arch/x86/kernel/setup.c| 1 +
arch/x86/platfor
x27;s fix this inconsistency, and always set this flag when booting dom0
via the EFI boot path. Note that Xen on x86 does not provide the EFI
memory map in this case, whereas other architectures do, so move the
associated EFI_PARAVIRT check into the x86 platform code.
Signed-off-by: Ard Biesh
s
Cc: Stefano Stabellini
Cc: Oleksandr Tyshchenko
Cc: Kees Cook
Cc: Anton Vorontsov
Cc: Colin Cross
Cc: Tony Luck
Cc: Marek Marczykowski-Górecki
Ard Biesheuvel (6):
efi: Move EFI fake memmap support into x86 arch tree
efi: memmap: Move manipulation routines into x86 arch tree
efi: xen
On Sun, 2 Oct 2022 at 23:43, Ard Biesheuvel wrote:
>
> On Sun, 2 Oct 2022 at 18:28, Demi Marie Obenour
> wrote:
> >
> > On Sun, Oct 02, 2022 at 11:56:26AM +0200, Ard Biesheuvel wrote:
> > > In order to permit the ESRT to be used when doing pseudo-EFI boot
>
On Sun, 2 Oct 2022 at 18:28, Demi Marie Obenour
wrote:
>
> On Sun, Oct 02, 2022 at 11:56:26AM +0200, Ard Biesheuvel wrote:
> > In order to permit the ESRT to be used when doing pseudo-EFI boot
> > without a EFI memory map, e.g., when booting inside a Xen dom0 on x86,
> >
On Sun, 2 Oct 2022 at 18:28, Demi Marie Obenour
wrote:
>
> On Sun, Oct 02, 2022 at 11:56:25AM +0200, Ard Biesheuvel wrote:
> > As it turns out, Xen does not guarantee that EFI bootservices data
> > regions in memory are preserved, which means that EFI configuration
> > t
this in its xen_efi_config_table_is_valid() helper, or provide
a EFI memory map like it does on other architectures.
Co-developed-by: Demi Marie Obenour
Signed-off-by: Demi Marie Obenour
Signed-off-by: Ard Biesheuvel
---
arch/x86/platform/efi/quirks.c | 3 +
drivers/firmware/efi/esrt.c
ff-by: Demi Marie Obenour
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/efi.c | 7 ++
drivers/xen/efi.c | 69
include/linux/efi.h| 2 +
3 files changed, 78 insertions(+)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
The EFI memory map is a description of the memory layout as provided by
the firmware, and only x86 manipulates it in various different ways for
its own memory bookkeeping. So let's move the memmap routines that are
only used by x86 into the x86 arch tree.
Signed-off-by: Ard Biesheuvel
---
x27;s fix this inconsistency, and always set this flag when booting dom0
via the EFI boot path. Note that Xen on x86 does not provide the EFI
memory map in this case, whereas other architectures do, so move the
associated EFI_PARAVIRT check into the x86 platform code.
Signed-off-by: Ard Biesh
o the x86 arch tree, where it
arguably belongs.
Signed-off-by: Ard Biesheuvel
---
arch/x86/Kconfig | 20 +
arch/x86/include/asm/efi.h | 5 ++
arch/x86/kernel/setup.c| 1 +
arch/x86/platfor
efano Stabellini
Cc: Oleksandr Tyshchenko
Cc: Kees Cook
Cc: Anton Vorontsov
Cc: Colin Cross
Cc: Tony Luck
Cc: Marek Marczykowski-Górecki
Ard Biesheuvel (5):
efi: Move EFI fake memmap support into x86 arch tree
efi: memmap: Move manipulation routines into x86 arch tree
efi: xen: Set EFI_PARAVIR
On Fri, 30 Sept 2022 at 22:59, Ard Biesheuvel wrote:
>
> On Fri, 30 Sept 2022 at 22:21, Demi Marie Obenour
> wrote:
> >
> > On Fri, Sep 30, 2022 at 09:11:19PM +0200, Ard Biesheuvel wrote:
> > > On Fri, 30 Sept 2022 at 20:21, Demi Marie Obenour
> > > wrot
On Fri, 30 Sept 2022 at 22:21, Demi Marie Obenour
wrote:
>
> On Fri, Sep 30, 2022 at 09:11:19PM +0200, Ard Biesheuvel wrote:
> > On Fri, 30 Sept 2022 at 20:21, Demi Marie Obenour
> > wrote:
> > >
> > > On Fri, Sep 30, 2022 at 06:36:11PM +0200, Ard Biesheuvel
On Fri, 30 Sept 2022 at 20:21, Demi Marie Obenour
wrote:
>
> On Fri, Sep 30, 2022 at 06:36:11PM +0200, Ard Biesheuvel wrote:
> > On Fri, 30 Sept 2022 at 01:02, Demi Marie Obenour
> > wrote:
> > >
> > > fwupd requires access to the EFI System Resource Table (ES
On Fri, 30 Sept 2022 at 20:17, Demi Marie Obenour
wrote:
>
> On Fri, Sep 30, 2022 at 06:25:53PM +0200, Ard Biesheuvel wrote:
> > On Fri, 30 Sept 2022 at 01:02, Demi Marie Obenour
> > wrote:
> > >
> > > Memory of type EFI_CONVENTIONAL_MEMO
On Fri, 30 Sept 2022 at 19:12, Demi Marie Obenour
wrote:
>
> On Fri, Sep 30, 2022 at 06:30:57PM +0200, Ard Biesheuvel wrote:
> > On Fri, 30 Sept 2022 at 08:44, Jan Beulich wrote:
> > >
> > > On 30.09.2022 01:02, Demi Marie Obenour wrote:
> > > &
On Fri, 30 Sept 2022 at 01:02, Demi Marie Obenour
wrote:
>
> fwupd requires access to the EFI System Resource Table (ESRT) to
> discover which firmware can be updated by the OS. Currently, Linux does
> not expose the ESRT when running as a Xen dom0. Therefore, it is not
> possible to use fwupd i
On Fri, 30 Sept 2022 at 08:44, Jan Beulich wrote:
>
> On 30.09.2022 01:02, Demi Marie Obenour wrote:
> > Memory of type EFI_CONVENTIONAL_MEMORY, EFI_LOADER_CODE, EFI_LOADER_DATA,
> > EFI_BOOT_SERVICES_CODE, and EFI_BOOT_SERVICES_DATA may be clobbered by
> > Xen before Linux gets to start using it.
1 - 100 of 129 matches
Mail list logo
