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, 3 Feb 2014 13:11:55 -0800 (PST) From: Roland McGrath <roland@...k.frob.com> To: "H. Peter Anvin" <hpa@...or.com> Cc: Andy Lutomirski <luto@...capital.net>, Stefani Seibold <stefani@...bold.net>, Greg KH <gregkh@...uxfoundation.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Andi Kleen <ak@...ux.intel.com>, Andrea Arcangeli <aarcange@...hat.com>, John Stultz <john.stultz@...aro.org>, Pavel Emelyanov <xemul@...allels.com>, Cyrill Gorcunov <gorcunov@...nvz.org>, andriy.shevchenko@...ux.intel.com, Martin.Runge@...de-schwarz.com, Andreas.Brief@...de-schwarz.com, Jakub Jelinek <jakub@...hat.com> Subject: Re: [PATCH 3/4] Add 32 bit VDSO time support for 32 bit kernel > > config COMPAT_VDSO > > def_bool y > > prompt "Compat VDSO support" > > depends on X86_32 || IA32_EMULATION > > ---help--- > > Map the 32-bit VDSO to the predictable old-style address too. > > > > Say N here if you are running a sufficiently recent glibc > > version (2.3.3 or later), to remove the high-mapped > > VDSO mapping and to exclusively use the randomized VDSO. > > > > If unsure, say Y. > > So we need this for 32-bit glibc < 2.3.3, and we effecively have the > same problem as on 64 bits. Next question is if those old glibcs rely > on the entry point alone or if they also expect the vdso header at that > address. > > I looked at the glibc diffs from 2.3.2 to 2.3.3, but it isn't really > obvious to me what assumptions the 2.3.2 glibc made. Perhaps Roland has > any idea? Jakub often has more reliable memories of these things than I do. >From looking at the old states of the code, AFAICT 2.3.3 was the first version that actually looked at AT_SYSINFO_EHDR or cared about the vDSO per se; 2.3.2 just uses AT_SYSINFO. I have a vague recollection that there was a period wherein ld.so would crash (trying to modify part of the read-only vDSO image in place) if the vDSO was loaded somewhere other than its prelinked location. But I don't see any evidence in the code that there was actually a release made of code with that issue. I'm fairly sure there are some relevant issues that I've forgotten and am overlooking now. > The safest thing for that might be to have the compat vdso be a > completely separate object from the real vdso, and let the former be an > object as similar to the current one as possible. I'm not at all clear on what particular dangers that avoids. Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists