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 070E3C433F5 for ; Thu, 10 Feb 2022 22:43:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6E7356B0074; Thu, 10 Feb 2022 17:43:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 697396B0075; Thu, 10 Feb 2022 17:43:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 53A416B0078; Thu, 10 Feb 2022 17:43:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0072.hostedemail.com [216.40.44.72]) by kanga.kvack.org (Postfix) with ESMTP id 47DBF6B0074 for ; Thu, 10 Feb 2022 17:43:46 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 086F092EA9 for ; Thu, 10 Feb 2022 22:43:46 +0000 (UTC) X-FDA: 79128348852.29.7AF8E8C Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf15.hostedemail.com (Postfix) with ESMTP id 0B0CAA0002 for ; Thu, 10 Feb 2022 22:43:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644533025; x=1676069025; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=3M8IIwvsuOqGIFi2k0uaq5Qj6oZtRqaS6GfOESfH9CM=; b=UviGI16QBhh5aRJ8oMzIWALjGyFRFrBhXQsNkxt5yJQpmvklnw8Oo+id wTGEVbMVyJU4L3VhHRFJwdMtlDzxMUDjWvB8w3MjskTI/eiE9VQztnGwl 2GJQxS74LACTRS+On5oa+O14Xh9viavN1ShrPerMhrcQ1Whai/tQ78jlI 2ePrEethdbZykdKBny8OrFS10QXCRp4l56v5aDkEVgejgdsuim+sgEXlC j8jBKa6cSDXhAHb+b2+lGNADMTQrc9smxcPErhskfJilmBozwWZlWLMVs gHiX31dUcp8JzNJZK8hDlydVtTYijFBnN/qqXzcdTZ+Wv47kFLvSPzO54 A==; X-IronPort-AV: E=McAfee;i="6200,9189,10254"; a="248442398" X-IronPort-AV: E=Sophos;i="5.88,359,1635231600"; d="scan'208";a="248442398" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.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 X-Rspam-User: Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=UviGI16Q; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf15.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.120) smtp.mailfrom=dave.hansen@intel.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 0B0CAA0002 X-Stat-Signature: woqcxfm8sqjwfhugbunqf57nzmb6o463 X-HE-Tag: 1644533024-705835 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 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?