From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753891AbaDWGZE (ORCPT ); Wed, 23 Apr 2014 02:25:04 -0400 Received: from terminus.zytor.com ([198.137.202.10]:60545 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752865AbaDWGZB (ORCPT ); Wed, 23 Apr 2014 02:25:01 -0400 Message-ID: <53575C84.6080801@zytor.com> Date: Tue, 22 Apr 2014 23:24:04 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Linus Torvalds , Andrew Lutomirski CC: Borislav Petkov , "H. Peter Anvin" , Linux Kernel Mailing List , Ingo Molnar , Alexander van Heukelum , Konrad Rzeszutek Wilk , Boris Ostrovsky , Arjan van de Ven , Brian Gerst , Alexandre Julliard , Andi Kleen , Thomas Gleixner Subject: Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE* References: <5355A9E9.9070102@zytor.com> <1dbe8155-58da-45c2-9dc0-d9f4b5a6e643@email.android.com> <20140422112312.GB15882@pd.tnic> <20140422144659.GF15882@pd.tnic> <53569467.1030809@zytor.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/22/2014 10:04 AM, Linus Torvalds wrote: > > The segment table is shared for a process. So you can have one thread > doing a load_ldt() that invalidates a segment, while another thread is > busy taking a page fault. The segment was valid at page fault time and > is saved on the kernel stack, but by the time the page fault returns, > it is no longer valid and the iretq will fault. > > Anyway, if done correctly, this whole espfix should be totally free > for normal processes, since it should only trigger if SS is a LDT > entry (bit #2 set in the segment descriptor). So the normal fast-path > should just have a simple test for that. > > And if you have a SS that is a descriptor in the LDT, nobody cares > about performance any more. > I just realized that with the LDT being a process-level object (unlike the GDT), we need to remove the filtering on the espfix hack, both for 32-bit and 64-bit kernels. Otherwise there is a race condition between executing the LAR instruction in the filter and the IRET, which could allow the leak to become manifest. The "good" part is that I think the espfix hack is harmless even with a 32/64-bit stack segment, although it has a substantial performance penalty. Does anyone have any idea if there is a real use case for non-16-bit LDT segments used as the stack segment? Does Wine use anything like that? Very old NPTL Linux binaries use LDT segments, but only for data segments. -hpa