Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934099AbbGUXkg (ORCPT ); Tue, 21 Jul 2015 19:40:36 -0400 Received: from mail-lb0-f177.google.com ([209.85.217.177]:34571 "EHLO mail-lb0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933239AbbGUXkf (ORCPT ); Tue, 21 Jul 2015 19:40:35 -0400 MIME-Version: 1.0 In-Reply-To: <20150721233653.GO1063@1wt.eu> References: <20150721233653.GO1063@1wt.eu> From: Andy Lutomirski Date: Tue, 21 Jul 2015 16:40:14 -0700 Message-ID: Subject: Re: [PATCH v2 3/3] selftests/x86, x86/ldt: Add a selftest for modify_ldt To: Willy Tarreau Cc: Andy Lutomirski , Peter Zijlstra , Steven Rostedt , "security@kernel.org" , X86 ML , Borislav Petkov , Sasha Levin , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk , Boris Ostrovsky 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: 3072 Lines: 83 On Tue, Jul 21, 2015 at 4:36 PM, Willy Tarreau wrote: > Hi Andy, > > On Tue, Jul 21, 2015 at 12:59:31PM -0700, Andy Lutomirski wrote: >> This tests general modify_ldt behavior (only writes, so far) as >> well as synchronous updates via IPI. It fails on old kernels. >> >> I called this ldt_gdt because I'll add set_thread_area tests to >> it at some point. > > Quick feedback : at two places you have this : > >> + } else if (errno == ENOSYS) { >> + printf("[OK]\tmodify_ldt is returned -ENOSYS\n"); > > => s/is // > > Please add stdlib.h to avoid this warning I'm getting on 32-bit : > > ldt_gdt.c:286:4: warning: incompatible implicit declaration of built-in function 'exit' [enabled by default] > > And I had to remove xmmintrinsic as suggested by Boris as well. > > > FWIW here's what I'm getting here on 4.1.2 without CONFIG_X86_16BIT > (where nmi_espfix failed), the output is the same for a 32- and a 64-bit > process : > > [OK] LDT entry 0 has AR 0x0040FA00 and limit 0x0000000A > [OK] LDT entry 0 has AR 0x00C0FA00 and limit 0x0000AFFF > [OK] LDT entry 1 is invalid > [OK] LDT entry 2 has AR 0x00C0FA00 and limit 0x0000AFFF > [OK] LDT entry 1 is invalid > [OK] LDT entry 2 has AR 0x00C0FA00 and limit 0x0000AFFF > [OK] LDT entry 2 has AR 0x00D0FA00 and limit 0x0000AFFF > [OK] LDT entry 2 has AR 0x00D07A00 and limit 0x0000AFFF > [OK] modify_ldt rejected 16 bit segment > [OK] LDT entry 2 has AR 0x00D07200 and limit 0x0000AFFF > [OK] LDT entry 2 has AR 0x00D07000 and limit 0x0000AFFF > [OK] LDT entry 2 has AR 0x00D07400 and limit 0x0000AFFF > [OK] LDT entry 2 has AR 0x00507600 and limit 0x0000000A > [OK] LDT entry 2 has AR 0x00507E00 and limit 0x0000000A > [OK] LDT entry 2 has AR 0x00507C00 and limit 0x0000000A > [OK] LDT entry 2 has AR 0x00507A00 and limit 0x0000000A > [OK] LDT entry 2 has AR 0x00507800 and limit 0x0000000A > [OK] LDT entry 2 has AR 0x00507800 and limit 0x0000000A > [RUN] Test fork > [OK] LDT entry 2 has AR 0x00507800 and limit 0x0000000A > [OK] LDT entry 1 is invalid > [OK] Child succeeded > [OK] modify_ldt failure 22 > [OK] modify_ldt rejected 16 bit segment > [OK] modify_ldt rejected 16 bit segment > [OK] modify_ldt rejected 16 bit segment > [OK] modify_ldt rejected 16 bit segment > [OK] modify_ldt rejected 16 bit segment > [OK] modify_ldt rejected 16 bit segment > [OK] LDT entry 0 is invalid > [OK] LDT entry 0 has AR 0x0040F200 and limit 0x00000000 > [OK] LDT entry 0 is invalid > [RUN] Cross-CPU LDT invalidation > [FAIL] 5 of 5 iterations failed That's intentional. Old modify_ldt can leave other threads with stale cached descriptors, which is what you're seeing. --Andy > > Thanks, > Willy > -- Andy Lutomirski AMA Capital Management, LLC -- 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/