From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x227/dgT4k5FppWxDxUiyaemvmBbvmSBT6pAyf9wZ0e+DN8jGGHl1w/xd/zYV6y32+yRvrJgJ ARC-Seal: i=1; a=rsa-sha256; t=1517243857; cv=none; d=google.com; s=arc-20160816; b=R75MD7L0vrn1PC/0bO2B1slqnJkRageSpMSqn3ygSlJf0NpBoJqTd0Jza74Qz4GYrM twC8uod3TY7OYueRMPnl7ccuGj7gO+xQ1it55GS66CxrZM/cDXrlyKamuA7pRz0VTsfS j1DDNKB2wvETw8sNoSoc6cbeEaHedlIW7vXblabMJzZwRjdYuJOGhfyE+AScU8byYYng 5bK6hcKH8FvwxUvJYytTkdE6Ylqg49Q9mQB87yNMbFbkznjHW5+Mz4nOyXlcaSbeEJy8 XRN8pmSzfL/ALhDFzm21KO6br7oBToooqnLqO7QWAuR4fsFLQXGNpQ2DOIF84B6Mmaz6 HgbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dmarc-filter :arc-authentication-results; bh=belinsnpxDJT6ALG16xmhvpf1Hmz7ylJqkhsknfGxjI=; b=eedu9COWwASUV24SZeTPvOTKat3zbT9HgPsqnUkSFkzeQlgAHFykDUX6fpTp2eCUMw g6GyU57QoYMu2A4ZxCQd3cBuNa5kVPtXPnA1Ry8QJPZ1cxYuxN+ZDHD+A+uAGtihz5rD nlmvtrBhGjG0H1Af6EJRcLUoKy/ImSW4hPd9s784CTgfaPB91bwGJ7vg6NJqZC7FwnaX MH1HjEpvgibH+L7zp2+uDhJSlohy335bTkCY761mrVVyumTWomBUuy+LG+/jxuQ1MkIu jzwBK9a0DGC5+MLAqu04jm44qlQ1FHYD9TNiVaAlMaMpFChyeQK1FArCPxnG7Qaky5Ut qyyw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kselftest-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kselftest-owner@vger.kernel.org Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kselftest-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kselftest-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751717AbeA2Qhg (ORCPT ); Mon, 29 Jan 2018 11:37:36 -0500 Received: from mail.kernel.org ([198.145.29.99]:46522 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751546AbeA2Qhg (ORCPT ); Mon, 29 Jan 2018 11:37:36 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6DFA621796 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org MIME-Version: 1.0 In-Reply-To: <46328204-e363-e517-f30c-c8c94ac1442c@zytor.com> References: <20180126153631.ha7yc33fj5uhitjo@xps> <46328204-e363-e517-f30c-c8c94ac1442c@zytor.com> From: Andy Lutomirski Date: Mon, 29 Jan 2018 08:37:14 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: selftests/x86/fsgsbase_64 test problem To: "H. Peter Anvin" Cc: Andy Lutomirski , Borislav Petkov , Dan Rue , Shuah Khan , Ingo Molnar , Dmitry Safonov , "open list:KERNEL SELFTEST FRAMEWORK" , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kselftest-owner@vger.kernel.org X-Mailing-List: linux-kselftest@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590669876861238825?= X-GMAIL-MSGID: =?utf-8?q?1590945494607767016?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Mon, Jan 29, 2018 at 1:13 AM, H. Peter Anvin wrote: > On 01/28/18 11:21, Andy Lutomirski wrote: >>> >>> I think the bug is here. I think that, when writing a NULL selector >>> to DS, ES, FS, or GS, Intel CPUs incorrectly set DPL == RPL, whereas >>> they should set DPL to 3. >> >> As an experiment, I did this: >> >> DEFINE_PER_CPU_PAGE_ALIGNED(struct gdt_page, gdt_page) = { .gdt = { >> + [0] = { .dpl = 3, }, >> + >> >> This had no apparent effect. I was hoping that maybe loading NULL >> into a selector would copy DPL from from gdt[0], but it seems like it >> doesn't. >> > > GDT[0] doesn't actually exist. That's what I thought, too, and the SDM does say that, but the SDM says all kinds of not-quite-correct things about segmentation. > It is pretty much scratch space (I have > suggested using it for the gsbase once all those issues get sorted out, > because it lets the paranoid code do something like: > > rdgsbase %rax > push %rax /* Save old gsbase */ > push %rax /* Reserve space on stack */ > sgdt -2(%rsp) /* We don't care about the limit */ > pop %rax /* %rax <- gdtbase */ > mov (%rax),%rax /* GDT[0] holds the gsbase for this cpu */ > wrgsbase %rax That will utterly suck on non-UMIP machines that have hypervisor-provided UMIP emulation.