lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <85de6b23-5c15-4651-8604-75ce6473ff08@sirena.org.uk>
Date: Tue, 18 Mar 2025 15:11:32 +0000
From: Mark Brown <broonie@...nel.org>
To: Michael Jeanson <mjeanson@...icios.com>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	Boqun Feng <boqun.feng@...il.com>, Shuah Khan <shuah@...nel.org>,
	linux-kselftest@...r.kernel.org, Aishwarya.TCV@....com,
	Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org
Subject: Re: [PATCH] rseq/selftests: ensure the rseq abi TLS is actually 1024
 bytes

On Tue, Mar 18, 2025 at 10:50:58AM -0400, Michael Jeanson wrote:
> On 2025-03-18 10:01, Mark Brown wrote:
> > On Tue, Mar 11, 2025 at 03:21:45PM -0400, Michael Jeanson wrote:
> > 
> > > Adding the aligned(1024) attribute to the definition of __rseq_abi did
> > > not increase its size to 1024, for this attribute to impact the size of
> > > __rseq_abi it would need to be added to the declaration of 'struct
> > > rseq_abi'. We only want to increase the size of the TLS allocation to
> > > ensure registration will succeed with future extended ABI. Use a union
> > > with a dummy member to ensure we allocate 1024 bytes.

> > This is in today's -next and breaks the build of the KVM selftests:

...

> > since unlike the rseq tests the KVM rseq test includes the UAPI header
> > for rseq which the padded union conflicts with.

> Oh, I missed that, we need a more unique name for the union.

> I'm unfamiliar with the workflow of linux-next, should I send a V2 of the
> current patch, or a new one that applies on top?

It depends on the tree that the patch was applied to - -next merges the
current stat of the maintainer trees daily rather than applying anything
itself.  In this case that's -tip, I think incremental is good for them
but ICBW?

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ