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 87C98C4332F for ; Thu, 10 Feb 2022 22:43:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345135AbiBJWnp (ORCPT ); Thu, 10 Feb 2022 17:43:45 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:60810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244866AbiBJWno (ORCPT ); Thu, 10 Feb 2022 17:43:44 -0500 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DD0F15F41; Thu, 10 Feb 2022 14:43:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644533023; x=1676069023; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=3M8IIwvsuOqGIFi2k0uaq5Qj6oZtRqaS6GfOESfH9CM=; b=X0hya5ADAOmuvFoDifDsSXV/gmlS/M0AxwFneZhASUfMAVt4+XklMNf3 dZbe088wA7w24OtTlxPrJc4t9QCFHsy+ajI5rWAlr0gSOvh1NwUXnqR1O fzL6GyaUfws6kOpWtv77YCn6DKBCvXN7IT3V4alvhExUhAJbYO043ArA/ wFW4FzidJMTvEJRHh9zCXBV7nI+5xhq1A8x9MLdMQcwW6dVXcm5FAC2xQ ODxgXRFBPexpEEHGNuEkCHpkBtW5udrg1EaRYUhgVlTpLNE1NkLJO8c3I sGxa43jwLYexxPn5Y16vIUscWi1X/FIxNeLTc+AD6s3luyGcnSEivqvL9 g==; X-IronPort-AV: E=McAfee;i="6200,9189,10254"; a="249819281" X-IronPort-AV: E=Sophos;i="5.88,359,1635231600"; d="scan'208";a="249819281" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Feb 2022 14:43:43 -0800 X-IronPort-AV: E=Sophos;i="5.88,359,1635231600"; d="scan'208";a="500561782" Received: from pengyusu-mobl.amr.corp.intel.com (HELO [10.212.149.216]) ([10.212.149.216]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Feb 2022 14:43:42 -0800 Message-ID: <4c216532-2b68-dd95-93f1-542df4786d7a@intel.com> Date: Thu, 10 Feb 2022 14:43:39 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH 18/35] mm: Add guard pages around a shadow stack. 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 , Andy Lutomirski , 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" , Dave Martin , Weijiang Yang , "Kirill A . Shutemov" , joao.moreira@intel.com, John Allen , kcc@google.com, eranian@google.com Cc: Yu-cheng Yu References: <20220130211838.8382-1-rick.p.edgecombe@intel.com> <20220130211838.8382-19-rick.p.edgecombe@intel.com> From: Dave Hansen In-Reply-To: <20220130211838.8382-19-rick.p.edgecombe@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On 1/30/22 13:18, Rick Edgecombe wrote: > INCSSP(Q/D) increments shadow stack pointer and 'pops and discards' the > first and the last elements in the range, effectively touches those memory > areas. > > The maximum moving distance by INCSSPQ is 255 * 8 = 2040 bytes and > 255 * 4 = 1020 bytes by INCSSPD. Both ranges are far from PAGE_SIZE. > Thus, putting a gap page on both ends of a shadow stack prevents INCSSP, > CALL, and RET from going beyond. What is the downside of not applying this patch? The shadow stack gap is 1MB instead of 4k? That, frankly, doesn't seem too bad. How badly do we *need* this patch?