linux-kernel - Re: [PATCH RFT v5 4/7] fork: Add shadow stack support to clone3()

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]

Message-ID: <565ca9697cf26be5509ef4b3c1cc95fa4f692b9f.camel@intel.com>
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.