On 5/12/2025 11:06 PM, 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 instructions are 9 bytes long.
On 12/05/2025 21:55, Stewart Hildebrand wrote:
> 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
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
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
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
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
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
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
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 ("
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 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
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 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 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
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
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
>
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
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
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 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
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
On Mon, May 12, 2025 at 12:51 PM Andrew Cooper
wrote:
>
> Kevin: It will be best to resend the series in full.
Ok.
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, 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
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 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.
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 Fri, Apr 25, 2025 at 09:47:57AM -0700, Lira, Victor M wrote:
> I can confirm with the patch the NVME drive can be accessed despite the "not
> mapping BAR" warning from Xen.
> Output log attached.
Thanks a lot for the test, and sorry for the delay in getting back. I
was busy with other stuff an
On 07.05.2025 07:27, Penny, Zheng wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: Tuesday, April 29, 2025 8:52 PM
>>
>> On 14.04.2025 09:40, Penny Zheng wrote:
>>> @@ -573,6 +576,14 @@ ret_t do_platform_op(
>>> }
>>>
>>> case XEN_PM_CPPC:
>>> +if (
On 07.05.2025 05:18, Penny, Zheng wrote:
> [Public]
>
> Hi,
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Tuesday, April 29, 2025 7:47 PM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v4 04/15] xen/cpufreq: refactor cmdline "cpufre
On 06.05.2025 11:11, Penny, Zheng wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: Monday, April 28, 2025 11:57 PM
>>
>> On 14.04.2025 09:40, Penny Zheng wrote:
>>> +if ( cppc_data->flags & XEN_CPPC_CPC )
>>> +{
>>> +if ( cppc_data->cpc.highest_perf == 0 ||
>>> +
On 06.05.2025 09:22, Penny, Zheng wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: Monday, April 28, 2025 11:32 PM
>>
>> On 14.04.2025 09:40, Penny Zheng wrote:
>>> --- a/xen/drivers/cpufreq/cpufreq.c
>>> +++ b/xen/drivers/cpufreq/cpufreq.c
>>> +{
>>> +case XEN_PX_INIT:
>
On 06.05.2025 07:56, Penny, Zheng wrote:
> [Public]
>
> Hi,
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Monday, April 28, 2025 11:32 PM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Anthony PERARD ;
>> Orzel, Michal ; Julien Grall ; Roger
>> Pau Monné ; Stefano St
On 06.05.2025 07:33, Penny, Zheng wrote:
> [Public]
>
> Hi,
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Thursday, April 17, 2025 11:12 PM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH v4 01/15] xen/cpufreq: move "init" flag into
On 06.05.2025 14:55, Roger Pau Monné wrote:
> On Tue, May 06, 2025 at 12:16:00PM +0100, Andrew Cooper wrote:
>> On 06/05/2025 9:31 am, Roger Pau Monne wrote:
>>> When a guest is allowed access to cache control operations such tracking
>>> prevents having to issue a system-wide cache flush, and rath
On 06.05.2025 10:31, Roger Pau Monne wrote:
> @@ -2606,6 +2619,36 @@ unsigned int domain_max_paddr_bits(const struct domain
> *d)
> return bits;
> }
>
> +void vcpu_flush_cache(struct vcpu *curr)
> +{
> +ASSERT(curr == current);
> +ASSERT(cache_flush_permitted(curr->domain));
> +
>
On 06.05.2025 10:31, Roger Pau Monne wrote:
> Such flag is added to the domain create hypercall, and a matching option is
> added to xl and libxl to set the flag: `cache_control`. When the flag is
> set, the domain is allowed the usage of cache control operations. If the
> flag is not explicitly
On 12.05.2025 16:58, 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 06.05.2025 10:31, Roger Pau Monne wrote:
> To better describe the underlying implementation. Define
> cache_flush_permitted() as an alias of has_arch_io_resources(), so that
> current users of cache_flush_permitted() are not effectively modified.
>
> With the introduction of the new handler, 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 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 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 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 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 Mon, May 12, 2025 at 12:26:09PM +0200, Roger Pau Monné wrote:
> > >
Clarify and fix usage of the pmstat hypervisor and tools interfaces
regarding sizes of buffers passed in.
Ross Lagerwall (5):
x86/pmstat: Check size of PMSTAT_get_pxstat buffers
public/sysctl: Clarify usage of pm_{px,cx}_stat
cpufreq: Avoid potential buffer overrun and leak
libxc/PM: Ensur
xc_pm_get_pxstat() requires the caller to allocate the pt and trans_pt
buffers but then calls xc_pm_get_max_px() to determine how big they are
(and hence how much Xen will copy into them). This is susceptible to
races if xc_pm_get_max_px() changes so avoid the problem by requiring
the caller to als
Suggested-by: Jan Beulich
Signed-off-by: Ross Lagerwall
---
* New in v2.
xen/include/public/sysctl.h | 52 -
1 file changed, 40 insertions(+), 12 deletions(-)
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index b0fec271d36f..449f016
If the total returned by Xen is more than the number of elements
allocated, it means that the buffer was too small and so the data is
incomplete. Retry to get all the data.
Signed-off-by: Ross Lagerwall
---
* New in v2.
tools/misc/xenpm.c | 49 +-
1
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
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
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 ==
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: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 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: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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
>
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
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
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 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
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: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
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 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 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 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.
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 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 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 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
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 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 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
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_
1 - 100 of 126 matches
Mail list logo
