From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4A6E7C41513 for ; Fri, 11 Aug 2023 15:09:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB85A6B0071; Fri, 11 Aug 2023 11:09:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A68066B0072; Fri, 11 Aug 2023 11:09:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 956876B0074; Fri, 11 Aug 2023 11:09:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 870096B0071 for ; Fri, 11 Aug 2023 11:09:45 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 520138115B for ; Fri, 11 Aug 2023 15:09:45 +0000 (UTC) X-FDA: 81112158330.26.520CAD2 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf03.hostedemail.com (Postfix) with ESMTP id EF39C20024 for ; Fri, 11 Aug 2023 15:09:41 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; spf=pass (imf03.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691766582; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Th1qeW1zhRwrLFBxbq8YfUG8Tmg98igOdRHZmT9DVAQ=; b=vky58JkX85dGAB0l2AOl6mICkESmqnOxtlIaHlcOmrp8gLbm/JNpfMyMKnguUkUX3tKRht oPZX0bZ48kuV93PsMTgh74HBj75p0McnxB/ap31hQd6wYH2hfPSpUnu4S8MuxI50VJTPTM wdqc5xJZCx6vvhO1f6Lf7IJlT2MF4/k= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691766582; a=rsa-sha256; cv=none; b=ld0IFxFlgEeBRWDDQNULufz7tlyCEcoJ57vYbzVgP7d1XX33I/foPwqQTXuJqG2v/6thxE qZNtt1wGirybX1S4/BL+ACOJKJwm2rjBB/ZNz52m9GuVrQcY3b818v9gxKd4qSQyzqkyOf P1QSQNVDTFd2kKF73pNK6Z+OxUoiViI= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; spf=pass (imf03.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0548F6741A; Fri, 11 Aug 2023 15:09:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91028C433C8; Fri, 11 Aug 2023 15:09:35 +0000 (UTC) Date: Fri, 11 Aug 2023 16:09:33 +0100 From: Catalin Marinas To: Mark Brown Cc: Will Deacon , Jonathan Corbet , Andrew Morton , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Eric Biederman , Kees Cook , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , Szabolcs Nagy , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH v4 17/36] arm64/mm: Handle GCS data aborts Message-ID: References: <20230807-arm64-gcs-v4-0-68cfa37f9069@kernel.org> <20230807-arm64-gcs-v4-17-68cfa37f9069@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230807-arm64-gcs-v4-17-68cfa37f9069@kernel.org> X-Rspamd-Queue-Id: EF39C20024 X-Rspam-User: X-Stat-Signature: m79qhaeyb17rm9wysi8xesktxuaizezs X-Rspamd-Server: rspam03 X-HE-Tag: 1691766581-699938 X-HE-Meta: U2FsdGVkX18+xHd1tn+RIH6sdMhzgiMdpnMgvyP4roWE+MK62s/zDUr8Vy/DbZGlX2m/ztRSOa++gYsnOO2flnuDoEeM6TMJff35aveO7GAM1dV+L83+7tkG7OpGIdi78rt6+uiDK+fA7aX3BBxVRjG+KPY5PeTAm8EWtyNFB2IqnItgjXvSh8iRsOKj6HQI5bAjEt97jHAbXmXoV3ffROuivrg1/IvekdyOPwUowSYGyiprJEN2SUxHq3GcucQ0NPZSeR0LMvOE5+Ypfo+oytHiX/Fbiv0tQvsJ4hkuXXaQnOIsE5+vGzpIpaexo2w2KoAvjuSknibNTthEyed8LgLb6Nhkkxz6bwP3VjIHdiByFIvjOf4KIrR1ZX/IpplaUeB3JNEWEahjNdwdWp46IiHze2SLkHN9o0ZKWErqrQ7v27xCl+x/zEIMmXqaQoLWU2zPDzsM3AC+n/NEBUHSzLIHfuQIViyHUXRbt3kWZV1AR86U8G5PzSXYgmRFlJQvXuc+gFVtOkUWm5GVeIcDuPG4J62gtMlYfYVNTHp72STmi841LwJBRlbLbm/jU0fEfj+ajUgrlz1/fMntr612O6VJbAp2eH6gQ9lQOuxMmcEk8UiVxkyS3UZO8+hV2GvgwBhzZ99iVWCm4SnYvED4lUmMG+SmnXZrUyHCgFWVo/FdaCzHLAczxwYzq056uLISLndbV6X/u7PxS9NE91GxdKMRPHQsaL9ZluWkgwr8QAXxRyiDyJ5J32LoILDyJjOeypcBRHwjMQ74IEbzZ2eStSV/mjTBw0xV+OTZEZi4vZx97UdBgDwTy9pvnjKxhKexwfZ9htaYDT7CF8jnr+ezDfBTXtKL3KZlnhVuc94ZY1J6uuRSg3Xe6tHqnEeZps9SQDoFa4ZyYYqr9ftliFPWV2r38IVQ7UJ9gZqNDGvACZilFPfCiuPxqfHzKlqDsC0tUgXu2PVPXWSLHYy7jWE y32l1feX 2rTs8hUJy8caZq6oLTjsCqe3ml0YuQ0oywCJ3T3lbT8buj6S604uaAhihyYKI08XS38xeXqr4t3mnzQo/yd0cpaVTf2PACQ5LfgAod5mogPPAef5sOWELnKrjG9g30i8d6bNJJJ7PfZqcDSjfjunuoUij5SkcSGUkQG87/vj+3r997RSqm4tqbUGZAoVdlimsLToycLXlyxuKqsKdZ3lMHvaVshApEqvUVl1xC+GWnZ/Al10EtD5fkrWAiNEUkLQmGnrvUmSmXS4MBFcs+avcJzG+DjwUIuwEhXYTR5FsurRRXklEvhqYslPvO2y4CvrXEzC7Lb1Zqj8hmXITX3F/i/nAXzmBdOKko/LP/AnAuMdMtU9ezHjSDokq8LSD6zwpDvu5ep5cLiPRqtdAjEGSh6uFauxYYJDEu5ao46P6ECaYgEsoZ/zrjX9G0I7WTbC7JXctVyHbeOiMlGudXBg3e0M5/V3UrQcm0HWcAAdTlYQ+DyE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Aug 07, 2023 at 11:00:22PM +0100, Mark Brown wrote: > @@ -510,6 +527,26 @@ static vm_fault_t __do_page_fault(struct mm_struct *mm, > */ > if (!(vma->vm_flags & vm_flags)) > return VM_FAULT_BADACCESS; > + > + if (vma->vm_flags & VM_SHADOW_STACK) { > + /* > + * Writes to a GCS must either be generated by a GCS > + * operation or be from EL1. > + */ > + if (is_write_abort(esr) && > + !(is_gcs_fault(esr) || is_el1_data_abort(esr))) > + return VM_FAULT_BADACCESS; Related to my PIE permissions comment: when do we have a valid EL1 data write abort that's not a GCS fault? Does a faulting GCSSTTR set the ESR_ELx_GCS bit? > + } else { > + /* > + * GCS faults should never happen for pages that are > + * not part of a GCS and the operation being attempted > + * can never succeed. > + */ > + if (is_gcs_fault(esr)) > + return VM_FAULT_BADACCESS; If one does a GCS push/store to a non-GCS page, do we get a GCS fault or something else? I couldn't figure out from the engineering spec. If the hardware doesn't generate such exceptions, we might as well remove this 'else' branch. But maybe it does generate a GCS-specific fault as you added a similar check in is_invalid_el0_gcs_access(). > @@ -595,6 +644,19 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr, > if (!vma) > goto lock_mmap; > > + /* > + * We get legitimate write faults for GCS pages from GCS > + * operations and from EL1 writes to EL0 pages but just plain What are the EL1 writes to the shadow stack? Would it not use copy_to_user_gcs()? -- Catalin