On Fri, 18 Jan 2019 at 19:30, Julien Grall wrote:
>
> Hi all,
>
> I am trying to boot a Xen guest using the latest EDK2 master (cce9d76358
> "BaseTools: Allow empty value for HiiPcd in Dsc"), GRUB and Linux 5.0-rc2.
>
> The last code executed by Linux is when installing the virtual address
> map i
On Fri, 18 Jan 2019 at 19:39, Ard Biesheuvel wrote:
>
> On Fri, 18 Jan 2019 at 19:30, Julien Grall wrote:
> >
> > Hi all,
> >
> > I am trying to boot a Xen guest using the latest EDK2 master (cce9d76358
> > "BaseTools: Allow empty value for HiiPcd in D
On Wed, 23 Jan 2019 at 13:09, Jann Horn wrote:
>
> On Wed, Jan 23, 2019 at 1:04 PM Greg KH wrote:
> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> > > Variables declared in a switch statement before any case statements
> > > cannot be initialized, so move all instances out of the
.tianocore.org/show_bug.cgi?id=1654>, and
> this series intends to address that -- i.e., to replace the MIT license
> blocks with the corresponding SPDX License IDs.
>
> Cc: Anthony Perard
> Cc: Ard Biesheuvel
> Cc: Jordan Justen
> Cc: Julien Grall
> Cc: Lars Ku
On Wed, 10 Apr 2019 at 07:27, Laszlo Ersek wrote:
>
> On 04/10/19 11:48, Jordan Justen wrote:
> > On 2019-04-09 04:08:15, Anthony PERARD wrote:
> >> This is a copy of OvmfX64, removing VirtIO and some SMM.
> >>
> >> This new platform will be changed to make it works on two types of Xen
> >> guest:
On 11 April 2018 at 10:56, Daniel Kiper wrote:
> On Wed, Apr 04, 2018 at 12:38:24PM +0200, Daniel Kiper wrote:
>> On Tue, Apr 03, 2018 at 10:00:52AM -0700, James Bottomley wrote:
>> > On Tue, 2018-04-03 at 18:07 +0200, Daniel Kiper wrote:
>> > > On Tue, Apr 03, 2018 at 08:44:41AM -0700, James Bott
On 9 January 2018 at 14:22, Daniel Kiper wrote:
> Hi,
>
> Initialize UEFI secure boot state during dom0 boot. Otherwise the kernel
> may not even know that it runs on secure boot enabled platform.
>
Hi Daniel,
I must say, I am not too thrilled with the approach you have chosen
here. #including .
On 12 January 2018 at 11:24, Daniel Kiper wrote:
> Hi Ard,
>
> On Thu, Jan 11, 2018 at 12:51:07PM +0000, Ard Biesheuvel wrote:
>> On 9 January 2018 at 14:22, Daniel Kiper wrote:
>> > Hi,
>> >
>> > Initialize UEFI secure boot state during dom0 boot. O
On Thu, 30 Apr 2020 at 13:15, Daniel Kiper wrote:
>
> Adding Ard...
>
> On Thu, Apr 30, 2020 at 09:01:45AM +0200, Jan Beulich wrote:
> > On 30.04.2020 00:51, Bobby Eshleman wrote:
> > > Hey all,
> > >
> > > We're looking to develop UEFI Secure Boot support for grub-loaded Xen and
> > > ultimately
On Tue, 5 May 2020 at 23:58, Bobby Eshleman wrote:
>
> On Thu, Apr 30, 2020 at 01:41:12PM +0200, Ard Biesheuvel wrote:
> > On Thu, 30 Apr 2020 at 13:15, Daniel Kiper wrote:
> > > Anyway, the advantage of this new protocol is that it uses UEFI API to
> > > load
Now that we have a static inline helper to discover the platform's secure
boot mode that can be shared between the EFI stub and the kernel proper,
switch to it, and drop some comments about keeping them in sync manually.
Signed-off-by: Ard Biesheuvel
---
arch/x86/xen/
On Thu, 5 Nov 2020 at 00:53, wrote:
>
>
> On 11/4/20 5:14 PM, Ard Biesheuvel wrote:
> > Now that we have a static inline helper to discover the platform's secure
> > boot mode that can be shared between the EFI stub and the kernel proper,
> > switch to it, and
Hi Marek,
On Sun, 16 Aug 2020 at 02:20, Marek Marczykowski-Górecki
wrote:
>
> In case of Xen PV dom0, Xen passes along info about system tables (see
> arch/x86/xen/efi.c), but not the memory map from EFI. This makes sense
> as it is Xen responsible for managing physical memory address space.
> In
On Thu, 20 Aug 2020 at 11:30, Roger Pau Monné wrote:
>
> On Wed, Aug 19, 2020 at 01:33:39PM +0200, Norbert Kaminski wrote:
> >
> > On 19.08.2020 10:19, Roger Pau Monné wrote:
> > > On Tue, Aug 18, 2020 at 08:40:18PM +0200, Marek Marczykowski-Górecki
> > > wrote:
> > > > On Tue, Aug 18, 2020 at 07
On Fri, 10 Jul 2020 at 13:17, Bartlomiej Zolnierkiewicz
wrote:
>
>
> [ added EFI Maintainer & ML to Cc: ]
>
> Hi,
>
> On 7/9/20 11:17 AM, Jürgen Groß wrote:
> > On 28.06.20 10:50, Jürgen Groß wrote:
> >> Ping?
> >>
> >> On 10.06.20 16:10, Juergen Gross wrote:
> >>> efifb_probe() will issue an erro
On Fri, 10 Jul 2020 at 16:38, Jürgen Groß wrote:
>
> On 10.07.20 15:27, Ard Biesheuvel wrote:
> > On Fri, 10 Jul 2020 at 13:17, Bartlomiej Zolnierkiewicz
> > wrote:
> >>
> >>
> >> [ added EFI Maintainer & ML to Cc: ]
> >>
> >
gt; Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when
> mapping the FB")
> Signed-off-by: Juergen Gross
Acked-by: Ard Biesheuvel
> ---
> drivers/video/fbdev/efifb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dri
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
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
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
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
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
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
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
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
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
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
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
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
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, 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
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
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
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
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 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
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
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 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 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 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 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;
> > +
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
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
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
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
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
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
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
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 .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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
On Thu, 11 Aug 2022 at 16:59, Bertrand Marquis wrote:
>
> Hi Leon,
>
> > On 11 Aug 2022, at 15:17, Leo Yan wrote:
> >
> > Hi Bertrand, Rahul,
> >
> > On Fri, Aug 05, 2022 at 12:05:23PM +, Bertrand Marquis wrote:
> >>> On 5 Aug 2022, at 12:44, Rahul Singh wrote:
> >
> > [...]
> >
> Looke
is patch adds a MEMRESERVE configuration table into the system table,
> > it points to a dummy data structure acpi_table_memreserve, this
> > structure has the consistent definition with the Linux kernel.
> > Following the method in Xen, it creates a table entry for the structure
> &g
On Thu, 18 Aug 2022 at 11:15, Leo Yan wrote:
>
> Hi Ard,
>
> On Wed, Aug 17, 2022 at 03:49:32PM +0200, Ard Biesheuvel wrote:
>
> [...]
>
> > > This header holds ACPI spec defined data structures. This one looks
> > > to be a Linux one, and hence shouldn&#
On Thu, 18 Aug 2022 at 17:49, Leo Yan wrote:
>
> On Thu, Aug 18, 2022 at 11:04:48AM +0100, Julien Grall wrote:
>
> [...]
>
> > > > Seems it's broken for kdump/kexec if kernel boots with using DT?
> > > >
> > >
> > > EFI supports both DT and ACPI boot, but only ACPI *requires* EFI.
> > >
> > > So D
On Sun, 28 Aug 2022 at 04:52, Demi Marie Obenour
wrote:
>
> This is needed for fwupd to work in Qubes OS.
>
Please elaborate on:
- the current situation
- why this is a problem
- why your approach is a reasonable solution.
> Signed-off-by: Demi Marie Obenour
> ---
> Changes since v1:
>
> - Use
On Tue, 6 Sept 2022 at 09:17, Leo Yan wrote:
>
> Hi Marc,
>
> On Tue, Sep 06, 2022 at 07:27:17AM +0100, Marc Zyngier wrote:
> > On Tue, 06 Sep 2022 03:52:37 +0100,
> > Leo Yan wrote:
> > >
> > > On Thu, Aug 25, 2022 at 10:40:41PM +0800, Leo Yan wrote:
> > >
> > > [...]
> > >
> > > > > > But here
Hello Demi,
On Mon, 19 Sept 2022 at 21:33, 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 t
On Tue, 20 Sept 2022 at 17:54, Jan Beulich wrote:
>
> On 20.09.2022 17:36, Ard Biesheuvel wrote:
> > On Mon, 19 Sept 2022 at 21:33, Demi Marie Obenour
> > wrote:
> >>
> >> fwupd requires access to the EFI System Resource Table (ESRT) to
> >> dis
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, 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, 22 Sept 2022 at 16:56, Demi Marie Obenour
wrote:
>
> On Thu, Sep 22, 2022 at 08:12:14AM +0200, Jan Beulich wrote:
> > On 22.09.2022 03:09, Demi Marie Obenour wrote:
> > > On Wed, Sep 21, 2022 at 10:34:04PM +0200, Jan Beulich wrote:
> > >> On 20.09
On Thu, 22 Sept 2022 at 20:12, Demi Marie Obenour
wrote:
>
> On Thu, Sep 22, 2022 at 05:05:43PM +0200, Ard Biesheuvel wrote:
> > On Thu, 22 Sept 2022 at 16:56, Demi Marie Obenour
> > wrote:
> > >
> > > On Thu, Sep 22, 2022 at 08:12:14AM +0200, Jan Beulich wrot
On Fri, 23 Sept 2022 at 01:27, Demi Marie Obenour
wrote:
>
> On Fri, Sep 23, 2022 at 12:14:50AM +0200, Ard Biesheuvel wrote:
> > On Thu, 22 Sept 2022 at 20:12, Demi Marie Obenour
> > wrote:
> > >
> > > On Thu, Sep 22, 2022 at 05:05:43PM +0200, Ard Biesheuvel
On Fri, 30 Sept 2022 at 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. Therefore, Linux under Xen
> must not use EFI
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.
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 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 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 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
1 - 100 of 129 matches
Mail list logo
