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: <203a89bc-75d1-4ab0-ab42-52616103ad72@sirena.org.uk>
Date: Tue, 25 Mar 2025 18:23:16 +0000
From: Mark Brown <broonie@...nel.org>
To: Jeremy Linton <jeremy.linton@....com>
Cc: linux-trace-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
	mhiramat@...nel.org, oleg@...hat.com, peterz@...radead.org,
	acme@...nel.org, namhyung@...nel.org, mark.rutland@....com,
	alexander.shishkin@...ux.intel.com, jolsa@...nel.org,
	irogers@...gle.com, adrian.hunter@...el.com,
	kan.liang@...ux.intel.com, thiago.bauermann@...aro.org,
	yury.khrustalev@....com, kristina.martsenko@....com,
	liaochang1@...wei.com, catalin.marinas@....com, will@...nel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/7] arm64: uaccess: Add additional userspace GCS
 accessors

On Fri, Mar 21, 2025 at 06:43:23PM -0500, Jeremy Linton wrote:
> On 3/19/25 8:24 AM, Mark Brown wrote:

> > A GCS load done by the hardware will verify that we are loading from GCS
> > memory (the accesses are marked as AccessType_GCS in the pseudocode
> > which is then validated in for example S1CheckPermissions()).  Sadly
> > there's no equivalent of GCSSTR so we'd need to do the permission check
> > ourselves to match this behaviour.

> Right, except that if I grab the VMA as a placeholder for the page, check to
> see if its a VM_SHADOW_STACK under any of
> map_read_lock()/lock_vma_under_rcu()/etc and then perform the access, the
> resulting possible fault will have problems with vma locking. Otherwise
> there ends up being a few different races that at the moment I've not yet
> figured out how to fix without making a big mess. For example, we can reduce
> that possible window, by reading the value/locking and checking shadow stack
> state/dropping the lock/rereading the value, or some other construct but it
> seems pointless because the suggested problem is that we might be creating a
> way to bypass some of the shadow stack security. In which case, leaving a
> little race is likely the same as leaving it wide open.

Yeah, it's messy.  The "nicest" thing I could think of was doing a GCS
store of the value we just read to validate the GCS permission but that
has very obvious ick and is in it's own way incorrect.  Since the GCS
permission is always read/write I'm not sure what would notice without
an incredibly dodgy race but it's wrong.

> Otherwise, maybe we can ignore the problem, or just refuse to allow probes
> on 'RET' instructions which seems to be the main problematic case. Although,
> given we don't really know if GCS is enabled until the probe is hit,
> SIGSEG'ing the target process is a big hammer.

Yeah, that doesn't feel like the solution.

> Ignoring it might be a valid option. I guess it could to be one of those "if
> the user puts a uprobe on a RET some of the shadow stack security is
> reduced" footguns. If an attacker can also manipulate the address space in a
> way to exploit it then its probably game over anyway. Ideally, the kernel
> would warn on this, but per the conversation around patch 6/7 that seems to
> be off the table.

I'm not completely opposed to just not doing the validation given the
pain with implementing it, it's hard to be enthusiastic about any of the
options really.  If we are going to do something other than fully
and accurately emulate then we should acknowledge what's missing and
why, at least in the changelog and probably also in the code.

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