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 65AE1C6FD1D for ; Mon, 6 Mar 2023 20:31:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B75816B0073; Mon, 6 Mar 2023 15:31:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AD6D2280001; Mon, 6 Mar 2023 15:31:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 929286B0075; Mon, 6 Mar 2023 15:31:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7D9ED6B0073 for ; Mon, 6 Mar 2023 15:31:23 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 5734DA0BB7 for ; Mon, 6 Mar 2023 20:31:23 +0000 (UTC) X-FDA: 80539618446.02.07DE00C Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf02.hostedemail.com (Postfix) with ESMTP id 1A77B80017 for ; Mon, 6 Mar 2023 20:31:19 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=eEuLpJMd; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf02.hostedemail.com: domain of kan.liang@linux.intel.com has no SPF policy when checking 134.134.136.100) smtp.mailfrom=kan.liang@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678134680; 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=usrzXxODimyPqu73pLjVZs+bVCwUrcN3IMuNIOo2XAQ=; b=ZrXvI3mo1323NrLPVqQ0NtzCD2vYMX49hvsJ707Olo9crch+2bGhThhnr3fXH7/Z3o4TNF qFwz8Xe42T3VyKjvMBNLRErbM72u5pOv2/+i7JL+Ws5zRJsL8zqkH24rvR3LGzWU335RRr jcKQ4hd4ALfSjJsnyHiC2isicfzvFq0= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=eEuLpJMd; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf02.hostedemail.com: domain of kan.liang@linux.intel.com has no SPF policy when checking 134.134.136.100) smtp.mailfrom=kan.liang@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678134680; a=rsa-sha256; cv=none; b=h5Jx5t4U1OuELWt0Nq8KYNaIX/AtDEKL4qIS8N9FI1K2sjJbiNKJoUX8WSClyWgWFcNfOc SV+jdN+meQnhPSwT9NLFpyUTkqP0tIvBvq01k2Wg2xblKnALRyVg2j23j5gmkBtauVSlGM ngTfgXJMDHNZT+2gzTDb1Z22suuOHzA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678134680; x=1709670680; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=MN+GxIeY2P/7LeJfofnw1WkCJjn6/4HPi9GyDps07Uw=; b=eEuLpJMdmRFR/PsZKkylJsFP4D/Xec4yAMBtRWZ7bEcIObsybBwtgcFV jUPFpsXHQRpwoQhvluzdC5Rzvz06YYK6XvjV2wk+4YFz2GQCWyFYu7x7U 5BITu+bRWuNGIr1zirFjQGh6WuJt3Jh7E3MNrPLXkDg3eAQMyGLP3AfuB TNny+DH+x1qwfj8knPUGThreZu8KAaeGVY6gKWjI3PsvFsXefwzvsMYcD HmgmPNfMMJ57g6AxoS2V8HyjEzRLQ9lY0FIwmBrg4s1wpk2UTcYNZxqdM SpTBxnLwlutXR/jw1u3UV8Uvw97p+KTpgqA36enBdFE6txqbj713GRq3h w==; X-IronPort-AV: E=McAfee;i="6500,9779,10641"; a="400491899" X-IronPort-AV: E=Sophos;i="5.98,238,1673942400"; d="scan'208";a="400491899" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Mar 2023 12:31:17 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10641"; a="626287541" X-IronPort-AV: E=Sophos;i="5.98,238,1673942400"; d="scan'208";a="626287541" Received: from linux.intel.com ([10.54.29.200]) by orsmga003.jf.intel.com with ESMTP; 06 Mar 2023 12:31:17 -0800 Received: from [10.251.28.138] (kliang2-mobl1.ccr.corp.intel.com [10.251.28.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by linux.intel.com (Postfix) with ESMTPS id 0EED558097C; Mon, 6 Mar 2023 12:31:11 -0800 (PST) Message-ID: Date: Mon, 6 Mar 2023 15:31:10 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v7 01/41] Documentation/x86: Add CET shadow stack description Content-Language: en-US To: "Edgecombe, Rick P" , "david@redhat.com" , "bsingharora@gmail.com" , "hpa@zytor.com" , "Syromiatnikov, Eugene" , "peterz@infradead.org" , "rdunlap@infradead.org" , "keescook@chromium.org" , "Eranian, Stephane" , "kirill.shutemov@linux.intel.com" , "szabolcs.nagy@arm.com" , "dave.hansen@linux.intel.com" , "linux-mm@kvack.org" , "fweimer@redhat.com" , "nadav.amit@gmail.com" , "jannh@google.com" , "dethoma@microsoft.com" , "broonie@kernel.org" , "kcc@google.com" , "linux-arch@vger.kernel.org" , "bp@alien8.de" , "oleg@redhat.com" , "hjl.tools@gmail.com" , "Yang, Weijiang" , "Lutomirski, Andy" , "pavel@ucw.cz" , "arnd@arndb.de" , "tglx@linutronix.de" , "Schimpe, Christina" , "mike.kravetz@oracle.com" , "x86@kernel.org" , "linux-doc@vger.kernel.org" , "debug@rivosinc.com" , "jamorris@linux.microsoft.com" , "john.allen@amd.com" , "rppt@kernel.org" , "andrew.cooper3@citrix.com" , "mingo@redhat.com" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" , "gorcunov@gmail.com" , "akpm@linux-foundation.org" Cc: "Liang, Kan" , "Yu, Yu-cheng" , "nd@arm.com" References: <636de4a28a42a082f182e940fbd8e63ea23895cc.camel@intel.com> <9714f724b53b04fdf69302c6850885f5dfbf3af5.camel@intel.com> <7b571c394839073cdc338b6718a363f44c9ba072.camel@intel.com> From: "Liang, Kan" In-Reply-To: <7b571c394839073cdc338b6718a363f44c9ba072.camel@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 1A77B80017 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: shhcdxkunkmriqyuaoutmxkcixyiwg4o X-HE-Tag: 1678134679-802939 X-HE-Meta: U2FsdGVkX1+HMPB9/qb0U1N9ZVX7q2ybT2MEMKz0DOyiLlwh3EkKqrE7zg30Ta1gt8gZ0Etwi7fc+nYM4L9gHYaYVg3q8/HvHwsh//GtGtgd5lXrt6b2NwruX/FPuznlrZqqpYqu0Hsyezz6Zd73o+vw/ONQfGKUDsD2Ejk7NOn+HGxbTsqzJQz65KA59a/80i7O8ULIwsAWiuKzA6xl+4yaSzfWBm0ksZLT0z0Xc/seaqhuJjRTcFQmqw1fBVuEW+dRDjTYbk7AmZ8hjnie0PdQkQmnOZhSHy6EaDbj4WisND7/L4mK275EpAG4eyX/cORpBi6Q9dFNuF4KbRlCEMnwG7BL9NaR6DQ9GLm/TxS6dgR0ZDuFxQBlUB+8ZhMPN5I9ax+MZGCzFQUg2+pV9mRTQMHLb6PPKMT+q3G7qk9CNS0BFaPwzaEm1CyBaUxy2LMXNOMz7WxFaHnfL3KfBRebq0Yr5coOl2eEHBDF694wX2RcIALrlGdwPi4bIa3VNyVu3GHYau44OLWWtMSbh5H8v8ylewDQXMFvCdiqOyWykIYHpyOLCVK5WlDSDyO+rJdz+QHw8DAvcc2SfdUgx6zuVNsz/1mkKWC2k2NGl3EqPPwR4xm1DR8hr59cV9985xDep/aEhOCSAIiIvRd+Xn2ySmQ2gDds+/kH6f4nIUlzuwuN0+oRgsKJji+Ae5DXbMqvkCgUKSxnMRQ49uo8ehvETeLY3iCwhB5wrZBYmbzy3mbJNVVChS+WXxzPArXR+ia/5xyXmPu28HAOZUFCdGEPP6/U9T1IuuLSl2MXgVEffGss9ZaVH3X6ugGjk92PkzkaH08d3SgZRohADJMi02QODQGE4I5Wh/RdG3pbxIAkmZ9XBtqr0NuhNlpfYZYpj5fQiLC3uiV0LnD7OIR+p/vo4CogVbnPKbwig261S8Bp4mYzMUp7JZAJdZmdBMc7tvqCIkf5M87X/64m+uN fUc5cOVs k/MB3vKO1rvMRVlxd97/dTYQ12epp2LYLcIsfY6r4o6qR0U6qm0Rt4MWSku6iueK1YE3Rg6XGBFqAKzCg/Xq8elWpEgAg+Ij7aY5E7UStKwAJ2RXa8l/+0W9PwKKUp9pb+Kkn2349SgMCM/zG8bSsAtnCmjJ8sFUjkZGHT83Fg0JvWtDfhcC1YhGwHXU8WqRVijwiQXVnFX/K7ZhPDCgzFpyNVJb2Sgh2Tj1jZ2vhzTKVU/RWp34YsXTcFW+X3aZ6+wkxAkhkT091taRq/65CMcgGH2x35TXSQIQw658kyXEih61wHZfPDLd5705IdJdIPcLs 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 2023-03-06 1:05 p.m., Edgecombe, Rick P wrote: > +Kan for shadow stack perf discussion. > > On Mon, 2023-03-06 at 16:20 +0000, szabolcs.nagy@arm.com wrote: >> The 03/03/2023 22:35, Edgecombe, Rick P wrote: >>> I think I slightly prefer the former arch_prctl() based solution >>> for a >>> few reasons: >>> - When you need to find the start or end of the shadow stack can >>> you >>> can just ask for it instead of searching. It can be faster and >>> simpler. >>> - It saves 8 bytes of memory per shadow stack. >>> >>> If this turns out to be wrong and we want to do the marker solution >>> much later at some point, the safest option would probably be to >>> create >>> new flags. >> >> i see two problems with a get bounds syscall: >> >> - syscall overhead. >> >> - discontinous shadow stack (e.g. alt shadow stack ends with a >> pointer to the interrupted thread shadow stack, so stack trace >> can continue there, except you don't know the bounds of that). >> >>> But just discussing this with HJ, can you share more on what the >>> usage >>> is? Like which backtracing operation specifically needs the marker? >>> How >>> much does it care about the ucontext case? >> >> it could be an option for perf or ptracers to sample the stack trace. >> >> in-process collection of stack trace for profiling or crash reporting >> (e.g. when stack is corrupted) or cross checking stack integrity may >> use it too. >> >> sometimes parsing /proc/self/smaps maybe enough, but the idea was to >> enable light-weight backtrace collection in an async-signal-safe way. >> >> syscall overhead in case of frequent stack trace collection can be >> avoided by caching (in tls) when ssp falls within the thread shadow >> stack bounds. otherwise caching does not work as the shadow stack may >> be reused (alt shadow stack or ucontext case). >> >> unfortunately i don't know if syscall overhead is actually a problem >> (probably not) or if backtrace across signal handlers need to work >> with alt shadow stack (i guess it should work for crash reporting). > > There was a POC done of perf integration. I'm not too knowledgeable on > perf, but the patch itself didn't need any new shadow stack bounds ABI. > Since it was implemented in the kernel, it could just refer to the > kernel's internal data for the thread's shadow stack bounds. > > I asked about ucontext (similar to alt shadow stacks in regards to lack > of bounds ABI), and apparently perf usually focuses on the thread > stacks. Hopefully Kan can lend some more confidence to that assertion. The POC perf patch I implemented tries to use the shadow stack to replace the frame pointer to construct a callchain of a user space thread. Yes, it's in the kernel, perf_callchain_user(). I don't think the current X86 perf implementation handle the alt stack either. So the kernel internal data for the thread's shadow stack bounds should be good enough for the perf case. Thanks, Kan