Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751955AbaGYXy4 (ORCPT ); Fri, 25 Jul 2014 19:54:56 -0400 Received: from mail-lb0-f169.google.com ([209.85.217.169]:34196 "EHLO mail-lb0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751364AbaGYXyy (ORCPT ); Fri, 25 Jul 2014 19:54:54 -0400 MIME-Version: 1.0 In-Reply-To: <53D2EB98.3090802@zytor.com> References: <53D2EB98.3090802@zytor.com> From: Andy Lutomirski Date: Fri, 25 Jul 2014 16:54:32 -0700 Message-ID: Subject: Re: General flags to turn things off (getrandom, pid lookup, etc) To: "H. Peter Anvin" Cc: "Eric W. Biederman" , Julien Tinnes , David Drysdale , Al Viro , Paolo Bonzini , LSM List , Greg Kroah-Hartman , Paul Moore , James Morris , Linux API , Meredydd Luff , Christoph Hellwig , "linux-kernel@vger.kernel.org" , Kees Cook , "Theodore Ts'o" , Henrique de Moraes Holschuh , linux-crypto@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 25, 2014 at 4:43 PM, H. Peter Anvin wrote: > On 07/25/2014 11:30 AM, Andy Lutomirski wrote: >> - 32-bit GDT code segments [huge attack surface] >> - 64-bit GDT code segments [probably pointless] > > I presume you mean s/GDT/LDT/. > > We already don't allow 64-bit LDT code segments. Also, it is unclear to > me how 32-bit LDT segments have a huge attack surface, given that there > will realistically always be a 32-bit *GDT* segment present. I really did mean GDT :) Setting the 32-bit code segment to "not present" (and using seccomp to block modify_ldt) prevents any attempt to exploit bugs in the sysenter and cstar code. It also might prevent exploiting CPU bugs, although I've never heard of a relevant CPU bug in this area. If I actually tried to implement this (which wouldn't be part of the initial implementation), I'd split out the unusual things in __switch_to and friends to a slow path that's only used if weird settings are present (e.g. this, TSC restrictions, etc). But twiddling the present bit on a GDT entry is very fast, I assume -- it's just memory, and I don't think that any flush is needed. Also, if I implement this, I will curse Xen. I might even go so far as to disable the feature entirely if there's a paravirt GDT. Hmm. A separate flag to turn int $0x80 into GPF could have some value, too. --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/