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
| ||
|
Message-Id: <20190428054505.GC14896@rapoport-lnx> Date: Sun, 28 Apr 2019 08:45:05 +0300 From: Mike Rapoport <rppt@...ux.ibm.com> To: Peter Zijlstra <peterz@...radead.org> Cc: linux-kernel@...r.kernel.org, Alexandre Chartre <alexandre.chartre@...cle.com>, Andy Lutomirski <luto@...nel.org>, Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>, James Bottomley <James.Bottomley@...senpartnership.com>, Jonathan Adams <jwadams@...gle.com>, Kees Cook <keescook@...omium.org>, Paul Turner <pjt@...gle.com>, Thomas Gleixner <tglx@...utronix.de>, linux-mm@...ck.org, linux-security-module@...r.kernel.org, x86@...nel.org Subject: Re: [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation On Fri, Apr 26, 2019 at 09:49:56AM +0200, Peter Zijlstra wrote: > On Fri, Apr 26, 2019 at 12:45:49AM +0300, Mike Rapoport wrote: > > The initial SCI implementation allows access to any kernel data, but it > > limits access to the code in the following way: > > * calls and jumps to known code symbols without offset are allowed > > * calls and jumps into a known symbol with offset are allowed only if that > > symbol was already accessed and the offset is in the next page > > * all other code access are blocked > > So if you have a large function and an in-function jump skips a page > you're toast. Right :( > Why not employ the instruction decoder we have and unconditionally allow > all direct JMP/CALL but verify indirect JMP/CALL and RET ? Apparently I didn't dig deep enough to find the instruction decoder :) Surely I can use it. > Anyway, I'm fearing the overhead of this one, this cannot be fast. Well, I think that the verification itself is not what will slow things down the most. IMHO, the major overhead is coming from cr3 switch. -- Sincerely yours, Mike.
Powered by blists - more mailing lists