Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1333717imm; Thu, 23 Aug 2018 01:00:30 -0700 (PDT) X-Google-Smtp-Source: AA+uWPwq7Mk48BLw2UgNc3K5bU2jRdiCrkDfzU8mXPf+W2akdBWlHpmJXZvNdJrN8IS6PCc6d7OZ X-Received: by 2002:a17:902:5481:: with SMTP id e1-v6mr57775452pli.309.1535011230274; Thu, 23 Aug 2018 01:00:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535011230; cv=none; d=google.com; s=arc-20160816; b=cz5Z97pgDYrA7qKvgFMIllj6yOUjWnlBBmuFsVSkYKqbBoVR6NtO2kL4FpBrNEHu7l TLCG6NKhAR2SnZrZ2YfJ05S9gdTD7NoxyQEIpD6cVXuhLzKRC9q7Vd/qs+Ot+Jl24AsG vKKmvSsaqSo7LCSOxzXdqc5W7beZV98nnmMKMAR5fGrHx5e6gszruyFnM2d1P1YF3E7Z FiR/t5JRAna6aaKTWHEozIYbIpvySus1EGpqkv3DZu4AAUIBncD1VXk2N3rk2MHUYk5n 5uLcFHLrXAXTHRCBd1jwN//JGnqKDhS/FKzHbIfvsjRbnX5UrfJPgwxvr4KqV3/MERCX 9KXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=uJI9OkV4VIfFOVP/TGYtKZM8CKnzrS1d0HvfSyIY61Q=; b=MY+IIu0xqId1q1q58WS7HWfdjHzdkVL1IN2JjQqz4zbugRlZrp2BPAxqbOExVToCwU 1KICEhY7TtPZ3dOZ9tnHBdftzqGrmBr+HPim25VKxQl+lk0mGHyxr14hGnMj8rrJDqVk lg4SSzKfzZlINW/SDCUl9dQDwsxhhNsqw8BhHf56iL5GreNWtKnLcwLAd7vHhtAz57NQ Xwgoud0GlopWMUu3n9Zgze/8C7bzrBBX8uOWs3DLdpkUOVTPNt9cev/bzGHPdBLgFN6Q eHOARm44aA7BXTYU49QIF3x5W2mPwR8QPG3mPiP02DQOAgChJONmh+DwJMyoP03ZILwk FzqQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n14-v6si3769747pgg.216.2018.08.23.01.00.15; Thu, 23 Aug 2018 01:00:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727955AbeHWL0g (ORCPT + 99 others); Thu, 23 Aug 2018 07:26:36 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:41760 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726995AbeHWL0f (ORCPT ); Thu, 23 Aug 2018 07:26:35 -0400 Received: from localhost (5355525A.cm-6-6b.dynamic.ziggo.nl [83.85.82.90]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 6AF0BACC; Thu, 23 Aug 2018 07:58:12 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andy Lutomirski , Borislav Petkov , Linus Torvalds , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Sasha Levin Subject: [PATCH 4.4 30/79] selftests/x86/sigreturn/64: Fix spurious failures on AMD CPUs Date: Thu, 23 Aug 2018 09:53:06 +0200 Message-Id: <20180823074920.685984965@linuxfoundation.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180823074918.641878835@linuxfoundation.org> References: <20180823074918.641878835@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Andy Lutomirski [ Upstream commit ec348020566009d3da9b99f07c05814d13969c78 ] When I wrote the sigreturn test, I didn't realize that AMD's busted IRET behavior was different from Intel's busted IRET behavior: On AMD CPUs, the CPU leaks the high 32 bits of the kernel stack pointer to certain userspace contexts. Gee, thanks. There's very little the kernel can do about it. Modify the test so it passes. Signed-off-by: Andy Lutomirski Cc: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/86e7fd3564497f657de30a36da4505799eebef01.1530076529.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- tools/testing/selftests/x86/sigreturn.c | 46 ++++++++++++++++++++------------ 1 file changed, 29 insertions(+), 17 deletions(-) --- a/tools/testing/selftests/x86/sigreturn.c +++ b/tools/testing/selftests/x86/sigreturn.c @@ -456,19 +456,38 @@ static int test_valid_sigreturn(int cs_b greg_t req = requested_regs[i], res = resulting_regs[i]; if (i == REG_TRAPNO || i == REG_IP) continue; /* don't care */ - if (i == REG_SP) { - printf("\tSP: %llx -> %llx\n", (unsigned long long)req, - (unsigned long long)res); + if (i == REG_SP) { /* - * In many circumstances, the high 32 bits of rsp - * are zeroed. For example, we could be a real - * 32-bit program, or we could hit any of a number - * of poorly-documented IRET or segmented ESP - * oddities. If this happens, it's okay. + * If we were using a 16-bit stack segment, then + * the kernel is a bit stuck: IRET only restores + * the low 16 bits of ESP/RSP if SS is 16-bit. + * The kernel uses a hack to restore bits 31:16, + * but that hack doesn't help with bits 63:32. + * On Intel CPUs, bits 63:32 end up zeroed, and, on + * AMD CPUs, they leak the high bits of the kernel + * espfix64 stack pointer. There's very little that + * the kernel can do about it. + * + * Similarly, if we are returning to a 32-bit context, + * the CPU will often lose the high 32 bits of RSP. */ - if (res == (req & 0xFFFFFFFF)) - continue; /* OK; not expected to work */ + + if (res == req) + continue; + + if (cs_bits != 64 && ((res ^ req) & 0xFFFFFFFF) == 0) { + printf("[NOTE]\tSP: %llx -> %llx\n", + (unsigned long long)req, + (unsigned long long)res); + continue; + } + + printf("[FAIL]\tSP mismatch: requested 0x%llx; got 0x%llx\n", + (unsigned long long)requested_regs[i], + (unsigned long long)resulting_regs[i]); + nerrs++; + continue; } bool ignore_reg = false; @@ -507,13 +526,6 @@ static int test_valid_sigreturn(int cs_b } if (requested_regs[i] != resulting_regs[i] && !ignore_reg) { - /* - * SP is particularly interesting here. The - * usual cause of failures is that we hit the - * nasty IRET case of returning to a 16-bit SS, - * in which case bits 16:31 of the *kernel* - * stack pointer persist in ESP. - */ printf("[FAIL]\tReg %d mismatch: requested 0x%llx; got 0x%llx\n", i, (unsigned long long)requested_regs[i], (unsigned long long)resulting_regs[i]);