On Fri, May 09, 2025 at 02:21:57PM -0400, Demi Marie Obenour wrote:
> On 5/9/25 6:50 AM, Roger Pau Monné wrote:
> > On Fri, May 09, 2025 at 11:47:36AM +0200, Alejandro Vallejo wrote:
> >>> A Linux driver that needs access to userspace memory
> >>> pages can get it in two different ways:
> >
Hi Andrew,
On 10/05/2025 14:12, Andrew Cooper wrote:
Nothing in bitmap.h uses lib.h. Reduce to just macros.h and string.h. Drop
types.h while at it, as it comes in through bitops.h
cpumask.h and nodemask.h only include kernel.h to get container_of(). Move it
into macros.h where it belongs.
On 03.05.2025 16:02, Ngamia Djabiri Julie wrote:
> Dear Xen developers,
>
> I would like to ask if the following fix can also be included in Xen 4.17.6
> (and eventually in the Xen versions after 4.17.6 that don't have the fix) :
>
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=dd05d
On Fri, May 09, 2025 at 02:10:03PM -0700, Stefano Stabellini wrote:
> On Fri, 9 May 2025, Roger Pau Monné wrote:
> > On Thu, May 08, 2025 at 04:25:28PM -0700, Stefano Stabellini wrote:
> > > On Thu, 8 May 2025, Roger Pau Monné wrote:
> > > > On Wed, May 07, 2025 at 04:02:11PM -0700, Stefano Stabell
A subset of command-line parameters that are specifically safe to use
when lockdown mode is enabled are annotated as such.
Signed-off-by: Kevin Lampis
---
xen/arch/arm/domain_build.c | 4 +--
xen/arch/x86/acpi/cpu_idle.c | 2 +-
xen/arch/x86/cpu/amd.c| 2 +-
On 02.05.2025 18:49, Stefano Stabellini wrote:
> On Fri, 2 May 2025, Jan Beulich wrote:
>> On 01.05.2025 15:44, Jason Andryuk wrote:
>>> On 2025-04-30 20:19, Stefano Stabellini wrote:
On Wed, 30 Apr 2025, Roger Pau Monné wrote:
> On Wed, Apr 30, 2025 at 08:27:55AM +0200, Jan Beulich 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 cannot be bounce buffered if it would straddle a page
bou
These patches:
1) remove a superfluous inclusion of accidently added to
drivers/acpi/processor_throttling.c in commit:
efef7f184f2e ("x86/msr: Add explicit includes of ").
2) Fix uninitialized symbol 'err' introduced by:
d815da84fdd0 ("x86/msr: Change the function type of
native_
xen_read_msr_safe() currently passes an uninitialized argument err to
xen_do_read_msr(). But as xen_do_read_msr() may not set the argument,
xen_read_msr_safe() could return err with an unpredictable value.
To ensure correctness, initialize err to 0 (representing success)
in xen_read_msr_safe().
The following commit:
efef7f184f2e ("x86/msr: Add explicit includes of ")
added a superfluous inclusion of to
drivers/acpi/processor_throttling.c.
Remove it.
Signed-off-by: Xin Li (Intel)
---
drivers/acpi/processor_throttling.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/
Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
conversions when a u64 MSR value is splitted into two u32.
Signed-off-by: Xin Li (Intel)
---
arch/x86/coco/sev/core.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/x86/coco/sev/core.c b/arch/
On 09.05.2025 10:32, Roger Pau Monné wrote:
> On Thu, May 08, 2025 at 04:25:28PM -0700, Stefano Stabellini wrote:
>> On Thu, 8 May 2025, Roger Pau Monné wrote:
>>> On Wed, May 07, 2025 at 04:02:11PM -0700, Stefano Stabellini wrote:
On Tue, 6 May 2025, Roger Pau Monné wrote:
> On Mon, May 0
On 5/9/25 6:14 PM, Andrew Cooper wrote:
On 09/05/2025 4:57 pm, Oleksii Kurochko wrote:
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
new file mode 100644
index 00..ad4beef8f9
--- /dev/null
+++ b/xen/arch/riscv/p2m.c
@@ -0,0 +1,168 @@
+#include
+#include
+#include
+#include
On 5/12/25 11:24 AM, Oleksii Kurochko wrote:
On 5/9/25 6:14 PM, Andrew Cooper wrote:
On 09/05/2025 4:57 pm, Oleksii Kurochko wrote:
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
new file mode 100644
index 00..ad4beef8f9
--- /dev/null
+++ b/xen/arch/riscv/p2m.c
@@ -0,0 +1,1
On 07.05.2025 16:37, Ross Lagerwall wrote:
> On Thu, Apr 17, 2025 at 2:23 PM Jan Beulich wrote:
>>
>> On 17.04.2025 12:30, Ross Lagerwall wrote:
>>> --- a/xen/drivers/acpi/pmstat.c
>>> +++ b/xen/drivers/acpi/pmstat.c
>>> @@ -104,6 +104,14 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
>>>
On 07.05.2025 11:42, Frediano Ziglio wrote:
> From: Frediano Ziglio
>
> Using EFI Secure Boot all kernel level code should be signed and
> there should be no way to run unchecked code.
> For this reason the Kexec interface needs to be changed in order
> to allows signature checking.
>
> The purg
On Thu, May 08, 2025 at 10:44:36PM +0200, Marek Marczykowski-Górecki wrote:
> Hi,
>
> I wanted to post another revision of the series adding hw12 runner,
> hoping that all known issues are fixed now, but unfortunately there is
> still something broken. I've rebased my series on top of staging
> (e
On 06.05.2025 18:23, Kevin Lampis wrote:
> Add lockdown mode
>
> 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
> w
On Fri, May 9, 2025 at 6:40 PM Andrew Cooper wrote:
>
> On 09/05/2025 4:34 pm, Frediano Ziglio wrote:
> > On Fri, May 9, 2025 at 4:04 PM Andrew Cooper
> > wrote:
> >> On 07/05/2025 10:42 am, Frediano Ziglio wrote:
> >>> Ross Lagerwall (4):
> >>> xen/lib: Export additional sha256 functions
> >>
On 06.05.2025 16:05, Andrew Cooper wrote:
> On 06/05/2025 2:56 pm, Frediano Ziglio wrote:
>> diff --git a/xen/include/xen/sha2.h b/xen/include/xen/sha2.h
>> index 47d97fbf01..ea8bad67e4 100644
>> --- a/xen/include/xen/sha2.h
>> +++ b/xen/include/xen/sha2.h
>> @@ -9,6 +9,16 @@
>>
>> #define SHA2_
On 06.05.2025 18:55, Andrew Cooper wrote:
> On 06/05/2025 5:24 pm, Kevin Lampis wrote:
>> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
>> index e39fbc3529..7c528cd5dd 100644
>> --- a/xen/common/efi/boot.c
>> +++ b/xen/common/efi/boot.c
>> @@ -870,6 +870,27 @@ static void __init pre_pa
From: Jason Andryuk
[ Upstream commit 90989869baae47ee2aa3bcb6f6eb9fbbe4287958 ]
Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
currently forced to XS_LOCAL. With Hyperlaunch booting dom0 and a
xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
late in
From: Jason Andryuk
[ Upstream commit 90989869baae47ee2aa3bcb6f6eb9fbbe4287958 ]
Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
currently forced to XS_LOCAL. With Hyperlaunch booting dom0 and a
xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
late in
From: Jason Andryuk
[ Upstream commit 90989869baae47ee2aa3bcb6f6eb9fbbe4287958 ]
Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
currently forced to XS_LOCAL. With Hyperlaunch booting dom0 and a
xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
late in
From: Jason Andryuk
[ Upstream commit 90989869baae47ee2aa3bcb6f6eb9fbbe4287958 ]
Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
currently forced to XS_LOCAL. With Hyperlaunch booting dom0 and a
xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
late in
From: Jason Andryuk
[ Upstream commit 90989869baae47ee2aa3bcb6f6eb9fbbe4287958 ]
Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
currently forced to XS_LOCAL. With Hyperlaunch booting dom0 and a
xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
late in
From: Jason Andryuk
[ Upstream commit 90989869baae47ee2aa3bcb6f6eb9fbbe4287958 ]
Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
currently forced to XS_LOCAL. With Hyperlaunch booting dom0 and a
xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
late in
From: Jason Andryuk
[ Upstream commit 90989869baae47ee2aa3bcb6f6eb9fbbe4287958 ]
Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
currently forced to XS_LOCAL. With Hyperlaunch booting dom0 and a
xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
late in
On Mon, May 12, 2025 at 03:00:18PM +0200, Jan Beulich wrote:
> On 12.05.2025 14:09, Andrew Cooper wrote:
> >
> > Now for the (new) controversial part. Since sending this, Linux has
> > decided to just #define auto __auto_type for C < 23, in order to start
> > writing C23 compatible code from now.
On Mon, 12 May 2025, Volodymyr Babchuk wrote:
> Hi Stefano,
>
>
> Stefano Stabellini writes:
>
> > On Wed, 7 May 2025, Volodymyr Babchuk wrote:
>
> >> alpine-3.18-gcc-debug-arm64:
> >> + extends: .gcc-arm64-build-debug
> >> + variables:
> >> +CONTAINER: alpine:3.18-arm64v8
> >> +EXT
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 ahead of normal command line handling.
If the UEF
On Mon, May 12, 2025 at 12:51 PM Andrew Cooper
wrote:
>
> Kevin: It will be best to resend the series in full.
Ok.
A subset of command-line parameters that are specifically safe to use when
lockdown mode is enabled are annotated as such.
Signed-off-by: Kevin Lampis
Signed-off-by: Ross Lagerwall
---
xen/arch/arm/domain_build.c | 4 +--
xen/arch/x86/acpi/cpu_idle.c | 2 +-
xen/arch/x86/cp
On 5/9/25 02:54, Orzel, Michal wrote:
> On 08/05/2025 15:20, Stewart Hildebrand wrote:
>> diff --git a/xen/include/xen/fdt-kernel.h b/xen/include/xen/fdt-kernel.h
>> index 7a6cd67c22f1..1939c3ebf7dc 100644
>> --- a/xen/include/xen/fdt-kernel.h
>> +++ b/xen/include/xen/fdt-kernel.h
>> @@ -24,6 +24,7
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 enabled and it cannot be disabled in that case.
Ross
On Mon, May 12, 2025 at 12:48 PM Teddy Astie wrote:
>
>What makes max_cstate / dom0-max-vcpus / dom0-mem specifically unsafe ?
These arguments are all allowed. The *_secure_param macros mean the argument is
safe for lockdown mode.
Making PCI passthrough safe for secure boot will be handled in a
From: Ross Lagerwall
Also cache it to avoid needing to repeatedly ask the firmware.
Signed-off-by: Ross Lagerwall
Signed-off-by: Kevin Lampis
---
xen/common/efi/boot.c| 23 +++
xen/common/efi/runtime.c | 3 +++
xen/include/xen/efi.h| 6 ++
3 files changed, 32
From: Ross Lagerwall
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 enabled and it cannot be disab
On 2025-05-12 20:25, Elliott Mitchell wrote:
On Mon, May 12, 2025 at 03:00:18PM +0200, Jan Beulich wrote:
On 12.05.2025 14:09, Andrew Cooper wrote:
>
> Now for the (new) controversial part. Since sending this, Linux has
> decided to just #define auto __auto_type for C < 23, in order to start
>
SBAT is a revocation scheme for UEFI SecureBoot, and is mandated by Microsoft
for signing.
The SBAT section provides a way for the binary to declare a generation
id for its upstream source and any vendor changes applied. A compatible
loader can then revoke vulnerable binaries by generation, using
On 12.05.2025 11:02, Kevin Lampis wrote:
> A subset of command-line parameters that are specifically safe to use
> when lockdown mode is enabled are annotated as such.
You want to go into more detail here, specifically to describe the criteria
of "specifically safe". The command line doc may also
On 12.05.2025 12:54, Roger Pau Monné wrote:
> On Mon, May 12, 2025 at 11:51:35AM +0200, Jan Beulich wrote:
>> On 08.05.2025 19:01, Ross Lagerwall wrote:
>>> @@ -1328,10 +1327,15 @@ static int livepatch_list(struct
>>> xen_sysctl_livepatch_list *list)
>>> status.rc = data->rc;
>>>
>>
On 08.05.2025 11:43, Andrew Cooper wrote:
> On 07/05/2025 3:45 pm, Kevin Lampis wrote:
>> From: Ross Lagerwall
>>
>> This will be used by future patches.
>>
>> Signed-off-by: Ross Lagerwall
>> Signed-off-by: Kevin Lampis
>
> Reviewed-by: Andrew Cooper
Like for the sha256 change - isn't this i
On 08.05.2025 10:51, Andrew Cooper wrote:
> On 07/05/2025 2:54 pm, Gerald Elder-Vass wrote:
> Also,
>
>> ld: warning: orphan section `.sbat' from `prelink.o' being placed in section
>> `.sbat'
>
> This is because sbat.o is getting linked into the non-EFI build of Xen too.
>
> I'm less sure how
On Mon, May 12, 2025 at 11:51:35AM +0200, Jan Beulich wrote:
> On 08.05.2025 19:01, Ross Lagerwall wrote:
> > @@ -1328,10 +1327,15 @@ static int livepatch_list(struct
> > xen_sysctl_livepatch_list *list)
> > status.rc = data->rc;
> >
> > name_len = strlen(data->name) +
On 06.05.2025 18:25, Kevin Lampis wrote:
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -216,6 +216,9 @@ static void __init _cmdline_parse(const char *cmdline)
> */
> void __init cmdline_parse(const char *cmdline)
> {
> +/* Call this early since it affects command-line parsing
On 06.05.2025 16:32, Ross Lagerwall wrote:
> From: Kevin Lampis
>
> Make it possible to embed a public key in Xen to be used when verifying
> live patch payloads. Inclusion of the public key is optional.
>
> To avoid needing to include a DER / X.509 parser in the hypervisor, the
> public key is
On 07.05.2025 11:53, Volodymyr Babchuk wrote:
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -78,6 +78,7 @@ extra-y := symbols-dummy.o
> obj-$(CONFIG_COVERAGE) += coverage/
> obj-y += sched/
> obj-$(CONFIG_UBSAN) += ubsan/
> +obj-$(CONFIG_FUZZER_LIBAFL_QEMU) += libafl-qemu.o
This
On 09.05.2025 18:32, Andrew Cooper wrote:
> elfstructs.h needs the stdint.h types. Two headers arrange this manually, but
> elf.h and livepatch.h do not, which breaks source files whose headers are
> properly sorted.
>
> elfstructs.h is used by tools too, so use stdint directly outside of Xen.
>
On 12.05.2025 13:58, Andrew Cooper wrote:
> --- a/xen/arch/x86/include/asm/idt.h
> +++ b/xen/arch/x86/include/asm/idt.h
> @@ -92,15 +92,16 @@ static inline void _set_gate_lower(idt_entry_t *gate,
> unsigned long type,
> * Update the lower half handler of an IDT entry, without changing any other
On 12.05.2025 14:00, Andrew Cooper wrote:
> Since commit 434596bbd44a ("x86/smpboot: Write the top-of-stack block in
> cpu_smpboot_alloc()"), smp_processor_id() is unconditionally usable on APs.
> Drop the global variable.
>
> Also drop the parameter from start_secondary(). It was introduced as u
On 12/05/2025 2:21 pm, Jan Beulich wrote:
> On 12.05.2025 13:58, Andrew Cooper wrote:
>> --- a/xen/arch/x86/include/asm/idt.h
>> +++ b/xen/arch/x86/include/asm/idt.h
>> @@ -92,15 +92,16 @@ static inline void _set_gate_lower(idt_entry_t *gate,
>> unsigned long type,
>> * Update the lower half han
On 12.05.2025 15:48, Andrew Cooper wrote:
> On 12/05/2025 2:21 pm, Jan Beulich wrote:
>> On 12.05.2025 13:58, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/include/asm/idt.h
>>> +++ b/xen/arch/x86/include/asm/idt.h
>>> @@ -92,15 +92,16 @@ static inline void _set_gate_lower(idt_entry_t *gate,
>>> uns
On 06.05.2025 10:31, Roger Pau Monne wrote:
> The implementation of MMUEXT_FLUSH_CACHE is bogus, as it doesn't account to
> flush the cache of any previous pCPU where the current vCPU might have run,
> and hence is likely to not work as expected.
>
> Fix this by resorting to use the same logic as
On 06.05.2025 10:31, Roger Pau Monne wrote:
> The implementation of MMUEXT_FLUSH_CACHE is bogus, as it doesn't account to
> flush the cache of any previous pCPU where the current vCPU might have run,
> and hence is likely to not work as expected.
>
> Fix this by resorting to use the same logic as
On 06.05.2025 10:31, Roger Pau Monne wrote:
> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -1193,17 +1193,18 @@ static int cf_check cache_op(
> {
> ASSERT(op == x86emul_wbinvd || op == x86emul_wbnoinvd);
>
> -/* Ignore the instruction if unprivileged.
On Mon, May 12, 2025 at 03:31:19PM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, May 12, 2025 at 12:26:09PM +0200, Roger Pau Monné wrote:
> > On Thu, May 08, 2025 at 10:44:36PM +0200, Marek Marczykowski-Górecki wrote:
> > > Hi,
> > >
> > > I wanted to post another revision of the series addin
On 06.05.2025 12:40, Roger Pau Monné wrote:
> On Tue, May 06, 2025 at 11:15:09AM +0100, Julien Grall wrote:
>> On 06/05/2025 09:31, Roger Pau Monne wrote:
>>> Whether a domain is allowed to issue cache-control operations is reported
>>> by the cache_flush_permitted() check. Introduce such check to
On Mon, May 12, 2025 at 04:11:51PM +0200, Jan Beulich wrote:
> On 06.05.2025 10:31, Roger Pau Monne wrote:
> > The implementation of MMUEXT_FLUSH_CACHE is bogus, as it doesn't account to
> > flush the cache of any previous pCPU where the current vCPU might have run,
> > and hence is likely to not w
On 06.05.2025 10:31, Roger Pau Monne wrote:
> The current underlying implementation of GNTTABOP_cache_flush on x86 won't
> work as expected. The provided {clean,invalidate}_dcache_va_range()
> helpers only do a local pCPU cache flush, so the cache of previous pCPUs
> where the vCPU might have run
On Mon, May 12, 2025 at 04:09:28PM +0200, Jan Beulich wrote:
> On 06.05.2025 10:31, Roger Pau Monne wrote:
> > The implementation of MMUEXT_FLUSH_CACHE is bogus, as it doesn't account to
> > flush the cache of any previous pCPU where the current vCPU might have run,
> > and hence is likely to not w
On 12/05/2025 11:58 am, Jan Beulich wrote:
> On 08.05.2025 18:03, Andrew Cooper wrote:
>> The text for CONFIG_INDIRECT_THUNK isn't really correct, and was already
>> stale
>> by the time speculative vulnerabilities hit the headlines in 2018. It is
>> specifically an out-of-line-ing mechansim, and
On 06.05.2025 10:31, Roger Pau Monne wrote:
> The current logic partially open-codes memory_type_changed(), but doesn't
> check whether the type change or the cache flush is actually needed.
> Instead switch to using memory_type_changed(), at possibly a higher expense
> cost of not exclusively issu
On 06.05.2025 10:31, Roger Pau Monne wrote:
> Only do the cache flush when there's a p2m type change to propagate,
> otherwise there's no change in the p2m effective caching attributes.
>
> If the p2m memory_type_changed hook is not set p2m_memory_type_changed() is
> a no-op, no recalculation of c
On Mon, May 12, 2025 at 04:50:22PM +0200, Roger Pau Monné wrote:
> On Mon, May 12, 2025 at 04:40:29PM +0200, Marek Marczykowski-Górecki wrote:
> > On Mon, May 12, 2025 at 04:19:59PM +0200, Roger Pau Monné wrote:
> > > On Mon, May 12, 2025 at 03:31:19PM +0200, Marek Marczykowski-Górecki
> > > wrote
On 5/12/25 10:58 AM, Andrew Cooper wrote:
> On 12/05/2025 11:58 am, Jan Beulich wrote:
>> On 08.05.2025 18:03, Andrew Cooper wrote:
>>> The text for CONFIG_INDIRECT_THUNK isn't really correct, and was already
>>> stale
>>> by the time speculative vulnerabilities hit the headlines in 2018. It is
>
On 13/05/2025 12:04 am, Demi Marie Obenour wrote:
> On 5/12/25 2:25 PM, Elliott Mitchell wrote:
>> On Mon, May 12, 2025 at 03:00:18PM +0200, Jan Beulich wrote:
>>> On 12.05.2025 14:09, Andrew Cooper wrote:
Now for the (new) controversial part. Since sending this, Linux has
decided to jus
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
Only read the HVM union b_info->u.hvm on HVM guests. The union
access is not guarded, so this reads even on non-HVM guests. Usually
this doesn't matter as PV and PVH unions are smaller and
zero-initialized. But it could incorrectly set b_info->altp2m through
aliased data.
Fixes: 0291089f6ea8 ("
From: Stefano Stabellini
dm_op hypercalls might come from userspace and pass memory addresses as
parameters. The memory addresses typically correspond to buffers
allocated in userspace to hold extra hypercall parameters.
On ARM, when CONFIG_ARM64_SW_TTBR0_PAN is enabled, they might not be
access
On 5/12/25 2:25 PM, Elliott Mitchell wrote:
> On Mon, May 12, 2025 at 03:00:18PM +0200, Jan Beulich wrote:
>> On 12.05.2025 14:09, Andrew Cooper wrote:
>>>
>>> Now for the (new) controversial part. Since sending this, Linux has
>>> decided to just #define auto __auto_type for C < 23, in order to s
On 5/12/25 4:08 AM, Roger Pau Monné wrote:
> On Fri, May 09, 2025 at 02:21:57PM -0400, Demi Marie Obenour wrote:
>> On 5/9/25 6:50 AM, Roger Pau Monné wrote:
>>> On Fri, May 09, 2025 at 11:47:36AM +0200, Alejandro Vallejo wrote:
> A Linux driver that needs access to userspace memory
>>>
On 2025-05-12 19:54, Jason Andryuk wrote:
Only read the HVM union b_info->u.hvm on HVM guests. The union
access is not guarded, so this reads even on non-HVM guests. Usually
this doesn't matter as PV and PVH unions are smaller and
zero-initialized. But it could incorrectly set b_info->altp2m t
Hi Stefano,
Stefano Stabellini writes:
> On Wed, 7 May 2025, Volodymyr Babchuk wrote:
>> alpine-3.18-gcc-debug-arm64:
>> + extends: .gcc-arm64-build-debug
>> + variables:
>> +CONTAINER: alpine:3.18-arm64v8
>> +EXTRA_XEN_CONFIG: |
>> + CONFIG_UBSAN=y
>> + CONFIG_UBSAN_FAT
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 instructions are 9 bytes long.
Yes, shouldn't be a problem.
Juergen
Op
Patch 1 is a straight replace of __vmread() with a new vmread() call.
Patch 2 removes __vmread() and updates ECLAIR config; depends on patch 1.
Link to v4:
https://lore.kernel.org/xen-devel/20250426072819.39455-1-dmuk...@ford.com/
Link to CI:
https://gitlab.com/xen-project/people/dmukhin/xen/-/p
From: Denis Mukhin
Use vmread() instead of __vmread() everywhere in the VT-x code.
Suggested-by: Andrew Cooper
Signed-off-by: Denis Mukhin
---
xen/arch/x86/cpu/vpmu_intel.c | 2 +-
xen/arch/x86/hvm/vmx/intr.c | 12 +--
xen/arch/x86/hvm/vmx/realmode.c | 2 +-
xen/arch/x86/hvm/vmx/vm
From: Denis Mukhin
Remove __vmread() and adjust ECLAIR configuration to account for the change.
Signed-off-by: Denis Mukhin
---
docs/misra/function-macro-properties.json | 9 -
xen/arch/x86/include/asm/hvm/vmx/vmx.h| 5 -
2 files changed, 14 deletions(-)
diff --git a/docs/misr
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 instructions are 9 bytes long.
Thanks!
Xin
On 05.05.2025 21:44, Stefano Stabellini wrote:
> On Mon, 5 May 2025, Andrew Cooper wrote:
>> In macros it is common to declare local variables using typeof(param) in
>> order
>> to ensure that side effects are only evaluated once. A consequence of this
>> is
>> double textural expansion of the p
Since commit 434596bbd44a ("x86/smpboot: Write the top-of-stack block in
cpu_smpboot_alloc()"), smp_processor_id() is unconditionally usable on APs.
Drop the global variable.
Also drop the parameter from start_secondary(). It was introduced as unused
in commit e9ac3bbccab0 ("Move initial stack-po
Hello,
Le 12/05/2025 à 11:04, Kevin Lampis a écrit :
> A subset of command-line parameters that are specifically safe to use
> when lockdown mode is enabled are annotated as such.
>
> Signed-off-by: Kevin Lampis
> ---
> xen/arch/arm/domain_build.c | 4 +--
> xen/arch/x86/acpi/cpu_id
On 12/05/2025 11:27 am, Jan Beulich wrote:
> On 06.05.2025 18:23, Kevin Lampis wrote:
>> Add lockdown mode
>>
>> 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-lin
After some experimentation, using .a/.b makes far better logic than using the
named fields, as both Clang and GCC spill idte to the stack when named fields
are used.
GCC seems to do something very daft for the addr1 field. It takes addr,
shifts it by 32, then ANDs with 0x0UL, whic
On 06.05.2025 16:32, Ross Lagerwall wrote:
> In preparation for adding support for livepatch signing, add support for
> RSA crypto.
If this is needed just for live-patch, ...
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -28,6 +28,7 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o livepat
On Mon, May 12, 2025 at 1:09 PM Andrew Cooper wrote:
>
> On 12/05/2025 12:59 pm, Jan Beulich wrote:
> > On 05.05.2025 21:44, Stefano Stabellini wrote:
> >> On Mon, 5 May 2025, Andrew Cooper wrote:
> >>> In macros it is common to declare local variables using typeof(param) in
> >>> order
> >>> to
On 09.05.25 10:18, Xin Li wrote:
On 5/6/2025 2:20 AM, Juergen Gross wrote:
Instead of having callback functions for rdmsr/wrmsr on native, switch
to inline the respective instructions directly in order to avoid
overhead with the call interface.
To me, this is a beneficial addition to the exist
On 08.05.2025 18:03, Andrew Cooper wrote:
> The text for CONFIG_INDIRECT_THUNK isn't really correct, and was already stale
> by the time speculative vulnerabilities hit the headlines in 2018. It is
> specifically an out-of-line-ing mechansim, and repoline is one of several
> safety sequences used.
Now with the mentioned patch really attached. :-)
On 12.05.25 13:20, Jürgen Groß wrote:
On 09.05.25 10:18, Xin Li wrote:
On 5/6/2025 2:20 AM, Juergen Gross wrote:
Instead of having callback functions for rdmsr/wrmsr on native, switch
to inline the respective instructions directly in order to a
On 12/05/2025 11:50 am, Jan Beulich wrote:
> On 08.05.2025 10:51, Andrew Cooper wrote:
>> On 07/05/2025 2:54 pm, Gerald Elder-Vass wrote:
>> Also,
>>
>>> ld: warning: orphan section `.sbat' from `prelink.o' being placed in
>>> section `.sbat'
>> This is because sbat.o is getting linked into the no
On 10.05.2025 01:28, Stefano Stabellini wrote:
> From: Federico Serafini
>
> MISRA C Rule 14.3 states that "Controlling expressions shall not be
> invariant".
>
> Change the #define to static inline to resolve the violation.
>
> Signed-off-by: Federico Serafini
> Signed-off-by: Victor Lira
>
On 12/05/2025 12:59 pm, Jan Beulich wrote:
> On 05.05.2025 21:44, Stefano Stabellini wrote:
>> On Mon, 5 May 2025, Andrew Cooper wrote:
>>> In macros it is common to declare local variables using typeof(param) in
>>> order
>>> to ensure that side effects are only evaluated once. A consequence of
On Mon, May 12, 2025 at 12:26:09PM +0200, Roger Pau Monné wrote:
> On Thu, May 08, 2025 at 10:44:36PM +0200, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > I wanted to post another revision of the series adding hw12 runner,
> > hoping that all known issues are fixed now, but unfortunately there
On 12.05.2025 12:39, Gerald Elder-Vass wrote:
> --- a/xen/arch/x86/efi/Makefile
> +++ b/xen/arch/x86/efi/Makefile
> @@ -6,11 +6,19 @@ cmd_objcopy_o_ihex = $(OBJCOPY) -I ihex -O binary $< $@
> $(obj)/%.o: $(src)/%.ihex FORCE
> $(call if_changed,objcopy_o_ihex)
>
> +$(obj)/sbat.o: OBJCOPYFLA
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_APPLY* to apply the
> patch.
> 4. *XEN_SYSCTL_LIVEPATCH_GET* to
On 12.05.2025 14:09, Andrew Cooper wrote:
> On 12/05/2025 12:59 pm, Jan Beulich wrote:
>> On 05.05.2025 21:44, Stefano Stabellini wrote:
>>> On Mon, 5 May 2025, Andrew Cooper wrote:
In macros it is common to declare local variables using typeof(param) in
order
to ensure that side ef
On Mon, May 12, 2025 at 04:19:59PM +0200, Roger Pau Monné wrote:
> On Mon, May 12, 2025 at 03:31:19PM +0200, Marek Marczykowski-Górecki wrote:
> > On Mon, May 12, 2025 at 12:26:09PM +0200, Roger Pau Monné wrote:
> > > On Thu, May 08, 2025 at 10:44:36PM +0200, Marek Marczykowski-Górecki
> > > wrote
On Mon, May 12, 2025 at 04:20:30PM +0200, Jan Beulich wrote:
> On 06.05.2025 10:31, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/pv/emul-priv-op.c
> > +++ b/xen/arch/x86/pv/emul-priv-op.c
> > @@ -1193,17 +1193,18 @@ static int cf_check cache_op(
> > {
> > ASSERT(op == x86emul_wbinvd || op ==
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 this case but since it is always set in
libxenctrl it seem
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 with the original state_count.
Secondly, the states
1 - 100 of 126 matches
Mail list logo
