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 BF2A4EB64D8 for ; Thu, 22 Jun 2023 15:26:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5CA838D0008; Thu, 22 Jun 2023 11:26:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 57A128D0002; Thu, 22 Jun 2023 11:26:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 441D38D0008; Thu, 22 Jun 2023 11:26:57 -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 3599A8D0002 for ; Thu, 22 Jun 2023 11:26:57 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id EEC15B04EC for ; Thu, 22 Jun 2023 15:26:56 +0000 (UTC) X-FDA: 80930761632.23.407D1F3 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf03.hostedemail.com (Postfix) with ESMTP id CC03B2000B for ; Thu, 22 Jun 2023 15:26:53 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=A75mRcJP; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf03.hostedemail.com: domain of luto@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=luto@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687447613; 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=CI6Z0S8b5O2++ayz6nzbvLrYXmyQnU5ouR738Nc0SUU=; b=oVCxEjncLThNPH+2kUOIKHBtf5e1oD/Wagce2O9RkOLW5QwNe57l8664tkcixudo3XYZ36 7nNRR7qFD7fyVuNek85o1iLa+FBDhxOWgwzbiUpYq9izUnNXB+x98A6YQJ86VuxHlB69UG QDlxJTxyITO3AD263+RdVKcUuxprIsA= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=A75mRcJP; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf03.hostedemail.com: domain of luto@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=luto@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687447614; a=rsa-sha256; cv=none; b=TIvI9cqK0fF1N6SmTlwLVVwSDSu9K4NflpFmvUibO6F5GkIUoOUwuIJztpxMsb+p+vg9IA r9ToXNjph7FOhGsHxrlt1xQFBAwaiR8apvcEM6MY+hn7wL+l87kgBZXbzXIqBJR6AUkRV1 JhWDJON8GiINTGPzb2rxOEhblPMr66E= 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 97ACC6189F for ; Thu, 22 Jun 2023 15:26:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0781DC433C9 for ; Thu, 22 Jun 2023 15:26:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687447612; bh=B+Z7cw05eGhQpRQ1oXi2HuFt1eCXDFTqYg6Ryju6Ww0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=A75mRcJPaJcOLCZMR+y8RYr5Bz3pRcTotjQ/+DxrOOD7ab2FJok4HTPvw7Koq3WjC MYvUh2LIoiTaNecbhOnmVe0yJ/Ro2Tl9dTN4nN6+dPUQTWkpEQdc6IY+pYPGDnfFM/ LE9j8G1/poWVIdTAJc1gr3Hlc3hr5IYYCH5VngTXQ02KUxhxPlZWwUBikUPuxsp6dM u7wamoFyaMlOhktLvpIRqPnvQLEJiDyWyFVdnesZZzwRz+6gf7RNAAufO26L/7V6OH WfA7ffjpuNLYFWN2R/4q86lMmypiw62BImo8B1W+LhRsIOQ+qavVrRCZmpg3EThGH2 kNRy4/bP10PLw== Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-311275efaf8so5781719f8f.3 for ; Thu, 22 Jun 2023 08:26:51 -0700 (PDT) X-Gm-Message-State: AC+VfDwl2VHMb4S1AkXK1+Jt9b/6lsvqpWCFmQCRUVSLuS8jChxq7x+Q owd83LFRCNe8s7vaFnu2xA5EhaRpY19bGnoio0XdPA== X-Google-Smtp-Source: ACHHUZ7ewJB4p0OlgjL9jrGWucQ4lnAZcdwnRyYRE2RVvAZbSPiRVU6sOkh+C0Lymc07Bd7gWh87WrIEBULLZsT4gxA= X-Received: by 2002:aa7:c594:0:b0:51a:44b7:14c2 with SMTP id g20-20020aa7c594000000b0051a44b714c2mr9734462edq.40.1687447589330; Thu, 22 Jun 2023 08:26:29 -0700 (PDT) MIME-Version: 1.0 References: <64837d2af3ae39bafd025b3141a04f04f4323205.camel@intel.com> <5794e4024a01e9c25f0951a7386cac69310dbd0f.camel@intel.com> In-Reply-To: From: Andy Lutomirski Date: Thu, 22 Jun 2023 08:26:17 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v9 23/42] Documentation/x86: Add CET shadow stack description To: "szabolcs.nagy@arm.com" Cc: "Edgecombe, Rick P" , "broonie@kernel.org" , "Xu, Pengfei" , "tglx@linutronix.de" , "linux-arch@vger.kernel.org" , "kcc@google.com" , "Lutomirski, Andy" , "nadav.amit@gmail.com" , "kirill.shutemov@linux.intel.com" , "david@redhat.com" , "Schimpe, Christina" , "linux-doc@vger.kernel.org" , "peterz@infradead.org" , "corbet@lwn.net" , "nd@arm.com" , "dethoma@microsoft.com" , "jannh@google.com" , "linux-kernel@vger.kernel.org" , "debug@rivosinc.com" , "pavel@ucw.cz" , "bp@alien8.de" , "mike.kravetz@oracle.com" , "linux-api@vger.kernel.org" , "rppt@kernel.org" , "jamorris@linux.microsoft.com" , "arnd@arndb.de" , "john.allen@amd.com" , "rdunlap@infradead.org" , "bsingharora@gmail.com" , "oleg@redhat.com" , "andrew.cooper3@citrix.com" , "keescook@chromium.org" , "x86@kernel.org" , "gorcunov@gmail.com" , "Yu, Yu-cheng" , "fweimer@redhat.com" , "hpa@zytor.com" , "mingo@redhat.com" , "hjl.tools@gmail.com" , "linux-mm@kvack.org" , "Syromiatnikov, Eugene" , "Torvalds, Linus" , "akpm@linux-foundation.org" , "dave.hansen@linux.intel.com" , "Yang, Weijiang" , "Eranian, Stephane" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: CC03B2000B X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: zzz1x85gfubcsbhnr5czqk5pz31q7ifb X-HE-Tag: 1687447613-150804 X-HE-Meta: U2FsdGVkX1/c9UEMYhzrsNxVGFVNgP+pM0UoKWtZx37jkFY5ybkNoSi/RmtBe03yrvLsashFltlJnJaYhzD/ibyNZFhdzb4VB20m0CFRNHw1sV/Jj7nUPM6bJmz2gUjqVw4q1Y4MlP/3gvVKzRtFVEbvFJZolgruBfLytDSKh+gmv4WZoa9cXqPHG4tAgjFPa3dbHcd6HsHbNScfbFQpr/W4PA1V7vRLAgUbsgEx6yg3LeDPkDaOHK6KAAgcIJfm2iB+eeWmimPcNObF29Au7y6LW5aNfm2fqMxpSytEXNWEkPymFVGkgwlQFtIzowx3tW8KDCmvBwVNkW/4bK9AaN8sjkqdzqyE2G9Q+H+4bqQSK6UFNetwd4TxcQuQdsrF5lS+AP91pWl9gWolQo3QLuMk634SmoMtqNwx+OZnR6MNSjeRSS3uuCidZVTwobIKuTR8CEKGFKVrtnVLIt5sum6ic38vvH1h0bvQTGxNqZsvRn6Oc0zMWknZshofduGq7ZWJ8PO2Jm1WXT/BZbVG4tSlySNg4UHtXGCdjmvgSYZgNY8UzNlUjreIr32gNzciQVwq7gHk9lerJgzDT6/uPsiCwmTptzYpDjK7i1CV39IfAtZm9YyA05ZOASDmy2bsYuGNqWbobozoEYc6B9oF68I7XD+XT/KBMboFAnTUS75DnvHJA0ahwkZW6mIEpwLuVagmTIpnDXAQrojQ/oGvGmpkhPSQwQORjUqv9+OMqKtGlhhSqc8LFeoLs/sf9CvIeniMYDA/nnnifS2eSUq79MEd4o+inItjlcKLm+QB0cv3GPgwJkxW7UeHrAIR1w0xJh8TbNpFZNOtUphcUgaSX4OPNlT4C062i/hFepr6YF+DTr0WJMDczP/nxwu71fnmSyusdW/GTJZW3e4SMwSbjPn/IAWV2wTlJV0ED5dGY5f3E8kN8FrmikT7PDcRSOJgmQnlBKmwLjUSaaW5158 C2qssqqz aFK9PCFvFysh8TVoD/FEFaqP1FnL36XsddajTk7Mx9uvcYV6tSer2gxazKbx/mu8zgExOC1cnpY3kWuh8LOPTRzzFWOPm8jCb9Oo0OPHZB5bspCLqjQs3RrEYIRf0yLPNmQBBUp4omYm51DjfK8GI7hPcrh4AviioQiLEduWDLQjllTPqmf5Q2NFXbbByZpd2UC7zo2T/dZCRHJFEtPFygV4kwX6lP2Wgo53f4mzKiDlhAalGHbERTwQGb72n4mAkudvjRm1GMO+hKOXatsaToqFsFF2FtEIw+g5vf63K2EBCeX6x49Wr1j3PDj+yR7GEiGwzE3ZYpw+F2nsV4iqhshC65f/B2rtI0GAyvyaxCfa7NHHFyt9AfkdZ365iq0aHKfFfd26BR8ksp5VnLNyJLnrbYZf318WNdZNsU0f1cXl1SdBKrKbIFzMqI1RIVAshmjJZtg1tUOkwXSwNTR12EtYL0Tm/nfo6Y6WZHfufM3Q5BOI= 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 Thu, Jun 22, 2023 at 2:28=E2=80=AFAM szabolcs.nagy@arm.com wrote: > > The 06/21/2023 18:54, Edgecombe, Rick P wrote: > > On Wed, 2023-06-21 at 12:36 +0100, szabolcs.nagy@arm.com wrote: > > > > The 06/20/2023 19:34, Edgecombe, Rick P wrote: > > > > > > I actually did a POC for this, but rejected it. The problem is, > > > > > > if > > > > > > there is a shadow stack overflow at that point then the kernel > > > > > > > > can't > > > > > > push the shadow stack token to the old stack. And shadow stack > > > > > > > > overflow > > > > > > is exactly the alt shadow stack use case. So it doesn't really > > > > > > > > solve > > > > > > the problem. > > > > > > > > the restore token in the alt shstk case does not regress anything > > > > but > > > > makes some use-cases work. > > > > > > > > alt shadow stack is important if code tries to jump in and out of > > > > signal handlers (dosemu does this with swapcontext) and for that a > > > > restore token is needed. > > > > > > > > alt shadow stack is important if the original shstk did not > > > > overflow > > > > but the signal handler would overflow it (small thread stack, huge > > > > sigaltstack case). > > > > > > > > alt shadow stack is also important for crash reporting on shstk > > > > overflow even if longjmp does not work then. longjmp to a > > > > makecontext > > > > stack would still work and longjmp back to the original stack can > > > > be > > > > made to mostly work by an altshstk option to overwrite the top > > > > entry > > > > with a restore token on overflow (this can break unwinding though). > > > > > > > > There was previously a request to create an alt shadow stack for the > > purpose of handling shadow stack overflow. So you are now suggesting to > > to exclude that and instead target a different use case for alt shadow > > stack? > > that is not what i said. > > > But I'm not sure how much we should change the ABI at this point since > > we are constrained by existing userspace. If you read the history, we > > may end up needing to deprecate the whole elf bit for this and other > > reasons. > > i'm not against deprecating the elf bit, but i think binary > marking will be difficult for this kind of feature no matter what > (code may be incompatible for complex runtime dependent reasons). > > > So should we struggle to find a way to grow the existing ABI without > > disturbing the existing userspace? Or should we start with something, > > finally, and see where we need to grow and maybe get a chance at a > > fresh start to grow it? > > > > Like, maybe 3 people will show up saying "hey, I *really* need to use > > shadow stack and longjmp from a ucontext stack", and no one says > > anything about shadow stack overflow. Then we know what to do. And > > maybe dosemu decides it doesn't need to implement shadow stack (highly > > likely I would think). Now that I think about it, AFAIU SS_AUTODISARM > > was created for dosemu, and the alt shadow stack patch adopted this > > behavior. So it's speculation that there is even a problem in that > > scenario. > > > > Or maybe people just enable WRSS for longjmp() and directly jump back > > to the setjmp() point. Do most people want fast setjmp/longjmp() at the > > cost of a little security? > > > > Even if, with enough discussion, we could optimize for all > > hypotheticals without real user feedback, I don't see how it helps > > users to hold shadow stack. So I think we should move forward with the > > current ABI. > > you may not get a second chance to fix a security feature. > it will be just disabled if it causes problems. *I* would use altshadowstack. I run a production system (that cares about correctness *and* performance, but that's not really relevant here -- SHSTK ought to be fast). And, if it crashes, I want to know why. So I handle SIGSEGV, etc so I have good logs if it crashes. And I want those same logs if I overflow the stack. That being said, I have no need for longjmp or siglongjmp for this. I use exit(2) to escape. For what it's worth, setjmp/longjmp is a bad API. The actual pattern that ought to work well (and that could be supported well by fancy compilers and non-C languages, as I understand it) is more like a function call that has two ways out. Like this (pseudo-C): void function(struct better_jmp_buf &buf, args...) { ... if (condition) better_long_jump(buf); // long jumps out! // could also pass buf to another function ... // could also return normally } better_call_with_jmp_buf(function, args); *This* could support altshadowstack just fine. And many users might be okay with the understanding that, if altshadowstack is on, you have to use a better long jump to get out (or a normal sigreturn or _exit). No one is getting an altshadowstack signal handler without code changes. siglongjmp() could support altshadowstack with help from the kernel, but we probably don't want to go there. --Andy