Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp625119rdd; Tue, 9 Jan 2024 14:46:38 -0800 (PST) X-Google-Smtp-Source: AGHT+IF5w0fU1+kjERfsPoZU4G/gF5jOfRVfygh14pm8XIDv4Hmbfrkws0ATN7HKlmiRxsrREbjo X-Received: by 2002:a05:6214:d62:b0:680:ce51:cf3c with SMTP id 2-20020a0562140d6200b00680ce51cf3cmr2088811qvs.59.1704840398681; Tue, 09 Jan 2024 14:46:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704840398; cv=none; d=google.com; s=arc-20160816; b=jU1E9sG9AEZnoWKsfjVWcTnaqq+Af5panEFnm4djwc91mZDOaRTu12PdlR3mPaUmks 55Am6YoQ2OIE9Omx6KDYjDmlfy1SG9K0isA2v6LYcE2rzPzmx9bBeEFZfJmVJAHWNI5F ZXhpeJOCQFrKJu7QCk1BcRVcI431eFuZNeFsrudaw6gR/PXS2lauZL/xYmaemNADKOan 6DfJSA5G8IKlV+hGV0+alPvUvrGe9qP9ZpWPEg47TrDybh95ZWnrx+ih9cx8yhM3mBCX 3rHR5qV/MboItym76NH8aZkDNBO+9rhukcQr0M/NhRavHWAW6fcxxWmnzcJSJZAQ3bpX xw4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=sSsAE8gp4KHhvoV1jPcfpB4+x7t7sVhh94EPI4B95tg=; fh=WMSq+jmIuTZHu2mcPpEXvmywG9O4OTD3fT0FpOtG3Uc=; b=hAvw7nyZIZClMb4zSsdjkxE5OplGhuPbYe63Vm2+iNffAWrdT93fwbc/klUw/1YgXz 1AEHXR1OgWccwi2lda47y1mvvTaaieDSviEZcK8J43xheMEn0nMaE1Y7GFWWtRrTPOiD Eju10j9QcUhfTMcVdJKJVWNHaQZHZsuO9ngJ9T8C4tgc4BFjkQ4UeykEdqdcn4ZaMeE6 RGD2mOf5RAg+MwldEVNN/wt3UZdWeJ3km3IP4N7e7JgId5MVJO6DRM5wQ0Q+WltQho3F XsOj7uTRchY9X3kcA8qFUjcTwSsLXhWWuFz2aPqht6nJd25CC67KoIARR4t+uL25AEW4 kf2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="ANXWA5Y/"; spf=pass (google.com: domain of linux-kernel+bounces-21485-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-21485-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id x20-20020a0ce0d4000000b00680c85d6553si3299228qvk.361.2024.01.09.14.46.38 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jan 2024 14:46:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-21485-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="ANXWA5Y/"; spf=pass (google.com: domain of linux-kernel+bounces-21485-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-21485-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 6F6B11C248E5 for ; Tue, 9 Jan 2024 22:46:38 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 408D63E470; Tue, 9 Jan 2024 22:46:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ANXWA5Y/" Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 936DD3E462 for ; Tue, 9 Jan 2024 22:46:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1704840390; x=1736376390; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=w6kupFrzbFpocVDLGUNde4MWMYhkpk7yL5N6258QRUQ=; b=ANXWA5Y/Wr3ZZeLXS1LV78YqUw++hAphWjKN/DwZDgDNsAB3LH5SF3dd cuiYaPYzNp5aCgNceyBa7G1ADz789l+24G9se4+0X0IUCS+2spaXObnjI Xyg5pvRGz9cn1B7DamKB2WLQxcPuUjCscTzSNxXRG6awu3kc6QysKGqO5 ue9GRIov855/GoNrdko2CToHn7dnYHE032VYJxgVvXl9eGmUP0E7g9Ncq SaIUHmuczwjdOGkcFRzsQCObXY4tVq1cgt8JF6KiS9i0xKHkjpv3OptIk OO/3706EsceWB+i7kiePToOlhgsx3as6KKmkmHrLRO6XXgpZNu4FMh2bB Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10947"; a="5116937" X-IronPort-AV: E=Sophos;i="6.04,184,1695711600"; d="scan'208";a="5116937" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jan 2024 14:46:29 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10947"; a="872397599" X-IronPort-AV: E=Sophos;i="6.04,184,1695711600"; d="scan'208";a="872397599" Received: from rflores-mobl.amr.corp.intel.com (HELO rpedgeco-desk4.intel.com) ([10.255.229.33]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jan 2024 14:46:29 -0800 From: Rick Edgecombe To: lkp@intel.com, x86@kernel.org Cc: bp@alien8.de, dave.hansen@linux.intel.com, keescook@chromium.org, linux-kernel@vger.kernel.org, oe-kbuild-all@lists.linux.dev, rick.p.edgecombe@intel.com, yu-cheng.yu@intel.com Subject: [PATCH] x86/shstk: Use __force when casting away __user Date: Tue, 9 Jan 2024 14:46:19 -0800 Message-Id: <20240109224619.1013899-1-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <202401080003.duO4RmjK-lkp@intel.com> References: <202401080003.duO4RmjK-lkp@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In setup_signal_shadow_stack() the kernel needs to push the restorer address to the shadow stack. This involves writing the value of the restorer pointer to the shadow stack. Since the restorer is defined as a __user in struct k_sigaction, the __user needs to be casted away to read the value. It is safe to do, because nothing is being dereferenced, and the de-__user-ed value is not stashed in an accessible local variable where it might accidentally be used for another purpose. However, sparse warns about casting away __user. So use __force to silence sparse and add a comment to explain why it is ok. Fixes: 05e36022c054 ("x86/shstk: Handle signals for shadow stack") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202401080003.duO4RmjK-lkp@intel.com/ Signed-off-by: Rick Edgecombe --- arch/x86/kernel/shstk.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c index 59e15dd8d0f8..7cc294482011 100644 --- a/arch/x86/kernel/shstk.c +++ b/arch/x86/kernel/shstk.c @@ -367,7 +367,11 @@ int setup_signal_shadow_stack(struct ksignal *ksig) /* Push restorer address */ ssp -= SS_FRAME_SIZE; - err = write_user_shstk_64((u64 __user *)ssp, (u64)restorer); + /* + * Use __force because this is just writing the address of the pointer + * to the shadow stack, not dereferencing it. + */ + err = write_user_shstk_64((u64 __user *)ssp, (u64 __force)restorer); if (unlikely(err)) return -EFAULT; -- 2.34.1