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 2392CEC875F for ; Thu, 7 Sep 2023 23:08:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 55E3F6B0074; Thu, 7 Sep 2023 19:08:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 50E8A6B0075; Thu, 7 Sep 2023 19:08:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D6888D0002; Thu, 7 Sep 2023 19:08:07 -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 2BD8E6B0074 for ; Thu, 7 Sep 2023 19:08:07 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E904F1A0E65 for ; Thu, 7 Sep 2023 23:08:06 +0000 (UTC) X-FDA: 81211341372.10.DCA8FBF Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) by imf07.hostedemail.com (Postfix) with ESMTP id 246DA40023 for ; Thu, 7 Sep 2023 23:08:04 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=F5lPkmwz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of r.m.kueffner@gmail.com designates 209.85.221.175 as permitted sender) smtp.mailfrom=r.m.kueffner@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694128085; 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=8EGrTs9IEoHVg0i1V0nP1EnGrXTJSERh0Kb4udXyvr8=; b=npMuW+8dOqmvf8PKk4E8PJcf9z13LIN26eIcDpqZrhZ+B3Sue4/qIXF1ZBC4ySzg8aYfbs SCtASPpndJqIUwT8z71Mtn+m3/VzWYDVT15hpy4eLLwZ0Zw+9NdRVKB1YAAaQHDLPHSGD7 WYC0vZnP1C26jcT7fQJDQoHVsRCUvX4= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=F5lPkmwz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of r.m.kueffner@gmail.com designates 209.85.221.175 as permitted sender) smtp.mailfrom=r.m.kueffner@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694128085; a=rsa-sha256; cv=none; b=yf0ADG+Mc4uCwb6Pi867WLmsP/KBL8w0eG8clICACGxNAsMUCypPF4V+/WRPTSXmnahJ3l qF2FC7HlNuu+OgavrcOdALocCnWTgA7EXk9Q7DhR3Ofs1z2DV96WqJk7TKbVUw/bLWD0KV tlBDvwm7Uha+nWq5LSRop2wz1H5YbQ0= Received: by mail-vk1-f175.google.com with SMTP id 71dfb90a1353d-48feedb90d2so520884e0c.1 for ; Thu, 07 Sep 2023 16:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694128084; x=1694732884; darn=kvack.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8EGrTs9IEoHVg0i1V0nP1EnGrXTJSERh0Kb4udXyvr8=; b=F5lPkmwz3rHmaECYeoV8U2wsUE1KbZyVKyEjGOxdo5E0T0E+ePBPGLxA7I2e1uc+9r A0cq5Is37Kub3LWMqsSM/s7yS6S6J+VfjLc2cru0hIuxRbXH08GgirMippTEp9A5kJsn yboynvNPOMTQvW+JVTLZK8jnc50jIlq9pICj01lnEW3pC+MIa3U7tEE4BDlOmaHe0Ari z82XnG5sA7nHxs2a9cy9ZcNUOMFKM2o1kGZbB5/lgEFio3R+EPsBYqPuIvgpa9+iU9UR JJ2zOYBh2foFD8HoZLz7rko1k6XBeurHdPN1JHNbBM+nNY/OLiIFW6XwR7u38XgkJDVj eVDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694128084; x=1694732884; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8EGrTs9IEoHVg0i1V0nP1EnGrXTJSERh0Kb4udXyvr8=; b=CUbQLY7b0OP7mSEMmL+ZogRj1IngxVNkJhJOixOX9yFl0GnmYK5ZpQC37SyyVE8U0x t7LovO8qM8cFeGRo/3W5QN3LcN1VHSqR07fF/naKqjogMJZlBUvim5T9DkBU38KNvbi3 9JtqEt8DsS4mL/GMWJlPsFhBGZclszY88sPugEwrVQzKP2ysnA6ruR4XB4L2rzZqX4oo iIGvduGyhkJdmTyyivhQddbEVjgdfM4v3zR7J+j6K6eCHqPf3rmlUO/E5SVOdO+hUSfD QwkaPsntNDSYDi9WwxvRo5kg06X0FnNHU2FqHt6OhsGrAShrCOaW9nPwzmGRSi3GzU8N 8zng== X-Gm-Message-State: AOJu0YwMgmyJz4jEug83c1+jis0OiskEKa5f2h0DMDMLT3v0+9CE8qUi YyrWLCjCJx3besCWudhYq2E= X-Google-Smtp-Source: AGHT+IF+P2oV641MbPBzfVdFETip/2bu98aLkTXgK+0LrlYZPtpnaBuAXeWNHNgzWqWtEJpnZ60igA== X-Received: by 2002:a1f:cac7:0:b0:48d:3983:24b3 with SMTP id a190-20020a1fcac7000000b0048d398324b3mr1105726vkg.8.1694128084118; Thu, 07 Sep 2023 16:08:04 -0700 (PDT) Received: from smtpclient.apple ([2601:189:8480:9a90:e176:8006:767b:ffee]) by smtp.gmail.com with ESMTPSA id f27-20020ac86edb000000b00403cc36f318sm201061qtv.6.2023.09.07.16.08.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Sep 2023 16:08:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: Memory protection keys: Signal handlers crash if pkey0 is write-disabled From: Robert Kueffner In-Reply-To: Date: Thu, 7 Sep 2023 19:07:52 -0400 Cc: Kyle Huey , Dave Hansen , Thomas Gleixner , Borislav Petkov , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Robert Kueffner Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dave Hansen X-Mailer: Apple Mail (2.3731.600.7) X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 246DA40023 X-Stat-Signature: 3e5jusdk3d6xsrq7q9iu6puymixnjwhe X-HE-Tag: 1694128084-843950 X-HE-Meta: U2FsdGVkX19zXhTzAS2nq8BcrctG/o4mUd3LOgGWTOHcK7Txq9b4woIaGSoVi8Z+648EsmOCEWpWSGHccHKxC7BU/RYy/99Q6wx2/QCg9cUM7qWGlLqfkKjx4E4CJDh9g0bPQcMQwpuBb6US8iHvxOmROa3Ncs3N7YUQp2uSgZ7xlPrAGmlG+nhl7yHBET6916U8ZfcTxOe6i6RbSWBC8SXN//I7rpuqphbEBZW+SHO+d/8LIup++24kyfjqhdCfpjmReFhAeh0R8M4MMgAz9kn6dRN9TbYfNQAaKfr+ahj3MAEkiLm/T2JV5pt3WBksL05LDld2BjfUVhLqV2GsoJe//2fR9sfE8MUnCTo0Q9RIM0s6rhFQNGowAjyuKpkveMFAgKKJV0aTi3CQbXHZ45GhmM1IDaQNqAEO0bVrPruN0jxv38rqzU5OAMgfVvsXB3n+rLKSGgw+z0yPtSE0J4T6xtBXyc/MxaaZRUGzVexAQIcNmSK05JpEHL1B0FN7hja41Lu0fNyb0xHU+4PE4YdggjtgVyiwcuItC0kETqI40TCa9u85Hq3hH3QIFIbE7kWUHNOHO7h2FIERuREI5QyXrdvCcJe/xr5Rvhk0V5jtz6HeWpUvd1A1V/r665i/XTTjhd3hmMj6YGLJnG0sGXgRsMCUuwbqsutsr8qflFRqSHAIQLoX5RkGYDTsXO7HSBNOIZWxzL6B/Hrd7wjVLAR1yBmPQsk1xWv2oDeMSAWESbBJew1bkk1ayChfp4XvXCUoFv9XPUjU/KNtFm3QAJj6GtUWXwkWtmUwnl6bdrAxu/oEQNnQ0B8M4h3zCNsdfIdbI73+5HzJvZ0KMZ8X755aBK1kW8IMSsMO/Urd0zJdYIlzugsz8BmEwfItJwujRmRKfVnE5sMFJmmthrMZBD87rga2rVB0whJlydZnyIVGBqOJeBedehHxexaOlrl2mSmpXWX75Nxv0EEEKv/ dIJI4773 40SD41zg/7Okn3SKHsUzRNCzr0aCeFKEfdgq4hEAuFxMlAjK0BbizrHIQFTrSM2rakf8oSEMdEaacMR47LQLLEIB7hG34zhnOg1QtUfwy9pVFNsKiKhrJsZtXiXdOI5MlKxFNDeY/AaPyQR+FtVW2p5EnHAK8Lb0MfgMCKAXB+NeZgNcy6f3uxzgRq/+mP7P8QdpST4JUGwuy2VVqOgrsvS2qiblQiYhhaA1Ow1ePcvjpHGDsBwMXMDxDTIl4bG4Lag/d4DLhJYoUeia2L3H7Zo7xeF58QfgROnOcYxwUDYwGvPoDuURPZxmqNUl4bmvaIG8Ui3zwtzW6zDN4uXyq3TH1M9p77Czx77VBu+ONAYF0oZrC6pneTW8Ej+IapTDfBkK86ZnrdsL1gXUQ+qoq3IE9AvMtS2LZ3FWH0PwRgKCBU7EOchjnZGWcAef3jo/U6B83n/djizSbgysNnLn9A942RN8ZY2wBoMZgJdwJkBjzOEuHi4V2E9ycOnTjHipFJkdVHnJH3/eLhBvOd1KAi1nlHPb7U2t61amI 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: > 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=3D0x55555554 some time before = switching to the signal handler. And may try between (a) and (b) to = write pkey-0-protected memory.=20 This would be compatible with what I see when my user code causes a FPE, = upon which there is a SEGV before the kernel switches to my signal = handler.=20 If the user code causes SEGV my signal handler actually executes and = only fails later when returning from syscall 14 in sigprocmask(), i.e. = sigprocmask() =3D> __GI___sigprocmask =3D> __GI___pthread_sigmask =3D> = syscall 14 I will look into tracepoints - but that would be diagnostic rather As a farfetched solution, would there be a way, perhaps via a kernel = hook, to reset PKRU before the kernel actually starts processing the = signal?=