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 D198DC46467 for ; Wed, 4 Jan 2023 14:32:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 40BCB8E0002; Wed, 4 Jan 2023 09:32:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3BBE98E0001; Wed, 4 Jan 2023 09:32:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2AA7C8E0002; Wed, 4 Jan 2023 09:32:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 1A5E88E0001 for ; Wed, 4 Jan 2023 09:32:24 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A0CB31607F8 for ; Wed, 4 Jan 2023 14:32:23 +0000 (UTC) X-FDA: 80317356966.11.DD9E4C8 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf15.hostedemail.com (Postfix) with ESMTP id 3D6D5A000F for ; Wed, 4 Jan 2023 14:32:13 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=alien8.de header.s=dkim header.b=Xqn4rhA3; dmarc=temperror reason="query timed out" header.from=alien8.de (policy=temperror); spf=temperror (imf15.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de Received: from zn.tnic (p5de8e9fe.dip0.t-ipconnect.de [93.232.233.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 978331EC02FE; Wed, 4 Jan 2023 15:32:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1672842730; h=from:from: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=mGAc1hvVkdgwx67qTNes4TeLVQF5ZYZruSeDLPAGn0s=; b=Xqn4rhA3RQh8ReQBXtLkJ3CyiJPGmS7JH7ngZ6z4RhyyGaedtIU5vIfqqUqEt+qN4f+VeA twAtwhN7jpXEV0mQK0MXBLdAmOgBzoF1mCclxLj1W1dKo++TdeWBftWfJvVf3quvS4uX0e +c2sc3vVioheJW4dMkIh2G6zpdom/tE= Date: Wed, 4 Jan 2023 15:32:05 +0100 From: Borislav Petkov To: Rick Edgecombe Cc: x86@kernel.org, "H . Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H . J . Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , Weijiang Yang , "Kirill A . Shutemov" , John Allen , kcc@google.com, eranian@google.com, rppt@kernel.org, jamorris@linux.microsoft.com, dethoma@microsoft.com, akpm@linux-foundation.org, Andrew.Cooper3@citrix.com, christina.schimpe@intel.com, Yu-cheng Yu Subject: Re: [PATCH v4 16/39] x86/mm: Check Shadow Stack page fault errors Message-ID: References: <20221203003606.6838-1-rick.p.edgecombe@intel.com> <20221203003606.6838-17-rick.p.edgecombe@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20221203003606.6838-17-rick.p.edgecombe@intel.com> X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 3D6D5A000F X-Stat-Signature: 3d4o4moth69k9npmgrfaus5ahh4duja9 X-HE-Tag: 1672842733-107934 X-HE-Meta: U2FsdGVkX18yvOrAht8JtpAkLAHH3yLGklo20UCIpEAWDH1VherG6AlFqWH2u+0Uf+HdtdebueTcQtiu72BoSf2f/7dOQ5odb41HM9X5Lc8/hJ9UG0Foozj0itCIqbmBBe5fLkys0gYUeqf8IVYTdkDFkxdVGotnJJbtrGxz9cT2yYBUUzjN08lB02h48KNDUlFkJPU7UdeUnD6lhbzJCcNtqN1/mKRsJt03Lz2aZjhMrIWXuAj5Fqu7i26I4UPkxh4/DqI7BmGDu5p005JryVi6ALj8mMqgRKbUxcyTcBD7qtzrlyRkI5JaWRZNASdXr3/eFQeZduFjTeMpXbZDSYDaWvoMqFnssKuYwOfmgRM5aMWeRHud6y7GG9tkHinlgX3Pe8NNRdB5Pj2ZKGjzH6Z31MGHRvnhainIKHQExERU6oKrqiXtRT0d5SPLlHgGe7SIcDiCVv/Q/8r8cLNoPKpIGxKvqp6TcTZcwYUSyFi4wk3RJtLTnH7YQPEZGWk0iGN87AR5IwjbdEcLo8i6MOn09kAnavKP+zorEW53rfv13UGZ1yrlzLK/m9CWZcWpLYJAQuz0N69KUmjpbi2HdQ4cgVkQk6ixhsAIGTygEBddQ3wKgo24PnhTD4oShNW7kL4QrY0jMkNCF2YN1rJyMtSgHmyeU7Vk/rVD1oMH4LDe+CWXGDMiZih2BRZWaL9HLuUu8mvdp4HIREQ1ynCpC8CmCb+UsOA/vAeL5w5p/ULXnMx5warKQjmrJ/a7WJ2ZukepVo7bwGE4bJfvu7p/Ldq7LRp522Y9E0RHIZ/JlhzaD4+Re388UJmnMombwQ9xZJlLXKBgEBfuWeLWXwDFgfhgGevhDZCD+KD+LM2tMgEF+Q6o+eCyWHjeXLx59NNZ/IH7NLl7ovjxscWYgBzle+/sgqriXf6dO/sawDAfRHG2ML2v6AkIbPnSDgNsXHBTZzOmuy4mbW96jiUdCVT LAmwVrfh wVZ/3 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 Fri, Dec 02, 2022 at 04:35:43PM -0800, Rick Edgecombe wrote: > From: Yu-cheng Yu > > The CPU performs "shadow stack accesses" when it expects to encounter > shadow stack mappings. These accesses can be implicit (via CALL/RET > instructions) or explicit (instructions like WRSS). > > Shadow stacks accesses to shadow-stack mappings can see faults in normal, > valid operation just like regular accesses to regular mappings. Shadow > stacks need some of the same features like delayed allocation, swap and > copy-on-write. The kernel needs to use faults to implement those features. > > The architecture has concepts of both shadow stack reads and shadow stack > writes. Any shadow stack access to non-shadow stack memory will generate > a fault with the shadow stack error code bit set. You lost me here: by "shadow stack access to non-shadow stack memory" you mean the explicit one using WRU*SS? > This means that, unlike normal write protection, the fault handler needs > to create a type of memory that can be written to (with instructions that > generate shadow stack writes), even to fulfill a read access. So in the > case of COW memory, the COW needs to take place even with a shadow stack > read. I guess I'm missing an example here: are we talking here about a user process getting its shadow stack pages allocated and them being COW first and on the first shstk operation, it would generate that fault? > @@ -1331,6 +1345,30 @@ void do_user_addr_fault(struct pt_regs *regs, > > perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address); > > + /* > + * When a page becomes COW it changes from a shadow stack permissioned Unknown word [permissioned] in comment. > + * page (Write=0,Dirty=1) to (Write=0,Dirty=0,CoW=1), which is simply > + * read-only to the CPU. When shadow stack is enabled, a RET would > + * normally pop the shadow stack by reading it with a "shadow stack > + * read" access. However, in the COW case the shadow stack memory does > + * not have shadow stack permissions, it is read-only. So it will > + * generate a fault. > + * > + * For conventionally writable pages, a read can be serviced with a > + * read only PTE, and COW would not have to happen. But for shadow > + * stack, there isn't the concept of read-only shadow stack memory. > + * If it is shadow stack permissioned, it can be modified via CALL and Ditto. > + * RET instructions. So COW needs to happen before any memory can be > + * mapped with shadow stack permissions. > + * > + * Shadow stack accesses (read or write) need to be serviced with > + * shadow stack permissioned memory, so in the case of a shadow stack Is this some new formulation I haven't heard about yet? "Permissioned "? > + * read access, treat it as a WRITE fault so both COW will happen and > + * the write fault path will tickle maybe_mkwrite() and map the memory > + * shadow stack. > + */ > + if (error_code & X86_PF_SHSTK) > + flags |= FAULT_FLAG_WRITE; > if (error_code & X86_PF_WRITE) > flags |= FAULT_FLAG_WRITE; > if (error_code & X86_PF_INSTR) > -- > 2.17.1 > -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette