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, 9 Feb 2024 20:18:11 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "dietmar.eggemann@....com" <dietmar.eggemann@....com>,
	"broonie@...nel.org" <broonie@...nel.org>, "Szabolcs.Nagy@....com"
	<Szabolcs.Nagy@....com>, "brauner@...nel.org" <brauner@...nel.org>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"debug@...osinc.com" <debug@...osinc.com>, "mgorman@...e.de"
	<mgorman@...e.de>, "vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
	"fweimer@...hat.com" <fweimer@...hat.com>, "mingo@...hat.com"
	<mingo@...hat.com>, "rostedt@...dmis.org" <rostedt@...dmis.org>,
	"hjl.tools@...il.com" <hjl.tools@...il.com>, "tglx@...utronix.de"
	<tglx@...utronix.de>, "vschneid@...hat.com" <vschneid@...hat.com>,
	"shuah@...nel.org" <shuah@...nel.org>, "bristot@...hat.com"
	<bristot@...hat.com>, "hpa@...or.com" <hpa@...or.com>, "peterz@...radead.org"
	<peterz@...radead.org>, "bp@...en8.de" <bp@...en8.de>, "bsegall@...gle.com"
	<bsegall@...gle.com>, "x86@...nel.org" <x86@...nel.org>,
	"juri.lelli@...hat.com" <juri.lelli@...hat.com>
CC: "keescook@...omium.org" <keescook@...omium.org>, "jannh@...gle.com"
	<jannh@...gle.com>, "linux-kselftest@...r.kernel.org"
	<linux-kselftest@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "catalin.marinas@....com"
	<catalin.marinas@....com>, "linux-api@...r.kernel.org"
	<linux-api@...r.kernel.org>, "will@...nel.org" <will@...nel.org>
Subject: Re: [PATCH RFT v5 4/7] fork: Add shadow stack support to clone3()

On Sat, 2024-02-03 at 00:05 +0000, Mark Brown wrote:
> +static bool shstk_consume_token(struct task_struct *tsk,
> +                               unsigned long addr)
> +{
> +       /*
> +        * SSP is aligned, so reserved bits and mode bit are a zero,
> just mark
> +        * the token 64-bit.
> +        */
> +       u64 expected = (addr - SS_FRAME_SIZE) | BIT(0);
> +       u64 val;
> +
> +       /* This should really be an atomic cpmxchg.  It is not. */
> +       __get_user(val, (__user u64 *)addr);
> +       if (val != expected)
> +               return false;
> +
> +       if (write_user_shstk_64((u64 __user *)addr, 0))
> +               return false;
> +
> +       return true;
> +}

So, don't we want to consume the token on the *new* task's MM, which
was already duplicated but still unmapped? In which case I think the
other arch's would need to GUP regardless of the existence of shadow
stack atomic ops.

If so, my question is, can we GUP on the new MM at this point? There is
a lot going in copy_process(). My first suspicion of complication is
the work on the child that happens in cgroup_post_fork().

I wonder about adding a shstk_post_fork() to make it easier to think
about and maintain, even if there are no issues today.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ