[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrWo8q1xPVd26z5Zij34UjqtKgqM1ma4vBkajLCoJ51A2g@mail.gmail.com>
Date: Tue, 21 Jul 2015 16:40:14 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Willy Tarreau <w@....eu>
Cc: Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
"security@...nel.org" <security@...nel.org>,
X86 ML <x86@...nel.org>, Borislav Petkov <bp@...en8.de>,
Sasha Levin <sasha.levin@...cle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>
Subject: Re: [PATCH v2 3/3] selftests/x86, x86/ldt: Add a selftest for modify_ldt
On Tue, Jul 21, 2015 at 4:36 PM, Willy Tarreau <w@....eu> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists