Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp3520308rwb; Mon, 3 Oct 2022 16:48:54 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4Z/06erUiSLf8ekKRE0OIckoDyitiuH2v5Ydlg9IF46PDxit1ZJqICe/zUZfPcHFP5sDUA X-Received: by 2002:a05:6402:510f:b0:451:624f:2f02 with SMTP id m15-20020a056402510f00b00451624f2f02mr20769760edd.40.1664840934230; Mon, 03 Oct 2022 16:48:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664840934; cv=none; d=google.com; s=arc-20160816; b=Fr1b4ShMvsNgV8Q962Yw9VxhTMOexT7cO6wa2r1HOGLU0e9hsU3KE7P+6aK9U+lPyD KIwgE5A7zl7vw+fVvK+duk5U3DvEwTiSVAQe2YQ1b5LTc+ibyYHr28RHFad/Kk8u0x69 rto1UXtrImxA18C7H7yYT3YZjoTMU5kD3CJlU57eXiGmnFpPevpU/Ak77y0PQEgCwPgY qrHWrO71ntilh/M8m5bYqv/9lgvq2J27YgbfBLUzAlO+H2Rj1Rajw5EE4uxGYs69tBVa nfY+2gp4h4mfaqYCcUVZZz/+XbaFxmHDrWMmY4ONT9AvCNggEI7AZRTonP+ApZrlkCP/ Youw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:to:content-language:subject:user-agent:mime-version:date :message-id:dkim-signature; bh=BQPbLOsQeBFfMfr8IIX4pzlXRVl4e3zexfuVERQsI/s=; b=xdrHyByc1xtUAPAXyawBgHa1I5TIDrCrv+mqdTW5LANpBBpogrpXvLfQnZQ/M8vhtr R5KciFO1NIax5PE3po5eXuOMUCOoiusprMIUIje03QAIPzqLMj4Furp4/p5UtzOWgkSO KWeknyfwA36WiQyYJQRzyc/ViVPuWX4JYuwapbffusXHBMvBoS28u1KbP32pWM5Hchol vUmJzXHJnLH6W0hMTrjnpoNeaGyvFpNHfAN7+IwhzR/0lwnV+gu/rewc5PDs6OFFOQM5 2Cmkfgh++C5fhlZx56+MCFq4bLp1Am+UH198GIx5IkN1MGkyGmETETJFMNlZcP2t8uFM dThA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="XVgO/DyU"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h2-20020a056402280200b0045938ab7129si2035218ede.330.2022.10.03.16.48.13; Mon, 03 Oct 2022 16:48:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="XVgO/DyU"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229775AbiJCXWD (ORCPT + 99 others); Mon, 3 Oct 2022 19:22:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229997AbiJCXVm (ORCPT ); Mon, 3 Oct 2022 19:21:42 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 29BD12AE2F; Mon, 3 Oct 2022 16:21:31 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 89363B8167C; Mon, 3 Oct 2022 23:21:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6E7FC433D6; Mon, 3 Oct 2022 23:21:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1664839288; bh=yamzuIFFkRskLclSUhT79/xfr8FDVLCU37aEmswN37Y=; h=Date:Subject:To:References:From:In-Reply-To:From; b=XVgO/DyUkp+jUFZzaWodSpcYO30efmUyxWXqEfnBsgqWN6brv8pRGUZn6JxSO//TS rB+zrBuc7mbAJ5O9vl49m51WMIvxHPnKgwc+qvmyddipHTn1d3EJI9TCQ/TNegKh4O BEu8x1CK5szkrXo6GQXkpLZZTp9iI5b2V/MAplaeSmlhlc13Sj4DcZUyxQadlstEl+ dGCSuIlxRVhuxm2LOgNilLzmrOranFb/RSTMrWJ5/wSial2F5GDp7iQz2yIVAOpdiJ v8eVK+Ic+Pc0vPaRtZmrA64t42M0M5DevU3YbNWzEPNi5WGfqe2t975WruwfOU5PLi X8Y9j91CYOeIg== Message-ID: Date: Mon, 3 Oct 2022 16:21:25 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [OPTIONAL/RFC v2 39/39] x86: Add alt shadow stack support Content-Language: en-US To: Rick Edgecombe , 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 , Balbir Singh , Borislav Petkov , 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 , "Ravi V . Shankar" , Weijiang Yang , "Kirill A . Shutemov" , joao.moreira@intel.com, John Allen , kcc@google.com, eranian@google.com, rppt@kernel.org, jamorris@linux.microsoft.com, dethoma@microsoft.com References: <20220929222936.14584-1-rick.p.edgecombe@intel.com> <20220929222936.14584-40-rick.p.edgecombe@intel.com> From: Andy Lutomirski In-Reply-To: <20220929222936.14584-40-rick.p.edgecombe@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/29/22 15:29, Rick Edgecombe wrote: > To handle stack overflows, applications can register a separate signal alt > stack to use for the stack to handle signals. To handle shadow stack > overflows the kernel can similarly provide the ability to have an alt > shadow stack. The overall SHSTK mechanism has a concept of a shadow stack that is valid and not in use and a shadow stack that is in use. This is used, for example, by RSTORSSP. I would like to imagine that this serves a real purpose (presumably preventing two different threads from using the same shadow stack and thus corrupting each others' state). So maybe altshstk should use exactly the same mechanism. Either signal delivery should do the atomic very-and-mark-busy routine or registering the stack as an altstack should do it. I think your patch has this maybe 1/3 implemented, but I don't see any atomics, and you seem to have removed (?) the code that actually modifies the token on the stack. > > +static bool on_alt_shstk(unsigned long ssp) > +{ > + unsigned long alt_ss_start = current->thread.sas_shstk_sp; > + unsigned long alt_ss_end = alt_ss_start + current->thread.sas_shstk_size; > + > + return ssp >= alt_ss_start && ssp < alt_ss_end; > +} We're forcing AUTODISARM behavior (right?), so I don't think this is needed at all. User code is never "on the alt stack". It's either "on the alt stack but the alt stack is disarmed, so it's not on the alt stack" or it's just straight up not on the alt stack.