linux-kernel - Re: [PATCH] PR_SPEC_DISABLE

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: <20200907171825.GB13281@willie-the-truck>
Date:   Mon, 7 Sep 2020 18:18:25 +0100
From:   Will Deacon <will@...nel.org>
To:     Anthony Steinhauser <asteinhauser@...gle.com>
Cc:     linux-kernel@...r.kernel.org, catalin.marinas@....com,
        maz@...nel.org
Subject: Re: [PATCH] PR_SPEC_DISABLE_NOEXEC support for arm64.

On Fri, Jul 17, 2020 at 04:05:32AM -0700, Anthony Steinhauser wrote:
> For x64 it was already implemented in:
> https://github.com/torvalds/linux/commit/71368af
> 
> The rationale is the same as for the x64 implementation.
> 
> Signed-off-by: Anthony Steinhauser <asteinhauser@...gle.com>
> ---
> 
> It's actively attempted by OpenJDK on arm64 CentOS and Fedora:
> https://git.centos.org/rpms/java-11-openjdk/blob/c8s/f/SOURCES/rh1566890-CVE_2018_3639-speculative_store_bypass.patch
> 
>  arch/arm64/include/asm/ssbd.h | 28 ++++++++++++++++++++++++++++
>  arch/arm64/kernel/process.c   | 13 +++++++++++++
>  arch/arm64/kernel/ssbd.c      | 34 +++++++++++++++++-----------------
>  3 files changed, 58 insertions(+), 17 deletions(-)
>  create mode 100644 arch/arm64/include/asm/ssbd.h

As a heads up: I'm currently reworking most of this, and hope to post
something within the next two weeks.

> diff --git a/arch/arm64/include/asm/ssbd.h b/arch/arm64/include/asm/ssbd.h
> new file mode 100644
> index 000000000000..68c716dc5811
> --- /dev/null
> +++ b/arch/arm64/include/asm/ssbd.h
> @@ -0,0 +1,28 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2020 Google LLC.
> + */
> +#ifndef __ASM_SSBD_H
> +#define __ASM_SSBD_H
> +
> +#include <linux/compat.h>
> +#include <linux/sched/task_stack.h>
> +#include <linux/thread_info.h>
> +
> +static inline void ssbd_ssbs_enable(struct task_struct *task)
> +{
> +	u64 val = is_compat_thread(task_thread_info(task)) ?
> +		PSR_AA32_SSBS_BIT : PSR_SSBS_BIT;
> +
> +	task_pt_regs(task)->pstate |= val;
> +}
> +
> +static inline void ssbd_ssbs_disable(struct task_struct *task)
> +{
> +	u64 val = is_compat_thread(task_thread_info(task)) ?
> +		PSR_AA32_SSBS_BIT : PSR_SSBS_BIT;
> +
> +	task_pt_regs(task)->pstate &= ~val;
> +}

I'd prefer to keep these where they are and have an out-of-line call if
necessary. We should try to keep the SSBD stuff in one place.

> +
> +#endif	/* __ASM_SSBD_H */
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 6089638c7d43..ad3c67c86c4c 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -54,6 +54,7 @@
>  #include <asm/mmu_context.h>
>  #include <asm/processor.h>
>  #include <asm/pointer_auth.h>
> +#include <asm/ssbd.h>
>  #include <asm/stacktrace.h>
>  
>  #if defined(CONFIG_STACKPROTECTOR) && !defined(CONFIG_STACKPROTECTOR_PER_TASK)
> @@ -588,6 +589,18 @@ void arch_setup_new_exec(void)
>  	current->mm->context.flags = is_compat_task() ? MMCF_AARCH32 : 0;
>  
>  	ptrauth_thread_init_user(current);
> +
> +	/*
> +	 * Don't inherit TIF_SSBD across exec boundary when
> +	 * PR_SPEC_DISABLE_NOEXEC is used.
> +	 */
> +	if (test_thread_flag(TIF_SSBD) &&
> +	    task_spec_ssb_noexec(current)) {
> +		clear_thread_flag(TIF_SSBD);
> +		task_clear_spec_ssb_disable(current);
> +		task_clear_spec_ssb_noexec(current);
> +		ssbd_ssbs_enable(current);
> +	}

How is this supposed to work with CPUs that expose SSBS directly to
userspace? I suppose we should be using PR_SPEC_DISABLE_NOEXEC to decide
what we set the SSBS bit to on exec, but the logic here requires TIF_SSBD
to be set and so won't trigger afaict.

Will