From: Mark Brown <broonie@kernel.org> To: Dave Martin <Dave.Martin@arm.com> Cc: Will Deacon <will@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, Oleg Nesterov <oleg@redhat.com>, Al Viro <viro@zeniv.linux.org.uk>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Doug Anderson <dianders@chromium.org> Subject: Re: [PATCH] arm64/sve: Lower the maximum allocation for the SVE ptrace regset Date: Mon, 12 Feb 2024 17:09:24 +0000 [thread overview] Message-ID: <b0858303-8289-4371-be62-27da98d57020@sirena.org.uk> (raw) In-Reply-To: <ZcpMabqH+VZv6RCZ@e133344.arm.com> [-- Attachment #1: Type: text/plain, Size: 1108 bytes --] On Mon, Feb 12, 2024 at 04:50:49PM +0000, Dave Martin wrote: > On Sat, Feb 03, 2024 at 12:16:49PM +0000, Mark Brown wrote: > > - .n = DIV_ROUND_UP(SVE_PT_SIZE(SVE_VQ_MAX, SVE_PT_REGS_SVE), > > + .n = DIV_ROUND_UP(SVE_PT_SIZE(ARCH_SVE_VQ_MAX, > > + SVE_PT_REGS_SVE), > > SVE_VQ_BYTES), > Do we need an actual check somewhere that we don't bust this limit? ... > Userspace could specify vl > sve_vl_from_vq(ARCH_SVE_VQ_MAX) in > PTRACE_SETREGSET; I'm not sure exactly what happens there. We already have validation against the actual enumerated limits for the system by virtue of setting the vector length to whatever is specified so we'll limit any overly large vector length down to something we can actually support and then reject an attempt to supply register data if we changed the VL from what the user specified. > Since ZCR_ELx_LEN_MASK was changed from 0x1ff to 0xf, it looks like the > kernel itself will not generate an overlarge VL, although it feels a bit > like this guarantee arrives by accident. > Could ARCH_SVE_VQ_MAX be based on ZCR_ELx_LEN_MASK instead? I guess. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org> To: Dave Martin <Dave.Martin@arm.com> Cc: Will Deacon <will@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, Oleg Nesterov <oleg@redhat.com>, Al Viro <viro@zeniv.linux.org.uk>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Doug Anderson <dianders@chromium.org> Subject: Re: [PATCH] arm64/sve: Lower the maximum allocation for the SVE ptrace regset Date: Mon, 12 Feb 2024 17:09:24 +0000 [thread overview] Message-ID: <b0858303-8289-4371-be62-27da98d57020@sirena.org.uk> (raw) In-Reply-To: <ZcpMabqH+VZv6RCZ@e133344.arm.com> [-- Attachment #1.1: Type: text/plain, Size: 1108 bytes --] On Mon, Feb 12, 2024 at 04:50:49PM +0000, Dave Martin wrote: > On Sat, Feb 03, 2024 at 12:16:49PM +0000, Mark Brown wrote: > > - .n = DIV_ROUND_UP(SVE_PT_SIZE(SVE_VQ_MAX, SVE_PT_REGS_SVE), > > + .n = DIV_ROUND_UP(SVE_PT_SIZE(ARCH_SVE_VQ_MAX, > > + SVE_PT_REGS_SVE), > > SVE_VQ_BYTES), > Do we need an actual check somewhere that we don't bust this limit? ... > Userspace could specify vl > sve_vl_from_vq(ARCH_SVE_VQ_MAX) in > PTRACE_SETREGSET; I'm not sure exactly what happens there. We already have validation against the actual enumerated limits for the system by virtue of setting the vector length to whatever is specified so we'll limit any overly large vector length down to something we can actually support and then reject an attempt to supply register data if we changed the VL from what the user specified. > Since ZCR_ELx_LEN_MASK was changed from 0x1ff to 0xf, it looks like the > kernel itself will not generate an overlarge VL, although it feels a bit > like this guarantee arrives by accident. > Could ARCH_SVE_VQ_MAX be based on ZCR_ELx_LEN_MASK instead? I guess. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-02-12 17:09 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-02-03 12:16 [PATCH] arm64/sve: Lower the maximum allocation for the SVE ptrace regset Mark Brown 2024-02-03 12:16 ` Mark Brown 2024-02-05 17:02 ` Doug Anderson 2024-02-05 17:02 ` Doug Anderson 2024-02-09 17:11 ` Will Deacon 2024-02-09 17:11 ` Will Deacon 2024-02-09 17:40 ` Mark Brown 2024-02-09 17:40 ` Mark Brown 2024-02-05 17:11 ` Dave Martin 2024-02-05 17:11 ` Dave Martin 2024-02-05 17:41 ` Mark Brown 2024-02-05 17:41 ` Mark Brown 2024-02-07 12:23 ` Dave Martin 2024-02-07 12:23 ` Dave Martin 2024-02-07 13:09 ` Mark Brown 2024-02-07 13:09 ` Mark Brown 2024-02-07 13:51 ` Dave Martin 2024-02-07 13:51 ` Dave Martin 2024-02-07 15:07 ` Mark Brown 2024-02-07 15:07 ` Mark Brown 2024-02-12 16:50 ` Dave Martin 2024-02-12 16:50 ` Dave Martin 2024-02-12 17:09 ` Mark Brown [this message] 2024-02-12 17:09 ` Mark Brown
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=b0858303-8289-4371-be62-27da98d57020@sirena.org.uk \ --to=broonie@kernel.org \ --cc=Dave.Martin@arm.com \ --cc=catalin.marinas@arm.com \ --cc=dianders@chromium.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=oleg@redhat.com \ --cc=viro@zeniv.linux.org.uk \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.