Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754608AbbGVEWy (ORCPT ); Wed, 22 Jul 2015 00:22:54 -0400 Received: from mail-lb0-f180.google.com ([209.85.217.180]:33663 "EHLO mail-lb0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752271AbbGVEWv (ORCPT ); Wed, 22 Jul 2015 00:22:51 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Andy Lutomirski Date: Tue, 21 Jul 2015 21:22:30 -0700 Message-ID: Subject: Re: [PATCH v2 1/3] x86/ldt: Make modify_ldt synchronous To: Brian Gerst Cc: Andy Lutomirski , Peter Zijlstra , Steven Rostedt , "security@kernel.org" , X86 ML , Borislav Petkov , Sasha Levin , Linux Kernel Mailing List , Konrad Rzeszutek Wilk , Boris Ostrovsky , stable Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2211 Lines: 47 On Tue, Jul 21, 2015 at 7:53 PM, Brian Gerst wrote: > On Tue, Jul 21, 2015 at 10:12 PM, Andy Lutomirski wrote: >> On Tue, Jul 21, 2015 at 7:01 PM, Brian Gerst wrote: >>> On Tue, Jul 21, 2015 at 3:59 PM, Andy Lutomirski wrote: >>>> modify_ldt has questionable locking and does not synchronize >>>> threads. Improve it: redesign the locking and synchronize all >>>> threads' LDTs using an IPI on all modifications. >>> >>> What does this fix? I can see sending an IPI if the LDT is >>> reallocated, but on every update seems unnecessary. >>> >> >> It prevents nastiness in which you're in user mode with an impossible >> CS or SS, resulting in potentially interesting artifacts in >> interrupts, NMIs, etc. > > By impossible, do you mean a partially updated descriptor when the > interrupt occurs? Would making sure that the descriptor is atomically > updated (using set_64bit()) fix that? > I tried to exploit that once and didn't get very far. If I could cause the LDT to be populated one bit at a time, I think I could materialize a call gate out of thin air. The docs are unclear on what, if anything, the memory ordering rules are. I'm more concerned about the case where a segment register caches a value that is no longer in the LDT. If it's DS, ES, FS, or GS, it results in nondeterministic behavior but is otherwise not a big deal. If it's CS or SS, then an interrupt or exception will write a stack frame with the selectors but IRET can fault. If the interrupt is an NMI and certain other conditions are met and your kernel is older than 4.2-rc3, then you should read the CVE-2015-5157 advisory I'll send tomorrow :) Even on 4.2-rc3, the NMI code still struggles a bit if this happens. With this patch, you can never be in user mode with CS or SS selectors that point at the LDT but don't match the LDT. That makes me a lot more comfortable with modify_ldt. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/