On Jan 8, 2015 2:17 AM, "Jiri Slaby" <jslaby@xxxxxxx> wrote: > > On 01/08/2015, 02:49 AM, Andy Lutomirski wrote: > > On Wed, Jan 7, 2015 at 5:01 PM, Greg KH <greg@xxxxxxxxx> wrote: > >> On Tue, Jan 06, 2015 at 07:53:14PM +0100, Andi Kleen wrote: > >>> On Tue, Jan 06, 2015 at 05:34:44PM +0100, Jiri Slaby wrote: > >>>> From: Andy Lutomirski <luto@xxxxxxxxxxxxxx> > >>>> > >>>> This patch has been added to the 3.12 stable tree. If you have any > >>>> objections, please let us know. > >>> > >>> IMHO this is not stable material. Significant risk you broke > >>> something obscure, and it's not clear it fixes any real problem. > >> > >> Then why is it in Linus's tree? > >> > >>> At least wait some more time first. > >> > >> How long should we wait? 3.19 to be released? This does seem to fix a > >> real problem as the changelog points out. > > > > It even has a CVE (CVE-2014-9419). > > Hi, is the patch needed for kernels < 3.14 (before kASLR)? The commit > message is so poor, that I do not see what it fixes at all. Could you > elaborate? > The attack is against user ASLR, not kASLR. A malicious process can set es to point to the TLS slot that arch_prctl(ARCH_SET_FS) uses for offsets < 4GB. Then the malicious process does something to get scheduled out and scheduled back in directly after the target thread. When this happens, es will have the same value, but the cached segment base will match the target's TLS base. The attacker can now learn the target's TLS base by dereferencing an es-relative pointer and figuring out which linear address is accessed. There are a couple of ways to do that. Hmm. On my system, both PIE and non-PIE 64-bit executables seem to put their TLS base in mmap space, which is far above 4GB. So this attack may only work against 32-bit targets. Maybe we should just get rid of the fsbase/gsbase-via-GDT optimization. (If we did that, then we could go farther and turn TLS off entirely on non-compat kernels.) Andi, I think the 64-bit TLS code. Do you recall what the <4GB optimization is for? --Andy > I indeed can run estest with failures on 3.12. But what does it mean to > me would be nice to have explained... > > thanks, > -- > js > suse labs -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html