[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170309160551.GC11966@leverpostej>
Date: Thu, 9 Mar 2017 16:05:52 +0000
From: Mark Rutland <mark.rutland@....com>
To: Thomas Garnier <thgarnie@...gle.com>
Cc: David Howells <dhowells@...hat.com>,
Dave Hansen <dave.hansen@...el.com>, Arnd Bergmann <arnd@...db.de>,
Al Viro <viro@...iv.linux.org.uk>,
René Nyffenegger <mail@...enyffenegger.ch>,
Andrew Morton <akpm@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>,
"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
"David S . Miller" <davem@...emloft.net>,
Andy Lutomirski <luto@...nel.org>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Nicolas Pitre <nicolas.pitre@...aro.org>,
Petr Mladek <pmladek@...e.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Helge Deller <deller@....de>, Rik van Riel <riel@...hat.com>,
Ingo Molnar <mingo@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
John Stultz <john.stultz@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Pavel Tikhomirov <ptikhomirov@...tuozzo.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Stephen Smalley <sds@...ho.nsa.gov>,
Stanislav Kinsburskiy <skinsbursky@...tuozzo.com>,
Ingo Molnar <mingo@...hat.com>, "H . Peter Anvin" <hpa@...or.com>,
Paolo Bonzini <pbonzini@...hat.com>, Borislav Petkov <bp@...en8.de>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Brian Gerst <brgerst@...il.com>, Jan Beulich <JBeulich@...e.com>,
Christian Borntraeger <borntraeger@...ibm.com>,
"Luis R . Rodriguez" <mcgrof@...nel.org>,
He Chen <he.chen@...ux.intel.com>,
Russell King <linux@...linux.org.uk>,
Will Deacon <will.deacon@....com>,
Catalin Marinas <catalin.marinas@....com>,
James Morse <james.morse@....com>,
Pratyush Anand <panand@...hat.com>,
Vladimir Murzin <vladimir.murzin@....com>,
Chris Metcalf <cmetcalf@...lanox.com>,
Andre Przywara <andre.przywara@....com>,
Linux API <linux-api@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
the arch/x86 maintainers <x86@...nel.org>,
linux-arm-kernel@...ts.infradead.org,
Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH v2 4/4] arm64/syscalls: Specific usage of
verify_pre_usermode_state
On Thu, Mar 09, 2017 at 07:56:49AM -0800, Thomas Garnier wrote:
> On Thu, Mar 9, 2017 at 4:23 AM, Mark Rutland <mark.rutland@....com> wrote:
> > We generally stick to lower case for the arm64 assembly macros. If we
> > need this, we should stick to the existing convention.
> >
> >> +/* Similar to set_fs(USER_DS) in verify_pre_usermode_state without a warning. */
> >> +.macro VERIFY_PRE_USERMODE_STATE
> >> + mov x1, #TASK_SIZE_64
> >> + str x1, [tsk, #TSK_TI_ADDR_LIMIT]
> >> +.endm
> >
> > We need arm64's set_fs() to configure UAO, too, so this is much weaker
> > than set_fs(), and will leave __{get,put}_user and
> > __copy_{to,from}_user() able to access kernel memory.
> >
> > We don't currently have an asm helper to clear UAO, and unconditionally
> > poking that on exception return is liable to be somewhat expensive.
> >
> > Also, given we're only trying to catch this in syscalls, I'm afraid I
> > don't see what we gain by doing this in the entry assembly.
>
> I optimized all architectures from the arm (32-bit) discussion. I will
> come back to a simple bl to the verify function. Thanks!
What I was trying to ask was do we need to touch the assembly at all
here?
Are we trying to protect the non-syscall cases by doing this in
assembly? If so, it'd be worth calling out in the commit message.
If so, we could add the necessary helper to clear UAO.
If not, doing this in the entry assembly only saves the small overhead
of reading and comparing the addr_limit for in-kernel use of the
syscalls (e.g. in the compat wrappers), and we may as well rely on the
common !ARCH_NO_SYSCALL_VERIFY_PRE_USERMODE_STATE implementation.
Thanks,
Mark.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
