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 12DACC7EE2A for ; Thu, 18 May 2023 15:37:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4D6A1900005; Thu, 18 May 2023 11:37:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4901A900004; Thu, 18 May 2023 11:37:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2FF91900005; Thu, 18 May 2023 11:37:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 1B768900004 for ; Thu, 18 May 2023 11:37:58 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id DD2D6A088B for ; Thu, 18 May 2023 15:37:57 +0000 (UTC) X-FDA: 80803781394.11.295FE0F Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf19.hostedemail.com (Postfix) with ESMTP id AA6521A000F for ; Thu, 18 May 2023 15:37:55 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="m2oH/X4u"; spf=pass (imf19.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684424275; 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=knEEE2+bhpCZLB6A+SXobrBqzLAV7eyJdl9h1DpUnNw=; b=hyGqOJ10T1GiDJ02xlm5rtNyfJ2zmw81Tn9FVoxWOSB/VXfKo0aMdeUEODFwOCUrHP4BrW MQfof8qlAFN8+oXLNP+CkAq71YQwlivV2H1fsGdTvakn/m+BdO0ewDGtOwZn4htacLCrtg WSOrVcLNPJOFN27Jpl9V9ZFFqO78GAs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684424275; a=rsa-sha256; cv=none; b=269vF7nCwGcyLEZS0R/6JnCD8JVQq5BXf0DXRP0aM/G0MJ3D2QWBLOQ1PHWaGOnj1rrTfc ruJlzN2m0OjXb2lSbEzbFvcpr+qjBcYn2YoilDThxNQhUHSAjX/acDbN70TUu2LAC7+sob pC4DTFviYnBSDbXVe19zBD1Eb7Z6QDQ= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="m2oH/X4u"; spf=pass (imf19.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1684424275; x=1715960275; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Z8XR62TLbLJfdA4SZDksnAzekPNNuRvRVdCm1RoqboE=; b=m2oH/X4ujFkGnObecHSmEL6UHkKXUU2wBGYqCHvD2PJh7SzK8PGEhfs/ sD8szjSBl+OAjhuUehEw4377GpuIDx2ldF/y+Mh/WKEW7FROTZY/CYS5/ XpI8JeMoaaDgw6PHf2GTendVK+XtjECHjMrjeZCnhIPk6rXFEPf2xV+Ga LePjG1ni8wRgvuy7n0V+ctWdcwxSNsrpr2SNJ2t6E/NPhRH/dQAqtXCh5 /+UZQdbo3tlxLc502vWiVSJOHyu0MQVx0GkprhJ3WX/dFU03+GsqijrTI YSm3Z4S++/TGRg35T/qHJGAjyPIWVtaJzH21M04u9Qg11NZ4/WFWVX3rY Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10714"; a="336686065" X-IronPort-AV: E=Sophos;i="5.99,285,1677571200"; d="scan'208";a="336686065" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2023 08:37:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10714"; a="826428246" X-IronPort-AV: E=Sophos;i="5.99,285,1677571200"; d="scan'208";a="826428246" Received: from nroy-mobl1.amr.corp.intel.com (HELO [10.209.81.123]) ([10.209.81.123]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2023 08:37:52 -0700 Message-ID: <2b14036e-aed8-4212-bc0f-51ec4fe5a5c1@intel.com> Date: Thu, 18 May 2023 08:37:53 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH 0/6] Memory Mapping (VMA) protection using PKU - set 1 Content-Language: en-US To: Jeff Xu Cc: =?UTF-8?Q?Stephen_R=c3=b6ttger?= , jeffxu@chromium.org, luto@kernel.org, jorgelo@chromium.org, keescook@chromium.org, groeck@chromium.org, jannh@google.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org References: <20230515130553.2311248-1-jeffxu@chromium.org> <2bcffc9f-9244-0362-2da9-ece230055320@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: tn3r946typwxgitwj64ss7oxnyxazuuu X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: AA6521A000F X-HE-Tag: 1684424275-28036 X-HE-Meta: U2FsdGVkX1+ayhyPwcnTt/DLOTIdZIM28Y0uzAV7quUF9KJBklD1Bggel5fAjuPWkHOR/9nX801HwaFmPBlAx6g1kfOVKf08ftLl2oiFvXOr8l7JiVwGUwoLuK6hbBOgThKYO5uhXq2uAPxR1GPuOUq/SEDWclM7O20UBxyJSo/wTVaQMGiQ3cWc465KIxO1EaouGQfcBpZYu/puPq9gVRyzGGsnTsIqkeXuzbyXdV9PDJtgsXDtrUX+V23qtw3EoJjU2Z7lNA6696rsWQ54e7tPs/hvTxkVzkPmsbrmaOiqPtKItway4IMh1j/PnKTtIiwB6gvEGgEb1TtibnX9mvD4o0I8VTw1y9SsKwq1Y8Hl7aCc+RBr9aXspEU5XmCw56GPNWvIY1UBcka1As+2JUPPOJiogAGjft3dPBxmG4bi8nx7d/pNnHS2VAIe75ZY2LV6faS8EBEE4EoNe2QLj2c/h7Qo0SkdQDil5LgRgxgdhxPJ5qELw0QenZdfXQNaBLYhNRHd32OPzK7Dyfwiqxxbt9keyihVhbpvtakE4WqzJwG6yynrVYlCLPh693o5YWv4xeiJg5+Jpedz7M1UjQp53O6VNIHrVnonD1HYL1oURuhtzWGgYNxhcV/TVcuG3x9irfdpD2MBTvnSsAAnwwvnjMBLKJQz4Zv+TIQh29BAdAq1FU7XRg8Ilva4tt8xxRyhmlYwER4PdZDdsNq8J1J7OSo/veHU8Yfc1x7wtJzWi0QKp7s9g74bTTDJol4X2+Plb5RxEXHj3EtLzLw0qRjJ7Gzj027VehzhQmLlKbejexhguDSVREU4NxgRJ21N/MRT0gq3gy4rUG3xEitNv+RykEP9fW6oSAxI7TONxopMhWDhXzpvh3crz4sJ0TcIoIdRkcmuUsK2sE0AuyG1So1//fQW0sMlQaHW3NUcuodV+fORYYYvtt9JkIsX7C1+byvto8ZSShRss7otup3 kBgsCwO3 5T2r0rGLoO5aH/zKRfXuUO0BKZ4eRcorn0nimEEDsnX2lS41mQ7Abcx2jvkosf4x/cBoATFT6e8uSnDPH+E4NRiM9o9FlhQzDGbcqom9wBTu1o8kNO5KJ48F382NqTtxW7qa4vQgcvZzrzIx+E28Nr9oWxg== 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 5/17/23 16:48, Jeff Xu wrote: > However, there are a few challenges I have not yet worked through. > First, the code needs to track when the first signaling entry occurs > (saving the PKRU register to the thread struct) and when it is last > returned (restoring the PKRU register from the thread struct). Would tracking signal "depth" work in the face of things like siglongjmp? Taking a step back... Here's my concern about this whole thing: it's headed down a rabbit hole which is *highly* specialized both in the apps that will use it and the attacks it will mitigate. It probably *requires* turning off a bunch of syscalls (like io_uring) that folks kinda like in general. We're balancing that highly specialized mitigation with a feature that add new ABI, touches core memory management code and signal handling. On the x86 side, PKRU is a painfully special snowflake. It's exposed in the "XSAVE" ABIs, but not actually managed *with* XSAVE in the kernel. This would be making it an even more special snowflake because it would need new altstack ABI and handling. I'm just not sure the gain is worth the pain.