On 14.05.2025 08:31, Orzel, Michal wrote:
> On 14/05/2025 02:07, Stefano Stabellini wrote:
>> On Tue, 13 May 2025, Stewart Hildebrand wrote:
>>> All functions in dom0less-build.c should be __init.
> Why? This patch is first in your series and by that time there is no build
> time
> enforcement. To
On 13.05.2025 19:18, Stewart Hildebrand wrote:
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -730,8 +730,8 @@ static int __init domain_p2m_set_allocation(struct domain
> *d, uint64_t mem,
> return rc;
> }
> #else /* !CONFIG_ARCH_PAGING_
On 13.05.2025 21:54, Stewart Hildebrand wrote:
> --- a/xen/common/rangeset.c
> +++ b/xen/common/rangeset.c
> @@ -433,6 +433,20 @@ bool rangeset_is_empty(
> return ((r == NULL) || list_empty(&r->range_list));
> }
>
> +int rangeset_count_ranges(const struct rangeset *r)
> +{
> +int nr = 0
On 13.05.2025 19:05, Sergii Dmytruk wrote:
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -542,6 +542,21 @@ F: */configure
> F: */*.ac
> F: tools/
>
> +TRENCHBOOT SECURE LAUNCH
> +M: Daniel P. Smith
> +R: Ross Philipson
> +R: Sergii Dmytruk
> +S: Supported
> +F: xen/include
On 14/05/2025 02:07, Stefano Stabellini wrote:
> On Tue, 13 May 2025, Stewart Hildebrand wrote:
>> All functions in dom0less-build.c should be __init.
Why? This patch is first in your series and by that time there is no build time
enforcement. Together with the Fixes tag it implies that this is
On 13.05.2025 19:01, Stewart Hildebrand wrote:
> On 5/13/25 11:39, Jan Beulich wrote:
>> On 08.05.2025 15:20, Stewart Hildebrand wrote:
>>> --- a/xen/common/rangeset.c
>>> +++ b/xen/common/rangeset.c
>>> @@ -397,6 +397,18 @@ int rangeset_merge(struct rangeset *r1, struct
>>> rangeset *r2)
>>>
On 5/14/2025 1:17 AM, Philippe Mathieu-Daudé wrote:
As each target declares the same prototypes, we can
use a single header, removing the TARGET_XXX uses.
Signed-off-by: Philippe Mathieu-Daudé
...
diff --git a/hw/arm/xen-pvh.c b/hw/arm/xen-pvh.c
index 4b26bcff7a5..1a9eeb01c8e 100644
--- a/hw/
[Public]
Hi
> -Original Message-
> From: Jan Beulich
> Sent: Monday, May 12, 2025 11:43 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andrew Cooper
> ; Anthony PERARD ;
> Orzel, Michal ; Julien Grall ; Roger Pau
> Monné ; Stefano Stabellini ;
> xen-
> de...@lists.xenproject.org
> Subject: R
On 5/13/25 1:05 PM, Sergii Dmytruk wrote:
> When running on an EFI-enabled system, Xen needs to have access to Boot
> Services in order to initialize itself properly and reach a state in
> which a dom0 kernel can operate without issues.
>
> This means that DRTM must be started in the middle of Xen
On Mon, 12 May 2025, John Ernberg wrote:
> When running Xen on iMX8QXP, an Arm SoC without IOMMU, DMA performed via
> its eDMA v3 DMA engine fail with a mapping error.
>
> The eDMA performs DMA between RAM and MMIO space, and it's the MMIO side
> that cannot be mapped.
>
> MMIO->RAM DMA access ca
On Tue, 13 May 2025, Stewart Hildebrand wrote:
> Code in domain-build.c and dom0less-build.c was migrated from init-only
> files. Thus, they contain only __init functions. Enforce this at build
> time.
>
> Fixes: ad03faa942b9 ("xen/common: dom0less: make some parts of Arm's
> CONFIG_DOM0LESS comm
On Tue, 13 May 2025, Stewart Hildebrand wrote:
> All functions in dom0less-build.c should be __init.
>
> Fixes: 2705f1adb9df ("xen: introduce Kconfig ARCH_PAGING_MEMPOOL")
> Signed-off-by: Stewart Hildebrand
Reviewed-by: Stefano Stabellini
> ---
> xen/common/device-tree/dom0less-build.c | 4 +
On Tue, 13 May 2025, Philippe Mathieu-Daudé wrote:
> As each target declares the same prototypes, we can
> use a single header, removing the TARGET_XXX uses.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Stefano Stabellini
> ---
> include/hw/arm/xen_arch_hvm.h | 9 -
> inc
On Tue, 13 May 2025, Oleksii Kurochko wrote:
> Refactor construct_domU() to improve architecture separation and reduce
> reliance on ARM-specific logic in common code:
> - Drop set_domain_type() from generic code. This function is specific
> to ARM and serves no purpose on other architectures lik
On 5/13/25 10:17 AM, Philippe Mathieu-Daudé wrote:
As each target declares the same prototypes, we can
use a single header, removing the TARGET_XXX uses.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/arm/xen_arch_hvm.h | 9 -
include/hw/i386/xen_arch_hvm.h | 11 ---
On May 12, 2025 11:06:02 PM PDT, "Jürgen Groß" wrote:
>On 13.05.25 07:55, Xin Li wrote:
>> On 5/12/2025 4:24 AM, Juergen Gross wrote:
>>> Now with the mentioned patch really attached. :-)
>>>
>>
>> Does it allow patching with an instruction more than 6 bytes long?
>>
>> The immediate form MSR i
On 5/13/25 04:05, Jan Beulich wrote:
On 06.05.2025 21:29, Daniel P. Smith wrote:
On 5/2/25 03:21, Jan Beulich wrote:
On 30.04.2025 20:56, Daniel P. Smith wrote:
On 4/29/25 08:36, Alejandro Vallejo wrote:
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -11,6 +11,7 @@ obj-$(filter-out $(
Similarly to fba1b0974dd8, when a device is passed through to a
direct-map dom0less domU, the xen,reg ranges may overlap with the
extended regions. Remove xen,reg from direct-map domU extended regions.
Introduce rangeset_count_ranges().
Take the opportunity to update the comment ahead of find_mem
v2->v3:
* drop committed patches
* add ("xen/arm: exclude xen,reg from direct-map domU extended regions")
v1->v2:
* rebase
* address feedback
Stewart Hildebrand (2):
xen/arm: exclude xen,reg from direct-map domU extended regions
tools/arm: exclude iomem from domU extended regions
tools/libs
When a device is passed through to a xl domU, the iomem ranges may
overlap with the extended regions. Remove iomem from extended regions.
Signed-off-by: Stewart Hildebrand
---
Not sure if we need a Fixes: tag, but if we do:
Fixes: 57f87857dc2d ("libxl/arm: Add handling of extended regions for Dom
Hi,
When debugging CI job on Linus' master branch, I added "console=vga vga=,keep"
and got PV dom0 crash Xen with:
(XEN) [ 40.870435] Assertion 'desc->arch.creator_domid == DOMID_INVALID'
failed at arch/x86/irq.c:294
(XEN) [ 40.886925] [ Xen-4.21-unstable x86_64 debug=y ubsan=y Not
From: Kacper Stojek
TXT heap, SINIT and TXT private space are marked as reserved or unused
in e820 to protect from unintended uses.
Signed-off-by: Kacper Stojek
Signed-off-by: Krystian Hebel
Signed-off-by: Michał Żygowski
Signed-off-by: Sergii Dmytruk
---
xen/arch/x86/Makefile
Code in domain-build.c and dom0less-build.c was migrated from init-only
files. Thus, they contain only __init functions. Enforce this at build
time.
Fixes: ad03faa942b9 ("xen/common: dom0less: make some parts of Arm's
CONFIG_DOM0LESS common")
Fixes: d07b7369aa65 ("xen/common: dom0less: introduce
All functions in dom0less-build.c should be __init.
Fixes: 2705f1adb9df ("xen: introduce Kconfig ARCH_PAGING_MEMPOOL")
Signed-off-by: Stewart Hildebrand
---
xen/common/device-tree/dom0less-build.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/common/device-tree/dom0
As each target declares the same prototypes, we can
use a single header, removing the TARGET_XXX uses.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/arm/xen_arch_hvm.h | 9 -
include/hw/i386/xen_arch_hvm.h | 11 ---
include/hw/xen/arch_hvm.h | 14 ++
hw/
From: Krystian Hebel
The file contains TXT register spaces base address, registers offsets,
error codes and inline functions for accessing structures stored on
TXT heap.
Signed-off-by: Krystian Hebel
Signed-off-by: Sergii Dmytruk
---
xen/arch/x86/include/asm/intel-txt.h | 277
Secure Launch won't initiate DRTM on S3 resume (the code for starting
DRTM is not part of Xen), so abort a request to perform S3 suspend to
not lose the state of DRTM PCRs.
Signed-off-by: Sergii Dmytruk
---
xen/arch/x86/acpi/power.c | 8
1 file changed, 8 insertions(+)
diff --git a/xen
From: Michał Żygowski
Report TXT capabilities so that dom0 can query the Intel TXT or AMD
SKINIT support information using xl dmesg.
Signed-off-by: Michał Żygowski
Signed-off-by: Sergii Dmytruk
---
xen/arch/x86/cpu/amd.c | 16 ++
xen/arch/x86/cpu/cpu.h | 1
SHA1 and SHA256 are hard-coded here, but their support by the TPM is
checked. Addition of event log for TPM2.0 will generalize the code
further.
Signed-off-by: Sergii Dmytruk
---
xen/arch/x86/tpm.c | 464 +++--
1 file changed, 452 insertions(+), 12 deleti
This allows the functionality to be reused by other units that need to
update MTRRs.
This also gets rid of a static variable.
Signed-off-by: Sergii Dmytruk
---
xen/arch/x86/cpu/mtrr/generic.c | 51 -
xen/arch/x86/include/asm/mtrr.h | 8 ++
2 files changed, 3
From: Krystian Hebel
This file is built twice: for early 32b mode without paging to measure
MBI and for 64b code to measure dom0 kernel and initramfs. Since MBI
is small, the first case uses TPM to do the hashing. Kernel and
initramfs on the other hand are too big, sending them to the TPM would
t
From: Krystian Hebel
This is made as the first step of making parallel AP bring-up possible.
It should be enough for pre-C code.
Parallel AP bring-up is necessary because TXT by design releases all APs
at once. In addition to that it reduces number of IPIs (and more
importantly, delays between t
When running on an EFI-enabled system, Xen needs to have access to Boot
Services in order to initialize itself properly and reach a state in
which a dom0 kernel can operate without issues.
This means that DRTM must be started in the middle of Xen's
initialization process. This effect is achieved
From: Krystian Hebel
In preparation for TXT SENTER call, GRUB had to modify MTRR settings
to be UC for everything except SINIT ACM. Old values are restored
from SLRT where they were saved by the bootloader.
Signed-off-by: Krystian Hebel
Signed-off-by: Michał Żygowski
Signed-off-by: Sergii Dmyt
From: Krystian Hebel
The code comes from [1] and is licensed under GPL-2.0 license.
The initial version was a combination of:
- include/crypto/sha1.h
- include/crypto/sha1_base.h
- lib/crypto/sha1.c
- crypto/sha1_generic.c
Changes:
- includes, formatting, naming
- renames and splicing of s
Signed-off-by: Sergii Dmytruk
---
xen/arch/x86/include/asm/intel-txt.h | 33 ++
xen/arch/x86/tpm.c | 169 ++-
2 files changed, 175 insertions(+), 27 deletions(-)
diff --git a/xen/arch/x86/include/asm/intel-txt.h
b/xen/arch/x86/include/asm/intel-txt
From: Krystian Hebel
On Intel TXT, APs are started in one of two ways, depending on ACM
which reports it in its information table. In both cases, all APs are
started simultaneously after BSP requests them to do so. Two possible
ways are:
- GETSEC[WAKEUP] instruction,
- MONITOR address.
GETSEC[WA
From: Michał Żygowski
Check whther IA32_FEATURE_CONTROL has the proper bits enabled to run
VMX in SMX when slaunch is active.
Signed-off-by: Michał Żygowski
---
xen/arch/x86/hvm/vmx/vmcs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/a
Use slr_entry_amd_info::boot_params_base on AMD with SKINIT to get MBI
location.
Another thing of interest is the location of SLRT which is bootloader's
data after SKL.
Signed-off-by: Krystian Hebel
Signed-off-by: Sergii Dmytruk
---
xen/arch/x86/boot/head.S | 38
Go through entires in the DRTM policy of SLRT to hash and extend data
that they describe into corresponding PCRs.
Addresses are being zeroed on measuring platform-specific data to
prevent measurements from changing when the only thing that has changed
is an address. Addresses can vary due to boot
This mostly involves not running Intel-specific code when on AMD.
There are only a few new AMD-specific implementation details:
- finding SLB start and size and then mapping and reserving it in e820
- managing offset for adding the next TPM log entry (TXT-compatible
data prepared by SKL is st
Signed-off-by: Sergii Dmytruk
---
MAINTAINERS | 15 +++
1 file changed, 15 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c11b82eca9..347b3bcbb0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -542,6 +542,21 @@ F: */configure
F: */*.ac
F: tools/
+TRENCHBOOT SECU
From: Krystian Hebel
The tests validate that important parts of memory are protected against
DMA attacks, including Xen and MBI. Modules can be tested later, when it
is possible to report issues to a user before invoking TXT reset.
TPM event log validation is temporarily disabled due to an issue
From: Kacper Stojek
Signed-off-by: Kacper Stojek
Signed-off-by: Krystian Hebel
Signed-off-by: Sergii Dmytruk
---
docs/hypervisor-guide/x86/how-xen-boots.rst | 5 ++
xen/arch/x86/boot/head.S| 53 +
2 files changed, 58 insertions(+)
diff --git a/docs/hy
Make head.S invoke a C function to retrieve MBI and SLRT addresses in a
platform-specific way. This is also the place to perform sanity checks
of DRTM.
Signed-off-by: Krystian Hebel
Signed-off-by: Sergii Dmytruk
---
xen/arch/x86/Makefile| 1 +
xen/arch/x86/boot/Makefile
The file provides constants, structures and several helper functions for
parsing SLRT.
Signed-off-by: Ross Philipson
Signed-off-by: Sergii Dmytruk
---
xen/include/xen/slr-table.h | 268
1 file changed, 268 insertions(+)
create mode 100644 xen/include/xen/sl
The aim of the [TrenchBoot] project is to provide an implementation of
DRTM that is generic enough to cover various use cases:
- Intel TXT and AMD SKINIT on x86 CPUs
- legacy and UEFI boot
- TPM1.2 and TPM2.0
- (in the future) DRTM on Arm CPUs
DRTM is a version of a measured launch that starts
Researchers from ETH Zurich have discovered Branch Privilege Injection,
a bug in hardware prediction-domain isolation whereby an attacker can
cause predictions to be tagged with the wrong mode/privilege, and then
use the incorrectly-tagged predictions to mount traditional Spectre-v2
attacks.
For m
On 5/13/25 11:39, Jan Beulich wrote:
> On 08.05.2025 15:20, Stewart Hildebrand wrote:
>> --- a/xen/common/rangeset.c
>> +++ b/xen/common/rangeset.c
>> @@ -397,6 +397,18 @@ int rangeset_merge(struct rangeset *r1, struct rangeset
>> *r2)
>> return rangeset_report_ranges(r2, 0, ~0UL, merge, r1);
On 13.05.2025 17:59, Kevin Lampis wrote:
> On Tue, May 13, 2025 at 3:32 PM Jan Beulich wrote:
>>
>> Well, it's easily possible to catch that error without any extra parsing.
>
> If `lockdown` is not the first argument then we should print a warning
> to tell the user that Xen may have already par
On 06.05.2025 18:51, Oleksii Kurochko wrote:
> Svpbmt extension is necessary for chaning the memory type for a page contains
> a combination of attributes that indicate the cacheability, idempotency,
> and ordering properties for access to that page.
The title suggest use of the extension is optio
On Tue, May 13, 2025 at 3:32 PM Jan Beulich wrote:
>
> Well, it's easily possible to catch that error without any extra parsing.
If `lockdown` is not the first argument then we should print a warning
to tell the user that Xen may have already parsed some insecure
arguments and lockdown mode will
On 06.05.2025 18:51, Oleksii Kurochko wrote:
> @@ -72,6 +72,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>
> remove_identity_mapping();
>
> +smp_prepare_boot_cpu();
> +
> set_processor_id(0);
>
> set_cpuid_to_hartid(0, bootcpu_id);
Is this a good placement
Only access the HVM union b_info->u.hvm on HVM guests. The union
access is not guarded, so this reads and sets the default even on
non-HVM guests. Usually this doesn't matter as PV and PVH unions are
smaller and zero-initialized, but the zero default will be re-written as
a -1 boolean. Generally
On 06.05.2025 18:51, Oleksii Kurochko wrote:
> The this_isa bitmap should be explicitly initialized to zero to avoid
> false positives when detecting supported ISA extensions. Without proper
> zero-initialization, the bitmap may retain non-zero values from
> uninitialized memory, causing Xen to inc
On 08.05.2025 15:20, Stewart Hildebrand wrote:
> --- a/xen/common/rangeset.c
> +++ b/xen/common/rangeset.c
> @@ -397,6 +397,18 @@ int rangeset_merge(struct rangeset *r1, struct rangeset
> *r2)
> return rangeset_report_ranges(r2, 0, ~0UL, merge, r1);
> }
>
> +static int cf_check subtract(un
On 12.05.2025 16:46, Ross Lagerwall wrote:
> If set_px_pminfo is called a second time with a larger state_count than
> the first call, calls to PMSTAT_get_pxstat will read beyond the end of
> the pt and trans_pt buffers allocated in cpufreq_statistic_init() since
> they would have been allocated wi
On 13/05/2025 16:29, Oleksii Kurochko wrote:
> The current implementation of make_chosen_node() does not contain any
> architecture-specific logic. Therefore, move it from arch-specific
> files to common code.
>
> At this stage, there is no need to introduce an arch_make_chosen_node(),
> as no
On 24.04.25 22:22, Stewart Hildebrand wrote:
> On 4/23/25 07:08, Mykyta Poturai wrote:
>> From: Oleksandr Andrushchenko
>>
>> Add support for Renesas R-Car Gen4 PCI host controller, specifically
>> targeting the S4 and V4H SoCs. The implementation includes configuration
>> read/write operations fo
On 12.05.2025 16:46, Ross Lagerwall wrote:
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -215,23 +215,51 @@ typedef struct pm_px_val pm_px_val_t;
> DEFINE_XEN_GUEST_HANDLE(pm_px_val_t);
>
> struct pm_px_stat {
> -uint8_t total;/* total Px states */
> -
This patch series refactor construct_domU() by moving back some Arm-specific
changes to Arm code as they aren't used now by other architectures.
Introduce arch_contruct_domU() to cover arch specific steps of a guest
domain construction.
Add ARM dependency for CONFIG_STATIC_MEMORY as, at the momen
On 13/05/2025 16:29, Oleksii Kurochko wrote:
> Now that CONFIG_DOM0LESS_BOOT has been moved to common code and is planned to
> be supported by other architectures (e.g., RISC-V), the dependency for
> CONFIG_STATIC_MEMORY needs to be updated.
> Since CONFIG_STATIC_MEMORY is currently only support
On 13.05.2025 16:28, Kevin Lampis wrote:
> On Tue, May 13, 2025 at 12:09 PM Jan Beulich wrote:
>> I would like this to at least be considered.
>> I don't like that custom command line parsing very much.
>
> I understand. Parsing code can be risky.
>
> In this case I think the code is small and s
Refactor construct_domU() to improve architecture separation and reduce
reliance on ARM-specific logic in common code:
- Drop set_domain_type() from generic code. This function is specific
to ARM and serves no purpose on other architectures like RISC-V,
which lack the arch.type field in kernel_
Now that CONFIG_DOM0LESS_BOOT has been moved to common code and is planned to
be supported by other architectures (e.g., RISC-V), the dependency for
CONFIG_STATIC_MEMORY needs to be updated.
Since CONFIG_STATIC_MEMORY is currently only supported on ARM, its dependency
should explicitly reflect that
On Tue, May 13, 2025 at 12:09 PM Jan Beulich wrote:
> I would like this to at least be considered.
> I don't like that custom command line parsing very much.
I understand. Parsing code can be risky.
In this case I think the code is small and simple though.
My concern with asking the user to alw
On 12.05.2025 16:46, Ross Lagerwall wrote:
> Check that the total number of states passed in and hence the size of
> buffers is sufficient to avoid writing more than the caller has
> allocated.
>
> The interface is not explicit about whether getpx.total is expected to
> be set by the caller in thi
On 13/05/2025 2:42 pm, Jan Beulich wrote:
> On 13.05.2025 14:48, Andrew Cooper wrote:
>> In IPU 2025.2 (May 2025), Intel have released an alternative mitigation for a
>> prior security issue (SA-00982) on Sappire and Emerald Rapids CPUs.
>>
>> Intel suggest that certain workloads will benefit from
On 13.05.2025 15:41, Roger Pau Monné wrote:
> On Wed, May 03, 2023 at 11:45:22AM +0200, Jan Beulich wrote:
>> We allow its use for writeback purposes only anyway, so let's also carry
>> these out that way on capable hardware.
>
> "for writeback purposes only" > is such the case because we cannot
>
Ping?
On 29.04.25 13:06, Juergen Gross wrote:
Remove the qemu-traditional support. This includes the Mini-OS
based ioemu-stubdom.
Don't remove ROMBIOS for now, as it can be used with qemu (XenServer
is doing that).
After adding the series a run of autoconf should be done.
Changes in V2:
- add
On 13.05.2025 14:48, Andrew Cooper wrote:
> In IPU 2025.2 (May 2025), Intel have released an alternative mitigation for a
> prior security issue (SA-00982) on Sappire and Emerald Rapids CPUs.
>
> Intel suggest that certain workloads will benefit from using the alternative
> mode. This can be sele
On Wed, May 03, 2023 at 11:45:22AM +0200, Jan Beulich wrote:
> We allow its use for writeback purposes only anyway, so let's also carry
> these out that way on capable hardware.
"for writeback purposes only" > is such the case because we cannot
guarantee the guest in which state the cache will be
On 2025-05-13 03:27, Jan Beulich wrote:
On 13.05.2025 01:54, Jason Andryuk wrote:
Only access the HVM union b_info->u.hvm on HVM guests. The union
access is not guarded, so this reads and sets the default even on
non-HVM guests. Usually this doesn't matter as PV and PVH unions are
smaller and
On 13.05.2025 15:12, Andrew Cooper wrote:
> On 03/05/2023 10:45 am, Jan Beulich wrote:
>> We allow its use for writeback purposes only anyway, so let's also carry
>> these out that way on capable hardware.
By implication of what you say ...
>> With it now known that WBNOINVD uses the same VM exit
On 03/05/2023 10:45 am, Jan Beulich wrote:
> We allow its use for writeback purposes only anyway, so let's also carry
> these out that way on capable hardware.
>
> With it now known that WBNOINVD uses the same VM exit code as WBINVD for
> both SVM and VT-x, we can now also expose the feature that w
On Wed, May 03, 2023 at 11:44:39AM +0200, Jan Beulich wrote:
> The majority of the present callers really aren't after invalidating
> cache contents, but only after writeback. Make this available by simply
> extending the FLUSH_CACHE handling accordingly. No feature checks are
> required here: cach
In IPU 2025.2 (May 2025), Intel have released an alternative mitigation for a
prior security issue (SA-00982) on Sappire and Emerald Rapids CPUs.
Intel suggest that certain workloads will benefit from using the alternative
mode. This can be selected by booting with `spec-ctrl=ibpb-alt`.
https://
On 12/05/2025 1:38 pm, Jan Beulich wrote:
>> + * Copyright (C) 1994, 1996, 1998, 2000 Free Software Foundation, Inc.
>> + *
>> + * This file is part of GnuPG.
>> + *
>> + * GnuPG is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as
On 13.05.2025 13:07, Kevin Lampis wrote:
> On Tue, May 13, 2025 at 8:00 AM Jan Beulich wrote:
>>
>> Well, there is an alternative: Require the lockdown argument to be absolutely
>> first. (There are further alternatives, but likely less usable.)
>
> Is this your recommendation?
I would like this
On Tue, May 13, 2025 at 8:00 AM Jan Beulich wrote:
>
> Well, there is an alternative: Require the lockdown argument to be absolutely
> first. (There are further alternatives, but likely less usable.)
Is this your recommendation?
On Mon, May 12, 2025 at 11:41 AM Jan Beulich wrote:
>
> You want to go into more detail here, specifically to describe the criteria
> of "specifically safe". The command line doc may also want updating.
I do not have a quick answer for you please bear with me.
On 13.05.2025 11:04, Ross Lagerwall wrote:
> On Mon, May 12, 2025 at 1:19 PM Jan Beulich wrote:
>>
>> On 09.05.2025 18:18, Ross Lagerwall wrote:
>>> --- a/docs/misc/livepatch.pandoc
>>> +++ b/docs/misc/livepatch.pandoc
>>> @@ -917,6 +917,58 @@ The normal sequence of events is to:
>>> 3. *XEN_SYS
On Mon, May 12, 2025 at 1:19 PM Jan Beulich wrote:
>
> On 09.05.2025 18:18, Ross Lagerwall wrote:
> > --- a/docs/misc/livepatch.pandoc
> > +++ b/docs/misc/livepatch.pandoc
> > @@ -917,6 +917,58 @@ The normal sequence of events is to:
> > 3. *XEN_SYSCTL_LIVEPATCH_ACTION* with *LIVEPATCH_ACTION_AP
Provide a function that creates a pr_t object from a memory
range and some attributes.
Signed-off-by: Luca Fancellu
---
v5 changes:
- removed AP_RW_EL2 used only by pr_of_xenaddr(), fixed
comments and typos
- Given some comments to the page.h flags and modifications
to the prbar_t fields
Hi all,
This is the first chunk of work to support MPU and R82 on Xen, this serie
reaches the early boot stages just before early_fdt_map(), just to give an idea
about which stage of the boot is reached.
v5:
- dropped patch that touches page.h, it is not needed
- general fixes listed on each pa
From: Penny Zheng
Introduce pr_t typedef which is a structure having the prbar
and prlar members, each being structured as the registers of
the AArch64 Armv8-R architecture.
Signed-off-by: Penny Zheng
Signed-off-by: Wei Chen
Signed-off-by: Luca Fancellu
---
Changes in v5:
- Given some commen
Provide some data structure in the C world to track the MPU
status, these structures will be filled at boot by the assembly
early code with the boot MPU regions and afterwards they will be
used at runtime.
Provide methods to update a bitmap created with DECLARE_BITMAP
from the assembly code for bo
Document the requirement needed to boot Xen on Armv8-R platforms.
Signed-off-by: Luca Fancellu
Reviewed-by: Ayan Kumar Halder
Reviewed-by: Michal Orzel
---
v5 changes:
- restructured and removed some EL3 reference that might not
be there on Armv8-R aarch64
- add R-by Ayan and Michal
v4 cha
Introduce a few utility functions to manipulate and handle the
pr_t type.
Signed-off-by: Luca Fancellu
---
v5 changes:
- Don't rely on bitfield and use the mask MPU_REGION_RES0 for
pr_set_base and pr_set_limit to make it explicit. Fixed typos
in commit message.
v4 changes:
- Modify commen
Implement some utility function in order to access the MPU regions
from the C world.
Signed-off-by: Luca Fancellu
---
v5 changes:
- move MPU_REGION_RES0 to arm64, fixed typos and code style.
v4 changes:
- moved back PRBAR0_EL2/PRLAR0_EL2 to mm.c and protect
them with CONFIG_ARM_64, changed c
On 06.05.2025 21:29, Daniel P. Smith wrote:
> On 5/2/25 03:21, Jan Beulich wrote:
>> On 30.04.2025 20:56, Daniel P. Smith wrote:
>>> On 4/29/25 08:36, Alejandro Vallejo wrote:
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -11,6 +11,7 @@ obj-$(filter-out $(CONFIG_X86),$(CONFI
On 09.05.2025 08:36, Penny, Zheng wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: Wednesday, April 30, 2025 9:55 PM
>>
>> On 14.04.2025 09:40, Penny Zheng wrote:
>>> HWP, amd-cppc, amd-cppc-epp are all the implementation of ACPI CPPC
>>> (Collaborative Processor Performace Contr
On 07.05.2025 11:19, Penny, Zheng wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: Tuesday, April 29, 2025 10:29 PM
>>
>> On 14.04.2025 09:40, Penny Zheng wrote:
>>> --- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c
>>> +++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
>>> +/*
>>> + * If CPPC
On 07.05.2025 08:12, Penny, Zheng wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: Thursday, April 17, 2025 11:23 PM
>>
>> On 14.04.2025 09:40, Penny Zheng wrote:
>>> --- a/xen/arch/x86/cpu/amd.c
>>> +++ b/xen/arch/x86/cpu/amd.c
>>> @@ -570,12 +573,35 @@ static void amd_get_topol
On 5/12/2025 4:20 AM, Jürgen Groß wrote:
On 09.05.25 10:18, Xin Li wrote:
On 5/6/2025 2:20 AM, Juergen Gross wrote:
I'm trying to evaluate how to add the immediate form MSR instructions
on top of this patch set. And I'm close to get it done.
There is something to consider when running as a Xe
On 13.05.2025 01:54, Jason Andryuk wrote:
> Only access the HVM union b_info->u.hvm on HVM guests. The union
> access is not guarded, so this reads and sets the default even on
> non-HVM guests. Usually this doesn't matter as PV and PVH unions are
> smaller and zero-initialized, but the zero defa
On 12.05.2025 21:56, Kevin Lampis wrote:
> The intention of lockdown mode is to prevent attacks from a rogue dom0
> userspace from compromising the system. Lockdown mode can be controlled by a
> Kconfig option and a command-line parameter. It is also enabled automatically
> when Secure Boot is enab
On 12.05.2025 21:51, Kevin Lampis wrote:
> On Mon, May 12, 2025 at 11:39 AM Jan Beulich wrote:
>>
>> I can't spot the effect the comment mentions anywhere in this patch. Is the
>> description perhaps lacking some detail? It's rather odd after all to see ...
>>
>> ... such custom token splitting ah
98 matches
Mail list logo
