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 CF0C8EE8016 for ; Fri, 8 Sep 2023 15:14:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 266DB6B00D4; Fri, 8 Sep 2023 11:14:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 214C36B00D5; Fri, 8 Sep 2023 11:14:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B7A06B00D8; Fri, 8 Sep 2023 11:14:47 -0400 (EDT) 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 E2A9E6B00D4 for ; Fri, 8 Sep 2023 11:14:46 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B5E9712109D for ; Fri, 8 Sep 2023 15:14:46 +0000 (UTC) X-FDA: 81213777372.20.CD6E5F4 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.115]) by imf19.hostedemail.com (Postfix) with ESMTP id E1D471A0019 for ; Fri, 8 Sep 2023 15:14:43 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=gFv9dmtL; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf19.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694186084; 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=enqRUHqmBUy6EeHNiymUYagF2hGhNwAoDm1nB7t143g=; b=WQLSyvL9u27MBMR+MJBBwkqPJxAKoKb/fysroxaoT1xad/FIrsXQ4DPZXkfQHva5O8VQWx T0m1LCZ4aPPgGvg1nV8J3pKyGDbEvR8bT56RM0SZ0nVlEtSRc1BrOvYxcHnYikOVl20OXc VYQmbWa+yPJTSRP+4zwplBn76DMq2do= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=gFv9dmtL; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf19.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694186084; a=rsa-sha256; cv=none; b=mSqDGaNMRnKMmZ0ku/Rn8J3mnj5sK1Ph8nPtlbvu0UnD4rhb+XpLAnWm28T4LmvGSDGMZh 58MWtBpkukt52gaOVziLvEnMfsA7iUDLdUIF+AkzVWhT/zXGf6R8KOaUz9hhoHujgbFU2Z YsvSyfE9lfLMrpiA2FGDje3XwP3rCRM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694186084; x=1725722084; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=1DUKteFi87J/ZjtM43eEumr6T9NOL9on7XcA8r4tIK4=; b=gFv9dmtLDNugbv/b+WzrWwMDydNnNg9Ixmc7EVIPGImqUPcrtQHGECRx kmsTNj/VRsiohHaMqGD75cffrhLC8zW9vA7PkDsKvkMUObuTOhbPFNTuo vI5isy0Fl0tITKK4bamyKy/xa3afUtLyzyng7MNlSt1UfHMnWiqjd8U++ XVG3eeee/uMp8NK6s23xiKBIbxubM/MijYu78ZE+zOC96Lrjx5KrpDgxR AReQ/bLE0UhrxWqXm8mnft5ZIxpgEOMeyNY2+eIfOovL5Ons680rE9eVy CA758X5mLikPBXSptBaFUVOMctOBhJnQVM6toYXMhL/1UIIDxtRcRMNKj w==; X-IronPort-AV: E=McAfee;i="6600,9927,10827"; a="377578745" X-IronPort-AV: E=Sophos;i="6.02,237,1688454000"; d="scan'208";a="377578745" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Sep 2023 08:14:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10827"; a="832690991" X-IronPort-AV: E=Sophos;i="6.02,237,1688454000"; d="scan'208";a="832690991" Received: from fgilganx-mobl1.amr.corp.intel.com (HELO [10.209.17.195]) ([10.209.17.195]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Sep 2023 08:14:41 -0700 Message-ID: <4c49c85a-2b2e-e408-534d-586f06a8e485@intel.com> Date: Fri, 8 Sep 2023 08:14:41 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: Memory protection keys: Signal handlers crash if pkey0 is write-disabled Content-Language: en-US To: Robert Kueffner Cc: Kyle Huey , Dave Hansen , Thomas Gleixner , Borislav Petkov , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: E1D471A0019 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: e8c6ii3w5ecara5gu8rxhfrmiicm8uzh X-HE-Tag: 1694186083-183201 X-HE-Meta: U2FsdGVkX1+OhTPRlwTxojePSRF3pzq+WRWFtB1x+X32hIH9GJCW5Tqen0gkl1GxnIM3pCylRd6Pq7Eo8yjpU/kQca02N6/exnG8padsfYXutDF0vplVOMVoF3jjt5leW0PZxbTCV7WKwG+zrIt1MV6h8It+32sH8YtOvPE2cP8MVmyprJgSdceYFqisNg/fdPF+IRC3QhinOerwYNAKFAFbCKewgJErxlz8yXg8ukkRar0j7cw4tjIEJ8G/3t8qr7W4FTEsiM7o+8RssCPfK5HqhSjPfLGgIFAEOxpILbwNUiS/v5XTpV9BH6UOWgBURL/mpvYZl31aLN93zyzcQWsjX4Es+JLUJ+ufDxtvcxNUd/Rtz8qejheYJY66gqUEaSw3h+Tv07lKuELLdIwHm/N8njxoif8RjB8TdXcVKcUv+8mCtU3qCTdW7Tj7Fcr2aO3rcoBpsEIf9c5Sp79J9kzH/7jEosR7W6x0PpLgaEPbmEog+k9arHAuqv5+PtqA1/BXSb54Xw93kzKe70Ann3VvT4+2FC1MtepS5ZFIV17zKbIIng9Zx6u89T8dkRdm8n15NKLSTf6/NUCatZBusQRDSOXzJzDWyicLkqJMJuBK0p5fhUhCboXmsGHXhoLIjEhzst+tcBWjYY29d6E5TfPx0SWAEGBCZNec0b8Q1RGUaBQWqpq9w2o36bFg+62ej12BJ26sH8XOfRLJqHtXK08bNhLeHBYJbs83YtooTKT1fdQ+JPXz1fF61GHSKQo3stVi1NAR/Ww8K15TDnSZyNysbc4sInoyeuYE13Zc1Y9wZx8tnxt9zc4bEJ2Mc7HBj1Yi1HWn+WQ8PwBVxsOGuVn5T6fjXs33VsvfIzOhA3srM+O0x1RCqj0tg7L3p5t+6T4F9sbROVbiDW0R7n4Nl5tSu/6zoWlox9ZwZAZHwqvbEixo6rUKUuc3Sw4YYjsWE8PAnF6YWHqDD80i/uQ aGwTe3Qs WetjrV7XAj+Fxsf27Xi6sCi2RaI9DoD1BKLyhDfQVyhGSyMZ18ncr2obgPfAehSguIfdvY33bxMXNZFmBCpY9hUehfcaQZZRcbMhrN+R7eSqchbxhScQIRrnFQLi/asnJ3eWsA/oMhDV7qWf+tubjmxJbfhKjQE+7SXWiBuxElxebPMwgXB69cBKUi4eF/zysk4QAspm8B2kQx8yo4QuSKTeGyQ== 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 9/7/23 16:07, Robert Kueffner wrote: >> I assume that *something* is trying to access pkey-0-protected >> memory. Any idea what that is? Which entity is doing that access >> and what are they accessing? The page fault tracepoints might come >> in handy. > If I understand correctly, the kernel (a) pushes the processor state > onto the stack and (b) resets PKRU=0x55555554 some time before > switching to the signal handler. And may try between (a) and (b) to > write pkey-0-protected memory. Well, the "pushes the processor state onto the stack" part is probably the problem. That processor state _includes_ PKRU and it's also eventually the only place that processor state exists. That means that there's no simple solution. You can't just move up where PKRU gets reset because that will blow away the PKRU that you need to save on the stack. There are tons of complicated ways to fix this. But the easiest way is just to say that you need to keep PKRU set so that the signal frame can be written at any time.