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] [thread-next>] [day] [month] [year] [list]
Date: Fri, 2 Feb 2024 17:48:25 +0000
From: Mark Brown <broonie@...nel.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Doug Anderson <dianders@...omium.org>,
	Christian Brauner <brauner@...nel.org>,
	Eric Biederman <ebiederm@...ssion.com>, Jan Kara <jack@...e.cz>,
	Kees Cook <keescook@...omium.org>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] regset: use vmalloc() for regset_get_alloc()

On Fri, Feb 02, 2024 at 03:49:25AM +0000, Al Viro wrote:
> On Thu, Feb 01, 2024 at 07:15:48PM -0800, Doug Anderson wrote:

> > [   45.875574] DOUG: Allocating 279584 bytes, n=17474, size=16,
> > core_note_type=1029

> 0x405, NT_ARM_SVE
>         [REGSET_SVE] = { /* Scalable Vector Extension */
>                 .core_note_type = NT_ARM_SVE,
>                 .n = DIV_ROUND_UP(SVE_PT_SIZE(SVE_VQ_MAX, SVE_PT_REGS_SVE),
>                                   SVE_VQ_BYTES),
>                 .size = SVE_VQ_BYTES,

> IDGI.  Wasn't SVE up to 32 * 2Kbit, i.e. 8Kbyte max?  Any ARM folks around?
> Sure, I understand that it's variable-sized and we want to allocate enough
> for the worst case, but can we really get about 280Kb there?  Context switches
> would be really unpleasant on such boxen...

The architecture itself is limited to 2048 bit vector lengths, and
practical implementations have thus far not exceeded 512 bits with the
overwhelming majority of systems being 128 bit.  2048 is commonly seen
in emulation though.  As well as the 32 Z registers we have 16 P
registers of VQ*2 bytes plus one more register FFR the same size as the
P registers and a header describing the VL and specific format of the
data, all in this regset.

The Linux ABI defines the maximum vector length much larger than the
architecture allows and that define does flow into the kernel code, I
believe this was based on consideration of bits 8:4 of ZCR_ELx[1] which
look like they're earmarked for potential future expansion should 2048
bits ever prove to be insufficient.  We should really do something like
what we did for SME and define down what ptrace uses to the actual
architectural maximum since no system will ever see any more than that,
that'd still result in large allocations but less impressively and
wastefully so.  I'll go and look at doing a patch for that just now.

Unfortunately SVE_VQ_MAX is in the uapi headers, we've already stopped
using it in the test programs due to the overallocation.

[1] https://developer.arm.com/documentation/ddi0601/2023-12/AArch64-Registers/ZCR-EL1--SVE-Control-Register--EL1-?lang=en

> > [   45.884809] DOUG: Allocating 8768 bytes, n=548, size=16, core_note_type=1035
> > [   45.893958] DOUG: Allocating 65552 bytes, n=4097, size=16,
> > core_note_type=1036

> 0x40c, NT_ARM_ZA.
>                 /*
>                  * ZA is a single register but it's variably sized and
>                  * the ptrace core requires that the size of any data
>                  * be an exact multiple of the configured register
>                  * size so report as though we had SVE_VQ_BYTES
>                  * registers. These values aren't exposed to
>                  * userspace.
>                  */
>                 .n = DIV_ROUND_UP(ZA_PT_SIZE(SME_VQ_MAX), SVE_VQ_BYTES),
>                 .size = SVE_VQ_BYTES,

Yup, and SME_VQ_MAX is defined to the actual architectural maximum of
2048 largely due to issues with the size of the allocation for ptrace.
There are not yet any physical implementations of SME so I can't comment
on the actual vector lengths we'll observe in the immediate future.  

I see there's a comment update needed there for s/SVE/SME/ too.

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