[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 22 Mar 2017 13:41:54 -0700
From: Thomas Garnier <thgarnie@...gle.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Andy Lutomirski <luto@...capital.net>, Ingo Molnar <mingo@...nel.org>,
Martin Schwidefsky <schwidefsky@...ibm.com>, Heiko Carstens <heiko.carstens@...ibm.com>,
David Howells <dhowells@...hat.com>, Arnd Bergmann <arnd@...db.de>, Al Viro <viro@...iv.linux.org.uk>,
Dave Hansen <dave.hansen@...el.com>, René Nyffenegger <mail@...enyffenegger.ch>,
Andrew Morton <akpm@...ux-foundation.org>, Kees Cook <keescook@...omium.org>,
"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>, 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>, John Stultz <john.stultz@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>, Oleg Nesterov <oleg@...hat.com>,
Stephen Smalley <sds@...ho.nsa.gov>, Pavel Tikhomirov <ptikhomirov@...tuozzo.com>,
Frederic Weisbecker <fweisbec@...il.com>, Stanislav Kinsburskiy <skinsbursky@...tuozzo.com>,
Ingo Molnar <mingo@...hat.com>, Paolo Bonzini <pbonzini@...hat.com>,
Dmitry Safonov <dsafonov@...tuozzo.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>, Fenghua Yu <fenghua.yu@...el.com>,
He Chen <he.chen@...ux.intel.com>, Russell King <linux@...linux.org.uk>,
Vladimir Murzin <vladimir.murzin@....com>, Will Deacon <will.deacon@....com>,
Catalin Marinas <catalin.marinas@....com>, Mark Rutland <mark.rutland@....com>,
James Morse <james.morse@....com>, "David A . Long" <dave.long@...aro.org>,
Pratyush Anand <panand@...hat.com>, Laura Abbott <labbott@...hat.com>,
Andre Przywara <andre.przywara@....com>, Chris Metcalf <cmetcalf@...lanox.com>,
linux-s390 <linux-s390@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>, "the arch/x86 maintainers" <x86@...nel.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH v3 2/4] x86/syscalls: Specific usage of verify_pre_usermode_state
On Wed, Mar 22, 2017 at 1:21 PM, H. Peter Anvin <hpa@...or.com> wrote:
> On 03/22/17 12:15, Thomas Garnier wrote:
>> On Wed, Mar 15, 2017 at 10:43 AM, Thomas Garnier <thgarnie@...gle.com> wrote:
>>> Thanks for the feedback. I will look into inlining by default (looking
>>> at code size on different arch), the updated patch for x86 in the
>>> meantime:
>>
>> I did couple checks and it doesn't seem worth it. I will send a v4
>> with the change below for additional feedback.
>
> Can you specify what that means?
If I set inline by default, the compiler chose not to inline it on
x86. If I force inline the size impact was actually bigger (without
the architecture specific code).
>
> On x86, where there is only one caller of this, it really seems like it
> ought to reduce the overhead to almost zero (since it most likely is
> hidden in the pipeline.)
>
> I would like to suggest defining it inline if
> CONFIG_ARCH_NO_SYSCALL_VERIFY_PRE_USERMODE_STATE is set; I really don't
> care about an architecture which doesn't have it.
But if there is only one caller, does the compiler is not suppose to
inline the function based on options?
The assembly will call it too, so I would need an inline and a
non-inline based on the caller.
>
> Note that the upcoming 5-level paging (LA57) support will make
> TASK_SIZE_MAX dependent on the CPU. The best way to handle that is
> probably to tag this immediate with an assembly alternative rather than
> loading it from a memory variable (most likely taking a cache hit.)
>
> -hpa
>
--
Thomas
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.
