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 0BC4DEB64DA for ; Thu, 22 Jun 2023 03:24:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 579528D0002; Wed, 21 Jun 2023 23:24:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 529798D0001; Wed, 21 Jun 2023 23:24:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F1078D0002; Wed, 21 Jun 2023 23:24:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 2F6668D0001 for ; Wed, 21 Jun 2023 23:24:26 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E9C9A140842 for ; Thu, 22 Jun 2023 03:24:25 +0000 (UTC) X-FDA: 80928940890.29.5E009D1 Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) by imf21.hostedemail.com (Postfix) with ESMTP id EE0621C000E for ; Thu, 22 Jun 2023 03:24:23 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=NNzIU7JY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of hjl.tools@gmail.com designates 209.85.128.173 as permitted sender) smtp.mailfrom=hjl.tools@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687404264; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=l4O28N8FGaP9hA4+6ahHxAcfwQx7IU5FkHKln14GG3Y=; b=rVxYpyHJID/VuEHpr+wu1+utsNhFoSDxh8sp2WCcynYp/uGxJJcHorH8syDYkE5mWpLjN3 ukpiLseFv9YMvJs5SlmomwFje5wqo7pO22BwJrWSIK6RpyretqpIuZfaxcDLN0l8wSzRX0 s0TYlB6BBUT/ArS+oK5C5ep5FLfqrsg= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=NNzIU7JY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of hjl.tools@gmail.com designates 209.85.128.173 as permitted sender) smtp.mailfrom=hjl.tools@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687404264; a=rsa-sha256; cv=none; b=D6fS+iDhmdcvi6N4lBhe2jkwZxmy9cyeCxkn+y4aJlsMP+27EmNY1dAgZiDtAo6+zThxn5 FxUNrJ8peWvcBVKnTQ96B3hv8LPEMkmDXTea9V02Yc+IP1PDeVWUktfeSRtjQtITQayxaj AzeXha/B3LrItaKAzK2tLhymcfeqgmM= Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-57338656a8aso37639497b3.0 for ; Wed, 21 Jun 2023 20:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687404263; x=1689996263; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=l4O28N8FGaP9hA4+6ahHxAcfwQx7IU5FkHKln14GG3Y=; b=NNzIU7JYQjWLGByJ0BDfsfQXPqUrK8MTUXGyV2D7lW4Bm2q/Ik9xu4/R9FF6nlsBJ3 TIHN8+qx+P5YQSu3BRXBrADFh6Rqc82tvQV2NucSTLEHqjw2x5J/wx8T/UxoG6g+6W41 BXCJp8iHfs3Q5LrKoKhMijiFDtHv6grmRkjMveBM6SShEnRHOCRtOEygGCX27SS1yLxo yCwfd8Z1Em0R8BJNkMXT+T61pRnBAPPWzTnB/pCpF+guhA/9FHrDf0XOl3iXXx8dLsJY J/mabNfXG0tb1BXV8NzPSOyBFOSkyMDAhwf7P9X4WVIF7ZbCsrUu+YD4LVDl+9W/VRku WJlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687404263; x=1689996263; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=l4O28N8FGaP9hA4+6ahHxAcfwQx7IU5FkHKln14GG3Y=; b=TfTB1K+QlQXkfq6QtGhhMRWSP6i1sLKiaX9feBBkrAmQwuJH6kEWy8/KHcr3t5nKFe 3hhczfRdTSpfCSlyryRKKZATuzbWQDoW2b61MxXJ+4cR+jhWakyaGsIQmbc8lZzmYmYt 54E4QDPNUzN6MSbSQ/CB1I5p2Haj/1SJYIRA2Ladik5tnxFi+UOclN7tCZs5Zz7YLK9Y LjmT8YYFWVOfCD07Och0pbSPknbQa6TEDG1QTMYn98xU7PHm9CxHEn3T+DdO+d9d4737 h2ndiBGkWEqS0KBx+nbrHQcjIBiopHrzk1VdsiChYHJRdmYQpc8qRUjj3eRBN7HK14Jz M+pQ== X-Gm-Message-State: AC+VfDx8s4UVZCQus6KNtoTveVKd9OP67LcoyhZke4iw9mep+QO7Xg/l ygxHJVAsrW+vd7L4LJ6CoZ/D0NvxkxFe5zE2S/A= X-Google-Smtp-Source: ACHHUZ59kfPGrSfKxuh324V37hD7nPSrroGRA6spekBztu808vKYMl2ssvTY0BHJNvqM8Z1gQTVEnHiRioEMUW3M1y4= X-Received: by 2002:a81:48d0:0:b0:56d:1521:4f6c with SMTP id v199-20020a8148d0000000b0056d15214f6cmr16992828ywa.16.1687404263010; Wed, 21 Jun 2023 20:24:23 -0700 (PDT) MIME-Version: 1.0 References: <1f04fa59-6ca9-4f18-b138-6c33e164b6c2@sirena.org.uk> <49eabafa97032dec8ace7361bccae72c6ecf3860.camel@intel.com> <64837d2af3ae39bafd025b3141a04f04f4323205.camel@intel.com> <5794e4024a01e9c25f0951a7386cac69310dbd0f.camel@intel.com> <5ae619e03ab5bd3189e606e844648f66bfc03b8f.camel@intel.com> <66042cf07ed596d33f714ef152153361c77567d7.camel@intel.com> In-Reply-To: <66042cf07ed596d33f714ef152153361c77567d7.camel@intel.com> From: "H.J. Lu" Date: Wed, 21 Jun 2023 20:23:46 -0700 Message-ID: Subject: Re: [PATCH v9 23/42] Documentation/x86: Add CET shadow stack description To: "Edgecombe, Rick P" Cc: "Xu, Pengfei" , "tglx@linutronix.de" , "linux-arch@vger.kernel.org" , "kcc@google.com" , "Lutomirski, Andy" , "nadav.amit@gmail.com" , "szabolcs.nagy@arm.com" , "david@redhat.com" , "kirill.shutemov@linux.intel.com" , "Schimpe, Christina" , "Yang, Weijiang" , "peterz@infradead.org" , "corbet@lwn.net" , "nd@arm.com" , "broonie@kernel.org" , "jannh@google.com" , "linux-kernel@vger.kernel.org" , "debug@rivosinc.com" , "pavel@ucw.cz" , "bp@alien8.de" , "rdunlap@infradead.org" , "linux-api@vger.kernel.org" , "rppt@kernel.org" , "jamorris@linux.microsoft.com" , "arnd@arndb.de" , "john.allen@amd.com" , "bsingharora@gmail.com" , "mike.kravetz@oracle.com" , "dethoma@microsoft.com" , "andrew.cooper3@citrix.com" , "oleg@redhat.com" , "keescook@chromium.org" , "x86@kernel.org" , "gorcunov@gmail.com" , "Yu, Yu-cheng" , "fweimer@redhat.com" , "hpa@zytor.com" , "mingo@redhat.com" , "linux-mm@kvack.org" , "Syromiatnikov, Eugene" , "linux-doc@vger.kernel.org" , "Torvalds, Linus" , "dave.hansen@linux.intel.com" , "akpm@linux-foundation.org" , "Eranian, Stephane" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: EE0621C000E X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 8sb9js7c4zisqeg5i19nzs6wgmt3xyeg X-HE-Tag: 1687404263-789061 X-HE-Meta: U2FsdGVkX19LHRcVNiQiBGi3+VfL6QUqU2GISNVoIDyDaDwS82qbWptKLTmUBk9VVgoNHmCGSMyMg8/RH3pAIYSVoyHaqrea3XLMvLp4KZ9qadgCFbtgCYajqbZbi+3QQMlnUL8NOxDhjQqcm0rPvc7kfVWvhaoePEmos1CgOKhyidMS0mLxdjT0G8kJKzaT/xOvmfpsI2cywoBztuAaMoFRPr71tQQWzJ/hc3dE65y9AxdTrQd/blJWi68TQdR9S6hyM5LBTtv91jEaxkNjQJxzi/k+9CdFXgCVtmXlbSbxTbl5S/zXyDNrwdaJUi7vbudJZmUy+LKOXP6YIOpsnwxvr4DeF+BOxdEqo50AfrieVxkUtMT1JA+wqKveBRpWmtl+E1Eii9V60/KbFshVrWQftqbvyqR1Cp0eOmspM4csvkJfd+e2Ej4KSRnclA53lKdZihOPsctvTeDIRgI8E38k9H50qL1LbWo76Dl2t1l+eMI9GOX7o0I9LShhJ9Xn6XZBpd0tka1MWN9AzBOweK1q1NDuXpKtr0gBOv7iPMxmpB87xokHRsJpGCKN+Vg2mGMTHhujoVnJxvlj5e1Bt8cVPuRUKkmOsb2TgETLmVu0zDvWwYaPHaJShcyP0JI8zT5iPsNKn+snUQLtAvi6EHFSQSQ/oCgcf9NWCSZKC0GBnlqcaUR+N96ThiSDlgSH07++haCVt2VIpeIRSBDLPT1dlnRHw24CuFNh5Uipx0hsBBVQRUvjZ8H36RPGYX78N8YaRQjH4WTD/ZHBCVpF5PSkhS//blQLaHsmH/PDFjdPcnUbtBM1mIiVi4CKFJXPcUrGDABry8i1q14PuvE5tLLcmPOBEmAqNU/foKSZX/AwMz5fqKhQmjWWHqzzjJRelQ5mTg2trb3RZfKV+msuLJbuQVSW6viVuZRC5YvR4jJhu+sFu5LP9Xs/vkWAX2N9LA7qrna06Pk8gkeXPSo FPdwv1q6 nysnNR1+fTVwENcmFNhUt6D8JdNUuJb2aGtWmOGLFbg8SQ/ozacWwC3IOZ5lK8nCFuQG5WLce0bdbV28mTiP9CT+JaDmLK8YZ8uBWEBajQADA/euuWOxrQJISlYmu0n6rYoqAcSXrlVqBzhEI33wiQWX2S/3KZZ/OzQ4yvdGh4rsEuaXYTUXv1vf7Y+dX85vP2eByIhgw/26GDGD5sIE6z5vOOueDCmX3yZ5zi8jt2+B2XMoGl4hUO3OjPnAOIErig58jbxIONVDv1x+EmQYEBCVf5bEF4rNuzFWR0kzKp2UwgDBZMiSjnaPdA4zrjAzWN1DYq9MdTrQ7UZCfviUJbe5Dn3lRJXbWKINR93kAjcE7fNytEYi57AskHdOa00Np+M0MV2iFaeeZR8iWvBE5+mK+UKcFDtS4sV1T5CDtp0BO9hp1F3NgrvZm4hVj1Hyw6T+mC5EP9M9tqDRWeWLwlg8ieB/EuG1vqBTqhKpBDbHHELo0dDVKQorClzAp9jxSuTyaXI4jkcnzIpw= 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 Wed, Jun 21, 2023 at 6:07=E2=80=AFPM Edgecombe, Rick P wrote: > > On Wed, 2023-06-21 at 16:15 -0700, Rick Edgecombe wrote: > > On Wed, 2023-06-21 at 16:05 -0700, H.J. Lu wrote: > > > > Which makes me think if we did want to make a more compatible > > > > longjmp() > > > > a better the way to do it might be an arch_prctl that emits a > > > > token > > > > at > > > > the current SSP. This would be loosening up the security somewhat > > > > (have > > > > to be an opt-in), but less so then enabling WRSS. But it would > > > > also > > > > be > > > > way simpler, work for all cases (I think), and be faster (maybe?) > > > > than > > > > INCSSPing through a bunch of stacks. > > > > > > Since longjmp isn't required to be called after setjmp, leaving a > > > restore > > > token doesn't work when longjmp isn't called. > > > > Oh good point. Hmm. > > Just had a quick chat with HJ on this. It seems like it *might* be able > to made to work. How it would go is setjmp() could act as a wrapper by > calling it's own return address (the function that called setjmp()). > This would mean in the case of longjmp() not being called, control flow > would return through setjmp() before returning from the calling method. It may not work since we can't tell if RAX (return value) is set by longjmp or function return. > This would allow libc to do a RSTORSSP when returning though setjmp() > in the non-shadow stack case, and essentially skip over the kernel > placed restore token, and then return from setjmp() like normal. In the > case of longjmp() being called, it could RSTORSSP directly to the > token, and then return from setjmp(). > > Another option could be getting the compilers help to do the RSTORSSP > in the case of longjmp() not being called. Apparently compilers are > aware of setjmp() and already do special things around it (makes sense > I guess, but news to me). > > And also, this all would actually work with IBT, because the compiler > knows already to add an endbr at that point right after setjmp(). > > I think neither of us were ready to bet on it, but thought maybe it > could work. And even if it works it's much more complicated than I > first thought, so I don't like it as much. It's also unclear what a > change like that would mean for security. > > As for unwinding through the existing swapcontext() placed restore > tokens, the problem was as assumed - that it's difficult to find them. > Even considering brute force options like doing manual searches for a > nearby token to use turned up edge cases pretty quick. So I think that > kind of leaves us where we were originally, with no known solutions > that would require breaking kernel ABI changes. > > > Are you interested in helping get longjmp() from a ucontext stack > working for shadow stack? One other thing that came up in the > conversation was that while it is known that some apps are doing this, > there are no tests for mixing longjmp and ucontext in glibc. So we may > not know which combinations of mixing them together even work in the > non-shadow stack case. > > It could be useful to add some tests for this to glibc and we could get > some clarity on what behaviors shadow stack would actually need to > support. --=20 H.J.