From patchwork Fri Nov 30 09:44:37 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gavin Guo X-Patchwork-Id: 1005844 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 435qHb3bt9z9sB7; Fri, 30 Nov 2018 20:44:59 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1gSfLt-0002BO-MF; Fri, 30 Nov 2018 09:44:49 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.86_2) (envelope-from ) id 1gSfLr-0002BC-IP for kernel-team@lists.ubuntu.com; Fri, 30 Nov 2018 09:44:47 +0000 Received: from mail-pl1-f198.google.com ([209.85.214.198]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1gSfLr-0001sI-61 for kernel-team@lists.ubuntu.com; Fri, 30 Nov 2018 09:44:47 +0000 Received: by mail-pl1-f198.google.com with SMTP id v2so3763584plg.6 for ; Fri, 30 Nov 2018 01:44:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=qVK1xWtS0uQFZbfiWEFt3gJIph97sJWGlGUdI9Y+Pt0=; b=YNb7x00uM1XX6heJ/QUJjEgDAY0XCWTc8cN/Q7aFdQtPDLMUVHU4jwoDfXPDEYfGBj GtiLqwJ1bysYC8bRu56vRi/+MYevtioorryxSg/UfghQ2/K3E7b1YEKuZWywNSJoe5hd as4lql7wQpRQanknQT8Wm9kBJyJNg4MjYktdkwapU9StY07gMv/pHgxOP4B9PasawGPr d42xwWonW8ANjVXrnXrsHCrRNuXH1Ck34FmbFsbklgWEV45S16fq0D4wvZC9DsOi/Q5H bO0UEU3Po4VbV/nYcMWomxeqffJiYV9h6WTgj2fhHlluTGBGxLGbJ4pebeOzPMXtWplk BwCA== X-Gm-Message-State: AA+aEWYYnXqezQmx33OVdpjppZFGeJU0REze6JD6vgB1/DmfbPPa8D+8 gJafFhbT/jAt+tQ4SDBHkaa6WwLcgUA4pWaQJJ5giH32gEAvrS9t4xSZrW/0EhqQe2OGI/ZUIEK J6dwthy1oiYTzV0tddT0Kp37V8Ddztd7fFQ63OTONUA== X-Received: by 2002:a17:902:9887:: with SMTP id s7mr4885510plp.199.1543571085496; Fri, 30 Nov 2018 01:44:45 -0800 (PST) X-Google-Smtp-Source: AFSGD/WqLkhqXcHJgv0pvskPK55P5/3E2wzxfJ1TK1lLeN+//DObbNZigjWcLghh9kKx3A5c4kmK/Q== X-Received: by 2002:a17:902:9887:: with SMTP id s7mr4885496plp.199.1543571085229; Fri, 30 Nov 2018 01:44:45 -0800 (PST) Received: from gavin-P70.buildd (114-35-245-81.HINET-IP.hinet.net. [114.35.245.81]) by smtp.gmail.com with ESMTPSA id s37sm5392582pgm.19.2018.11.30.01.44.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 30 Nov 2018 01:44:44 -0800 (PST) From: Gavin Guo To: kernel-team@lists.ubuntu.com, juerg.haefliger@canonical.com Subject: [SRU][Trusty][Xenial][PATCH v2] UBUNTU: SAUCE: x86/speculation: Fix the IBRS synchronization Date: Fri, 30 Nov 2018 17:44:37 +0800 Message-Id: <1543571077-25165-1-git-send-email-gavin.guo@canonical.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: References: X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: gpiccoli@canonical.com MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" BugLink: https://launchpad.net/bugs/1764956 Ubuntu v4.4 kernel uses the in-house patches for IBRS. The backports still have some issues causing the IBRS status wrong when context-switching between the VM and host. For example, the IBRS would be mistakenly enabled in the host when the switching from an IBRS-enabled VM and that causes the performance overhead in the host. The other condition could also mistakenly disables the IBRS in VM when context-switching from the host. And this could be considered a CVE host. The detail different situations analysis: The reproducing environment: Guest kernel version: 4.4.0-138.164 Host kernel version: 4.4.0-140.166 (host IBRS, guest IBRS) - 1). (0, 1). The case can be reproduced by the following instructions: guest$ echo 1 | sudo tee /proc/sys/kernel/ibrs_enabled 1 host$ cat /proc/sys/kernel/ibrs_enabled 0 host$ for i in {0..55}; do sudo rdmsr 0x48 -p $i; done 11111111111111000000000000000000010010100000000000000000 Some of the IBRS bit inside the SPEC_CTRL MSR are mistakenly enabled. host$ taskset -c 5 stress-ng -c 1 --cpu-ops 2500 stress-ng: info: [11264] defaulting to a 86400 second run per stressor stress-ng: info: [11264] dispatching hogs: 1 cpu stress-ng: info: [11264] cache allocate: default cache size: 35840K stress-ng: info: [11264] successful run completed in 33.48s The host kernel didn't notice the IBRS bit is enabled. So, the situation is the same as "echo 2 > /proc/sys/kernel/ibrs_enabled" in the host. And running the stress-ng is a pure userspace CPU capability calculation. So, the performance downgrades to about 1/3. Without the IBRS enabled, it needs about 10s. - 2). (1, 1) disables IBRS in host -> (0, 1) actually it becomes (0, 0). The guest IBRS has been mistakenly disabled. guest$ echo 2 | sudo tee /proc/sys/kernel/ibrs_enabled guest$ for i in {0..55}; do sudo rdmsr 0x48 -p $i; done 11111111111111111111111111111111111111111111111111111111 host$ echo 2 | sudo tee /proc/sys/kernel/ibrs_enabled host$ for i in {0..55}; do sudo rdmsr 0x48 -p $i; done 11111111111111111111111111111111111111111111111111111111 host$ echo 0 | sudo tee /proc/sys/kernel/ibrs_enabled host$ for i in {0..55}; do sudo rdmsr 0x48 -p $i; done 00000000000000000000000000000000000000000000000000000000 guest$ for i in {0..55}; do sudo rdmsr 0x48 -p $i; done 00000000000000000000000000000000000000000000000000000000 Fixes: 4d8d3dbed275 ("UBUNTU: SAUCE: x86/bugs, KVM: Support the combination ...") Fixes: f676aa34b402 ("x86/kvm: add MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD ...") Signed-off-by: Gavin Guo --- arch/x86/kernel/cpu/bugs.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 60907abf12f5..e5f1ba148e3c 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -185,6 +185,13 @@ x86_virt_spec_ctrl(u64 guest_spec_ctrl, u64 guest_virt_spec_ctrl, bool setguest) guestval = hostval & ~x86_spec_ctrl_mask; guestval |= guest_spec_ctrl & x86_spec_ctrl_mask; + /* + * Check the host IBRS status to make IBRS regsiter update + * correctly. + */ + if (ibrs_enabled) + hostval |= SPEC_CTRL_IBRS; + /* SSBD controlled in MSR_SPEC_CTRL */ if (static_cpu_has(X86_FEATURE_SPEC_CTRL_SSBD)) hostval |= ssbd_tif_to_spec_ctrl(ti->flags);