[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+CK2bCBS2fKOTmTFm13iv3u5TBPwpoCsYeeP352DVE-gs9GJw@mail.gmail.com>
Date: Tue, 26 Nov 2019 08:50:42 -0500
From: Pavel Tatashin <pasha.tatashin@...een.com>
To: Pavel Tatashin <pasha.tatashin@...een.com>,
James Morris <jmorris@...ei.org>,
Sasha Levin <sashal@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, steve.capper@....com,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Marc Zyngier <marc.zyngier@....com>,
James Morse <james.morse@....com>,
Vladimir Murzin <vladimir.murzin@....com>,
Mark Rutland <mark.rutland@....com>,
Thomas Gleixner <tglx@...utronix.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
allison@...utok.net, info@...ux.net, alexios.zavras@...el.com,
Stefano Stabellini <sstabellini@...nel.org>,
boris.ostrovsky@...cle.com, jgross@...e.com,
Stefan Agner <stefan@...er.ch>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
xen-devel@...ts.xenproject.org,
Russell King - ARM Linux admin <linux@...linux.org.uk>,
Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH v2 0/3] Use C inlines for uaccess
Kees Cook mentioned that it is a good idea to assert the PAN state
during disable/enable. Since, with this change everything is moved to
the same C place, if this hardening is something others also want to
see, I could add it in the next revision of this series. Here are the
options to choose from:
1. Do something similar to what is done in preempt with
CONFIG_PREEMPT_COUNT: keep a boolean (could be optionally enabled by
a config) that is checked when uaccess_enable()/uaccess_disable() are
called. This way we will always check that state even on processors
with hardware PAN and UAO, however, there is going to be this extra
overhead of checking/storing the variable on userland enter/exits even
on systems which have these marcos set to nothing otherwise.
2. Check only in __uaccess_ttbr0_disable()/__uaccess_ttbr0_enable()
that ttbr0_el1 is in the expected state, or add another boolean for
this purpose to thread_info.
3. Keep as is, and do not add extra overhead for this hardening.
Thank you,
Pasha
On Thu, Nov 21, 2019 at 9:24 PM Pavel Tatashin
<pasha.tatashin@...een.com> wrote:
>
> Changelog
> v2:
> - Addressed Russell King's concern by not adding
> uaccess_* to ARM.
> - Removed the accidental change to xtensa
>
> Convert the remaining uaccess_* calls from ASM macros to C inlines.
>
> These patches apply against linux-next. I boot tested ARM64, and
> compile tested ARM changes.
>
> Pavel Tatashin (3):
> arm/arm64/xen: use C inlines for privcmd_call
> arm64: remove uaccess_ttbr0 asm macros from cache functions
> arm64: remove the rest of asm-uaccess.h
>
> arch/arm/include/asm/assembler.h | 2 +-
> arch/arm/include/asm/xen/hypercall.h | 10 +++++
> arch/arm/xen/enlighten.c | 2 +-
> arch/arm/xen/hypercall.S | 4 +-
> arch/arm64/include/asm/asm-uaccess.h | 60 --------------------------
> arch/arm64/include/asm/cacheflush.h | 38 ++++++++++++++--
> arch/arm64/include/asm/xen/hypercall.h | 28 ++++++++++++
> arch/arm64/kernel/entry.S | 6 +--
> arch/arm64/lib/clear_user.S | 2 +-
> arch/arm64/lib/copy_from_user.S | 2 +-
> arch/arm64/lib/copy_in_user.S | 2 +-
> arch/arm64/lib/copy_to_user.S | 2 +-
> arch/arm64/mm/cache.S | 31 +++++--------
> arch/arm64/mm/context.c | 12 ++++++
> arch/arm64/mm/flush.c | 2 +-
> arch/arm64/xen/hypercall.S | 19 +-------
> include/xen/arm/hypercall.h | 12 +++---
> 17 files changed, 115 insertions(+), 119 deletions(-)
> delete mode 100644 arch/arm64/include/asm/asm-uaccess.h
>
> --
> 2.24.0
>
Powered by blists - more mailing lists