Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1359153pxb; Wed, 4 Nov 2020 07:00:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJySBrw45TJHnwkYg7eqN8z7Du21x0ZAu1i/Q4EvbbjjYI0oYOrV8CHmw5BlN+oETWHlTqFq X-Received: by 2002:a17:906:36cd:: with SMTP id b13mr26434984ejc.235.1604502052001; Wed, 04 Nov 2020 07:00:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604502051; cv=none; d=google.com; s=arc-20160816; b=hz5ObcbR9zVtVrUBhhQylf2d5WsFjjfQxtNBgi6G5k1p5VL6FiCGEDWZo8IngE4OXX BUqVmITJMwoErYkUGTX3qIfGfIT1r+Fs258f6c2sO9hXjliNpEyExPeIkJ15Ji0DS55B lu7Tpe1WHDZjqQ1JBWJspIxzbdKaneGRfslkCgSSBK43buc1aE9T3EiL5jNCIm2J2xqS IKP0FL7ZU0g31hNmHYXvLzN8Y5aY+0atBu8KAF/TMvmAwiHH5mETwrE/Rxz9OgPF1xNt e/bYPhRWYbDZ3ehqpPP4Ot4gHLHocNzLqXuirzHiOy884LLqMMapRSyhDon3Jn46aJsg /dUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=OyZpLAEVIMVZ0aU5mpkg9hhpXcZl7OsCT0d36b/Hq10=; b=G2xeYAXucRB0PCJUjEOnVeNihVyzHOnQEFfI9ttqBGKP/CLDrNmsaaXzAegPzQj2EH vMxJDbkRFp7Pk+sL98gm7K148leSCpUt9rw2IU/HocHqzuIdipCRQgSj7NGGWT2p/T3N M09Q3yvVEz6Vks086oXwml0wLPKoKhny/eGSkRatYJy55XbMJi2JedBv4wuSdXlDLY1I sPVrxDYH1B9NAEgjpIxnpfZ28hc0cs4FVsfFTbkZQFhEacy22XPr6H6SQ2LQKeot2euh 5n8bGxHA73ogrfYvFLJGjNdeP9X3WNLdDHuoTudB4tN5TrVWvmvvbNlH2pG0kymaPFqW Dsqw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t13si1396421edv.198.2020.11.04.07.00.29; Wed, 04 Nov 2020 07:00:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730567AbgKDO4b (ORCPT + 99 others); Wed, 4 Nov 2020 09:56:31 -0500 Received: from mail.kernel.org ([198.145.29.99]:50372 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727651AbgKDO42 (ORCPT ); Wed, 4 Nov 2020 09:56:28 -0500 Received: from suppilovahvero.lan (83-245-197-237.elisa-laajakaista.fi [83.245.197.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8D15120729; Wed, 4 Nov 2020 14:56:21 +0000 (UTC) From: Jarkko Sakkinen To: x86@kernel.org, linux-sgx@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Sean Christopherson , Jethro Beekman , Jarkko Sakkinen , akpm@linux-foundation.org, andriy.shevchenko@linux.intel.com, asapek@google.com, bp@alien8.de, cedric.xing@intel.com, chenalexchen@google.com, conradparker@google.com, cyhanish@google.com, dave.hansen@intel.com, haitao.huang@intel.com, kai.huang@intel.com, kai.svahn@intel.com, kmoy@google.com, ludloff@google.com, luto@kernel.org, nhorman@redhat.com, npmccallum@redhat.com, puiterwijk@redhat.com, rientjes@google.com, tglx@linutronix.de, yaozhangx@google.com, mikko.ylinen@intel.com Subject: [PATCH v40 17/24] x86/fault: Add helper function to sanitize error code Date: Wed, 4 Nov 2020 16:54:23 +0200 Message-Id: <20201104145430.300542-18-jarkko.sakkinen@linux.intel.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20201104145430.300542-1-jarkko.sakkinen@linux.intel.com> References: <20201104145430.300542-1-jarkko.sakkinen@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sean Christopherson vDSO exception fixup is a replacement for signals in limited situations. Signals and vDSO exception fixup need to provide similar information to userspace, including the hardware error code. That hardware error code needs to be sanitized. For instance, if userspace accesses a kernel address, the error code could indicate to userspace whether the address had a Present=1 PTE. That can leak information about the kernel layout to userspace, which is bad. The existing signal code does this sanitization, but fairly late in the signal process. The vDSO exception code runs before the sanitization happens. Move error code sanitization out of the signal code and into a helper. Call the helper in the signal code. Acked-by: Jethro Beekman Signed-off-by: Sean Christopherson Signed-off-by: Jarkko Sakkinen --- Changes from v39: * Add the missing change to the set_signal_archinfo() that removes the snippet contained in sanitize_error_code(). arch/x86/mm/fault.c | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index 9339fee83784..0161d4acf3ad 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -602,11 +602,9 @@ pgtable_bad(struct pt_regs *regs, unsigned long error_code, oops_end(flags, regs, sig); } -static void set_signal_archinfo(unsigned long address, - unsigned long error_code) +static void sanitize_error_code(unsigned long address, + unsigned long *error_code) { - struct task_struct *tsk = current; - /* * To avoid leaking information about the kernel page * table layout, pretend that user-mode accesses to @@ -617,7 +615,13 @@ static void set_signal_archinfo(unsigned long address, * information and does not appear to cause any problems. */ if (address >= TASK_SIZE_MAX) - error_code |= X86_PF_PROT; + *error_code |= X86_PF_PROT; +} + +static void set_signal_archinfo(unsigned long address, + unsigned long error_code) +{ + struct task_struct *tsk = current; tsk->thread.trap_nr = X86_TRAP_PF; tsk->thread.error_code = error_code | X86_PF_USER; @@ -658,6 +662,8 @@ no_context(struct pt_regs *regs, unsigned long error_code, * faulting through the emulate_vsyscall() logic. */ if (current->thread.sig_on_uaccess_err && signal) { + sanitize_error_code(address, &error_code); + set_signal_archinfo(address, error_code); /* XXX: hwpoison faults will set the wrong code. */ @@ -806,13 +812,7 @@ __bad_area_nosemaphore(struct pt_regs *regs, unsigned long error_code, if (is_errata100(regs, address)) return; - /* - * To avoid leaking information about the kernel page table - * layout, pretend that user-mode accesses to kernel addresses - * are always protection faults. - */ - if (address >= TASK_SIZE_MAX) - error_code |= X86_PF_PROT; + sanitize_error_code(address, &error_code); if (likely(show_unhandled_signals)) show_signal_msg(regs, error_code, address, tsk); @@ -931,6 +931,8 @@ do_sigbus(struct pt_regs *regs, unsigned long error_code, unsigned long address, if (is_prefetch(regs, error_code, address)) return; + sanitize_error_code(address, &error_code); + set_signal_archinfo(address, error_code); #ifdef CONFIG_MEMORY_FAILURE -- 2.27.0