linux-kernel - Re: [PATCH v4 19/36] arm64/gcs: Allocate a new GCS for threads with GCS enabled

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: <3a01ce20-3365-421b-95ff-211946808174@sirena.org.uk>
Date:   Fri, 18 Aug 2023 21:15:15 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     Will Deacon <will@...nel.org>, Jonathan Corbet <corbet@....net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Marc Zyngier <maz@...nel.org>,
        Oliver Upton <oliver.upton@...ux.dev>,
        James Morse <james.morse@....com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Arnd Bergmann <arnd@...db.de>, Oleg Nesterov <oleg@...hat.com>,
        Eric Biederman <ebiederm@...ssion.com>,
        Kees Cook <keescook@...omium.org>,
        Shuah Khan <shuah@...nel.org>,
        "Rick P. Edgecombe" <rick.p.edgecombe@...el.com>,
        Deepak Gupta <debug@...osinc.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Szabolcs Nagy <Szabolcs.Nagy@....com>,
        "H.J. Lu" <hjl.tools@...il.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
        kvmarm@...ts.linux.dev, linux-fsdevel@...r.kernel.org,
        linux-arch@...r.kernel.org, linux-mm@...ck.org,
        linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v4 19/36] arm64/gcs: Allocate a new GCS for threads with
 GCS enabled

On Fri, Aug 11, 2023 at 05:26:03PM +0100, Catalin Marinas wrote:
> On Mon, Aug 07, 2023 at 11:00:24PM +0100, Mark Brown wrote:

> > +	mmap_write_lock(mm);
> > +	mapped_addr = do_mmap(NULL, addr, size, PROT_READ, flags,
> > +			      VM_SHADOW_STACK | VM_WRITE, 0, &unused, NULL);

> Why not PROT_WRITE as well? I guess I need to check the x86 patches
> since the do_mmap() called here has a different prototype than what's in
> mainline.

> This gets confusing since currently the VM_* flags are derived from the
> PROT_* flags passed to mmap(). But you skip the PROT_WRITE in favour of
> adding VM_WRITE directly.

I have to confess that I inherited this from the x86 code and never
thought too hard about it.  I've got a horrible feeling the reasoning is
simply the way in which x86 fits shadow stack into the page tables
without having a mechanism like permission indirection, these don't
apply for us.

> I haven't followed the x86 discussion but did we run out of PROT_* bits
> for a PROT_SHADOW_STACK?

It's more that there are security concerns with having PROT_, especially
in conjunction with needing to provide a token for stack pivot - we not
only need to map pages for the GCS, we also need to write a cap token
into it so that we can pivot to the new stack.  If the GCS can ever be
written to by userspace via normal means then that's an issue for the
basic protection model that the feature is trying to implement.  If we
have the PROT_ but try to check for bad uses of it that makes everything
messy and complicated which is especially non-ideal for a feature with a
security focus.  Having a more packaged system call is easier for
everyone.

More detail in the x86 patch that's currently in -next:

   https://lore.kernel.org/all/20230319001535.23210-34-rick.p.edgecombe@intel.com/

> > +	/* Allocate RLIMIT_STACK with limits of PAGE_SIZE..4G */
> > +	size = PAGE_ALIGN(min_t(unsigned long long,
> > +				rlimit(RLIMIT_STACK), SZ_4G));
> > +	return max(PAGE_SIZE, size);
> > +}

> I saw Szabolcs commenting on the default size as well. Maybe we should
> go for RLIMIT_STACK/2 but let's see how the other sub-thread is going.

I've updated it.

> > +	if ((clone_flags & (CLONE_VFORK | CLONE_VM)) != CLONE_VM)
> > +		return 0;

> Is it safe for CLONE_VFORK not to get a new shadow stack? A syscall for
> exec could push something to the stack. I guess the GCS pointer in the
> parent stays the same, so it wouldn't matter.

Yes, pushing should be fine just as for the regular stack.

> That said, I think this check should be somewhere higher up in the
> caller of gcs_alloc_thread_stack(). The copy_thread_gcs() function
> already does most of the above checks. Is the GCS allocation called from
> elsewhere as well?

That's the only place.  I've moved the above check into copy_thread_gcs(),
you're right that the other checks are redundant as they're done in the
caller already.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)