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: Sun, 8 Nov 2020 11:04:03 -0800 From: Andy Lutomirski <luto@...nel.org> To: Dmitry Safonov <dima@...sta.com> Cc: LKML <linux-kernel@...r.kernel.org>, Dmitry Safonov <0x7f454c46@...il.com>, Alexander Viro <viro@...iv.linux.org.uk>, Andrew Morton <akpm@...ux-foundation.org>, Andy Lutomirski <luto@...nel.org>, Arnd Bergmann <arnd@...db.de>, Borislav Petkov <bp@...en8.de>, Catalin Marinas <catalin.marinas@....com>, Christophe Leroy <christophe.leroy@...roup.eu>, Guo Ren <guoren@...nel.org>, "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>, Oleg Nesterov <oleg@...hat.com>, Russell King <linux@...linux.org.uk>, Thomas Bogendoerfer <tsbogend@...ha.franken.de>, Thomas Gleixner <tglx@...utronix.de>, Vincenzo Frascino <vincenzo.frascino@....com>, Will Deacon <will@...nel.org>, X86 ML <x86@...nel.org>, "open list:MIPS" <linux-mips@...r.kernel.org> Subject: Re: [PATCH 14/19] mm: Add user_landing in mm_struct On Sat, Nov 7, 2020 at 9:18 PM Dmitry Safonov <dima@...sta.com> wrote: > > Instead of having every architecture to define vdso_base/vdso_addr etc, > provide a generic mechanism to track landing in userspace. > It'll minimize per-architecture difference, the number of callbacks to > provide. > > Originally, it started from thread [1] where the need for .close() > callback on vm_special_mapping was pointed, this generic code besides > removing duplicated .mremap() callbacks provides a cheaper way to > support munmap() on vdso mappings without introducing .close() callbacks > for every architecture (with would bring even more code duplication). I find the naming odd. It's called "user_landing", which is presumably a hard-to-understand shorthand for "user mode landing pad for return from a signal handler if SA_RESTORER is not set". But, looking at the actual code, it's not this at all -- it's just the vDSO base address. So how about just calling it vdso_base? I'm very much in favor of consolidating and cleaning up, and improving the vdso remap/unmap code, but I'm not convinced that we should call it anything other than the vdso base. --Andy
Powered by blists - more mailing lists