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: Tue, 25 Aug 2020 16:15:26 +0200 From: Christophe Leroy <christophe.leroy@...roup.eu> To: Michael Ellerman <mpe@...erman.id.au>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, Paul Mackerras <paulus@...ba.org>, nathanl@...ux.ibm.com Cc: linux-arch@...r.kernel.org, arnd@...db.de, linux-kernel@...r.kernel.org, luto@...nel.org, tglx@...utronix.de, vincenzo.frascino@....com, linuxppc-dev@...ts.ozlabs.org Subject: Re: [PATCH v8 2/8] powerpc/vdso: Remove __kernel_datapage_offset and simplify __get_datapage() Le 04/08/2020 à 13:17, Christophe Leroy a écrit : > > > On 07/16/2020 02:59 AM, Michael Ellerman wrote: >> Christophe Leroy <christophe.leroy@....fr> writes: >>> The VDSO datapage and the text pages are always located immediately >>> next to each other, so it can be hardcoded without an indirection >>> through __kernel_datapage_offset >>> >>> In order to ease things, move the data page in front like other >>> arches, that way there is no need to know the size of the library >>> to locate the data page. >>> [...] >> >> I merged this but then realised it breaks the display of the vdso in >> /proc/self/maps. >> >> ie. the vdso vma gets no name: >> >> # cat /proc/self/maps [...] >> >> >> And it's also going to break the logic in arch_unmap() to detect if >> we're unmapping (part of) the VDSO. And it will break arch_remap() too. >> >> And the logic to recognise the signal trampoline in >> arch/powerpc/perf/callchain_*.c as well. > > I don't think it breaks that one, because ->vdsobase is still the start > of text. > >> >> So I'm going to rebase and drop this for now. >> >> Basically we have a bunch of places that assume that vdso_base is == the >> start of the VDSO vma, and also that the code starts there. So that will >> need some work to tease out all those assumptions and make them work >> with this change. > > Ok, one day I need to look at it in more details and see how other > architectures handle it etc ... > I just sent out a series which switches powerpc to the new _install_special_mapping() API, the one powerpc uses being deprecated since commit a62c34bd2a8a ("x86, mm: Improve _install_special_mapping and fix x86 vdso naming") arch_remap() gets replaced by vdso_remap() For arch_unmap(), I'm wondering how/what other architectures do, because powerpc seems to be the only one to erase the vdso context pointer when unmapping the vdso. So far I updated it to take into account the pages switch. Everything else is not impacted because our vdso_base is still the base of the text and that's what those things (signal trampoline, callchain, ...) expect. Maybe we should change it to 'void *vdso' in the same way as other architectures, as it is not anymore the exact vdso_base but the start of VDSO text. Note that the series applies on top of the generic C VDSO implementation series. However all but the last commit cleanly apply without that series. As that last commit is just an afterwork cleanup, it can come in a second step. Christophe
Powered by blists - more mailing lists