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: <20180406083436.GA17948@isilmar-4.linta.de> Date: Fri, 6 Apr 2018 10:34:36 +0200 From: Dominik Brodowski <linux@...inikbrodowski.net> To: Ingo Molnar <mingo@...nel.org> Cc: linux-kernel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>, Andi Kleen <ak@...ux.intel.com>, Andrew Morton <akpm@...ux-foundation.org>, Andy Lutomirski <luto@...nel.org>, Brian Gerst <brgerst@...il.com>, Denys Vlasenko <dvlasenk@...hat.com>, "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>, Linus Torvalds <torvalds@...ux-foundation.org>, Peter Zijlstra <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org Subject: Re: [PATCH 0/8] use struct pt_regs based syscall calling for x86-64 On Fri, Apr 06, 2018 at 10:23:22AM +0200, Ingo Molnar wrote: > > * Dominik Brodowski <linux@...inikbrodowski.net> wrote: > > > On Thu, Apr 05, 2018 at 05:19:33PM +0200, Ingo Molnar wrote: > > > Ok, this series looks mostly good to me, but AFAICS this breaks the UML build: > > > > > > make[2]: *** No rule to make target 'archheaders'. Stop. > > > arch/um/Makefile:119: recipe for target 'archheaders' failed > > > make[1]: *** [archheaders] Error 2 > > > make[1]: *** Waiting for unfinished jobs.... > > > > Ah, that's caused by patch 8/8 which I did and do not like all that much > > anyway: UML re-uses syscall_64.tbl which now has x86-specific entries like > > __sys_x86_pread64, but expects the generic syscall stub sys_pread64 > > referenced there. Fixup patch below; could be folded with patch 8/8. Or > > patch 8/8 could simply be dropped from the series altogether... > > I still like the 'truth in advertising' aspect. For example if I see this in the > syscall table: > > 10 common mprotect __sys_x86_mprotect > > I can immediately find the _real_ syscall entry point: > > ffffffff81180a10 <__sys_x86_mprotect>: > ffffffff81180a10: 48 8b 57 60 mov 0x60(%rdi),%rdx > ffffffff81180a14: 48 8b 77 68 mov 0x68(%rdi),%rsi > ffffffff81180a18: b9 ff ff ff ff mov $0xffffffff,%ecx > ffffffff81180a1d: 48 8b 7f 70 mov 0x70(%rdi),%rdi > ffffffff81180a21: e8 fa fc ff ff callq ffffffff81180720 <do_mprotect_pkey> > ffffffff81180a26: 48 98 cltq > ffffffff81180a28: c3 retq > ffffffff81180a29: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) > > If, on the other hand, I see this entry: > > 10 common mprotect sys_mprotect > > Then, as a first step, no symbol anywhere matches with this: > > triton:~/tip> grep sys_mprotect System.map > triton:~/tip> > > "sys_mprotect" does not exist in any easily discoverable sense. You have to *know* > to replace the sys_ prefix with __sys_x86_ to find it. > > Now arguably we could use a __sys_ prefix instead of the grep-barrier __sys_x86 > prefix - but that too would be somewhat confusing I think. Well, if looking at the ARCH="um" kernel, you won't find the __sys_x86_mprotect there in its System.map -- so we either have to disentangle um and plain x86, or live with some cause for confusion. __sys_mprotect as prefix won't work by the way, as the double-underscore __sys_ variant is already used in net/* for internal syscall helpers. Thanks, Dominik
Powered by blists - more mailing lists