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
| ||
|
Date: Mon, 8 Oct 2018 09:29:56 -0700 From: Andy Lutomirski <luto@...capital.net> To: Peter Zijlstra <peterz@...radead.org> Cc: Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...ux-foundation.org>, Ingo Molnar <mingo@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, Thomas Gleixner <tglx@...utronix.de>, Masami Hiramatsu <mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Matthew Helsley <mhelsley@...are.com>, "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>, David Woodhouse <dwmw2@...radead.org>, Paolo Bonzini <pbonzini@...hat.com>, Josh Poimboeuf <jpoimboe@...hat.com>, Jason Baron <jbaron@...mai.com>, Jiri Kosina <jkosina@...e.cz>, ard.biesheuvel@...aro.org, Andy Lutomirski <luto@...nel.org> Subject: Re: [POC][RFC][PATCH 1/2] jump_function: Addition of new feature "jump_function" > On Oct 8, 2018, at 8:57 AM, Peter Zijlstra <peterz@...radead.org> wrote: > > On Mon, Oct 08, 2018 at 01:33:14AM -0700, Andy Lutomirski wrote: >>> Can't we hijack the relocation records for these functions before they >>> get thrown out in the (final) link pass or something? >> >> I could be talking out my arse here, but I thought we could do this, >> too, then changed my mind. The relocation records give us the >> location of the call or jump operand, but they don’t give the address >> of the beginning of the instruction. > > But that's like 1 byte before the operand, right? We could even double check > this by reading back that byte and ensuring it is in fact 0xE8 (CALL). > > AFAICT there is only the _1_ CALL encoding, and that is the 5 byte: E8 <PLT32>, > so if we have the PLT32 location, we also have the instruction location. Or am > I missing something? There’s also JMP and Jcc, any of which can be used for rail calls, but those are also one byte. I suppose GCC is unlikely to emit a prefixed form of any of these. So maybe we really can assume they’re all one byte. But there is a nasty potential special case: anything that takes the function’s address. This includes jump tables, computed gotos, and plain old function pointers. And I suspect that any of these could have one of the rather large number of CALL/JMP/Jcc bytes before the relocation by coincidence.
Powered by blists - more mailing lists