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 134FBEC875B for ; Thu, 7 Sep 2023 21:31:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F9D78D0005; Thu, 7 Sep 2023 17:31:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A90D8D0001; Thu, 7 Sep 2023 17:31:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D8BF8D0005; Thu, 7 Sep 2023 17:31:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 25DC38D0001 for ; Thu, 7 Sep 2023 17:31:19 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 016B0A01B3 for ; Thu, 7 Sep 2023 21:31:18 +0000 (UTC) X-FDA: 81211097478.17.CC7F454 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.88]) by imf06.hostedemail.com (Postfix) with ESMTP id 5522818000A for ; Thu, 7 Sep 2023 21:31:16 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=WmPVCSJr; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf06.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.88 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694122277; a=rsa-sha256; cv=none; b=07FnFUi3XCJkYwf6zoTd/pqEhn663Wrkk/0of+sth8RWJVc4qH/BgV9OlilMyEzWyiz0K4 RColahyj7dCM8eQAUXbaIbCo/aNhCDIvI9ULFOgy1KheaE4giPNUyZM5cjLORLvzlgm9C/ dJ5ebkO1AW42a7uScf/0A7c3jUqyxZU= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=WmPVCSJr; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf06.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.88 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=1694122277; 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=VIuU2HGXCMJbAzWi5mLBT99Yhn3J82xOV0pdlmT2ObI=; b=8DpynY2StokD8rBCP6XaV8f4eEHjTNyK1s4uqQ6FdEl6fBwzJubWESBJMRiq5n+Qgdof01 wUoSYBWRFrPMNKluAQaIf5sn8+0PyxpO3DUopjg1SHHUNOUmrVkms/S/IZooTDENUgKXHe mZE5LibM72cv8BXhZkAhtbVN6xzFH6w= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694122276; x=1725658276; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=eyplcqMShK7JduyqqjFDLu2TyYp5DTL3jHCp4kVYupU=; b=WmPVCSJr9K27qgv8oZcBb74iUosCG9U1dHNB+aJcBBUqTPKki3E5onRe iD+v1B0edOAWwhnWxWPRHuinykSkclQ8zbWyKZVc3f+mLleQ17WpGFlA0 iem8ZUkP0zZ1VxZtxC+4DLbW28H74wzKsWuq/jRYwQNbfoeMAooW2A7l9 /l1tD6c+vwX/zhq7nIY16LJ5RHcALiAkXnuuQoVL17QhIa3LmTe+da8Ku Xt/59CfaBOHYWoNBIx2YiHyuhnhG3Lpb28MZfrLdWyB727H+BjTKY+s09 OpVX7xQTEyhCsoNLzaT6TGSLtbedOFHJs/wKcUru9hd+TT/XrC6Wu/6R/ A==; X-IronPort-AV: E=McAfee;i="6600,9927,10826"; a="408473770" X-IronPort-AV: E=Sophos;i="6.02,236,1688454000"; d="scan'208";a="408473770" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2023 14:31:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10826"; a="771451251" X-IronPort-AV: E=Sophos;i="6.02,236,1688454000"; d="scan'208";a="771451251" Received: from ningle-mobl2.amr.corp.intel.com (HELO [10.209.13.77]) ([10.209.13.77]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2023 14:31:13 -0700 Message-ID: Date: Thu, 7 Sep 2023 14:31:13 -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 , Kyle Huey , Dave Hansen , Thomas Gleixner , Borislav Petkov Cc: 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-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5522818000A X-Stat-Signature: 6yo1x7kubfhryoj8ipqdnun8esqdwgro X-HE-Tag: 1694122276-353763 X-HE-Meta: U2FsdGVkX19uVfs2RAxjPaEGGJecPP5qXlzE0j4WHam1ZV0Ge6t5EwWGDtnAXnQcSX8S69E7slpkecnilGC0Du2UGH1mESwyys8q59iMA95mu1sEUBLlTbDHbVQGxvmQMj89BXfnqP6RENRTdxgtS5TW4q6A+OzQ+x/z0hjIwoMQ5WLqx3aNQzQCzDDnXceTnBhIe2uQ3xtEHLDPuJo7e5lU6w5WYm33Z1tCHUOCNgEMrEexdaDQlRaXjLrFh7EFqm0Ca+0zSk7WwS5pw9HFwvmdLX05Uj1CMrT0sDQVAz8ud15bL9g6Nyz7GOySV6oX3ZzTK7hWD7WmjPX6JdGHRe8Wrqm4hyWCx2Yam/Vye0R+GRyc/vdyR1MZlBEK8vpGIYFVxlAI1ZiRGFCqj89D8QZe16APHAGgkiIB2IRlI7jeUn5CAW8zLgXv81ZwcJIon9FLynrqF6kK2jIeVG9fb1urc4vYRZtBoahfIIy9qyLtuy4N9Naqzky3YF3Hr7ilpIRh4hzOeAQjgkzlko7PwBTeMf4DRrWKXK7Z5P7K96MabUK3Xb+Y0zylXjUSv0Mjj822oQ5sNjr1xQrY9j2TuRZANYi1+HYI52Bsayi1sZhvGnsr7HsTOzLjJIsJRsx47nXRELgYM4JE8wsaSeKKBVImcD1vdRn4s/Q83gjkZMY1PTkSv/UUXQ4Vb+63C7T/2iJvjNcHFlfKdpynMwkzoFnHQyi9KOAgh8KWnIpIEVQjFv1Jg391JSr+Z4+evoqiWl9cxlOm+8XeFB8elOAgEt0pN4ccg7cfOac2Q8frA3KbbXu2Udlj9UPW+WJXDlTZbjh7g6RdgF3dnNc5Q4X27PQtgPgbPnpprxqP6ENQnb9ZNO/svh3Dh+TJEmtCFa7JBpG/KNd5VSlCeSLz/aBXljMKs0so2F8V82pgVrbPZcPwrKYmpD+ece9Fs35QG9YGm/VpRqNdFsfi4TtFOZg UJzd8t42 SYGyImObW3uHNFV/CBqGJra/73eNeJd+g1OJN/1AFeTHoEVkiwBwkhhHueSklQsF11uOv/m4y21xtwZTmXpfwxEnnmSwmTfBxoH5cG2KOaUvCchrN4rICO7Jc9ljGk2qqXRn2sJthXp3RkKIHBbMPgHiKWctJtC8UY0DcQJ2hWzujL15Dhvd+X0PcMkH3c9Bcop6VMpI1H7yqHP+0DaO+SEWKT6emdmijnAnig7DfWFHMB5g= 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 14:22, Robert Kueffner wrote: > Is there some way to make this work, or is it generally not possible > to successfully handle exceptions if WD0=true? It's theoretically possible, but it's in a grey area. The kernel can't easily try to respect PKRU *and* override it for things like decoding userspace instructions. PKRU should get reset to a value that permits reads and writes to pkey-0 before the signal frame is created. But you're obviously tripping over it anyway. 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.