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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5AED0EB64DD for ; Thu, 22 Jun 2023 03:24:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229602AbjFVDY0 (ORCPT ); Wed, 21 Jun 2023 23:24:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50254 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229437AbjFVDYY (ORCPT ); Wed, 21 Jun 2023 23:24:24 -0400 Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C59861A4; Wed, 21 Jun 2023 20:24:23 -0700 (PDT) Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-57015b368c3so59245677b3.3; 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=PNQ70k29dV02skC3Ig6Pc8rkGyuMquNPl2fr4QreWhDpeyKP3BdNJfOuztKvq+4KUl Yv97u465xqbqQMWh22IG7LfPkTqwbpbKKD/AkgunaDLYJrGh3qyppsX5zlBPbfD+Di1T 9Lta8aT584VUBaEOrakIn4nst6AI/Qe8XcPo0GEgt/xNMxnc/15eFeifeqObViMxeX1m j5PpPfhilkDZlP8xxyYrIhOpMRbtsBhujKI9NZ5ncYxHs+jZ5awYYcl+UZXnC/tQUJgt yz2PIbvnlAsjq7iJ+Ex+baIHLHSXp9VNWKasfRCMYDZRnDLWkpN9GnjIueobbU4fvkz5 Ed9g== X-Gm-Message-State: AC+VfDwcwA/4jT5WGocW+TJ+X3jdlalCNtTlOY4ZUSdunqIXWXdkanjz 4VfypchKJ10iT+egE4LPVqmdcYGCNz8y2nCz7eE= 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 Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org 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.