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 4E739C77B7A for ; Tue, 16 May 2023 23:24:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AF773900004; Tue, 16 May 2023 19:24:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA82D900003; Tue, 16 May 2023 19:24:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96F9E900004; Tue, 16 May 2023 19:24:00 -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 8491C900003 for ; Tue, 16 May 2023 19:24:00 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4D06F1403F1 for ; Tue, 16 May 2023 23:24:00 +0000 (UTC) X-FDA: 80797698240.26.064023A Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf14.hostedemail.com (Postfix) with ESMTP id E812C100007 for ; Tue, 16 May 2023 23:23:57 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=l72lMvb4; spf=pass (imf14.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.88 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=1684279438; 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=GxU/T9UmgD0owD3UFg1In71xZ6fYxxqEnI5sVyLNZ8M=; b=LBB3A1w5iRmbAwC3lK0F3t/D4NWj+vsT4Bg5Zd0SHn18UDRlWKO8qSpa7FyniEX1VOk3gh Va2HGQjnI1Kr2skYDAggVG5u8NHloDg7hpJU3oNCowKR/lJ6Hm1vAC0ot7Y/qhYlxAunMc mldfOKzwWLfp505O4sSZfRyIn6F2xbc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684279438; a=rsa-sha256; cv=none; b=5kezBXY0XQZh5m+23ptAmOmCJ0LG14DWZayJ932G3XfhPP72HveM3bKHC25EK1gp93aLbX 5rZ2az6KAAUeNdNgiSkLcWaUXFefNpH0QzUi7sGIwJCmwN5W59Aik14DAMX9hjqwRccAYp f56vOPn8m3IGw82uHIBNl8+YoG2Nw90= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=l72lMvb4; spf=pass (imf14.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.88 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=1684279438; x=1715815438; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=wgM7eIPJSPaebudw9GLyN8QMt1bMjOZTH6XelPWKDrY=; b=l72lMvb4l6aFhwgZ6xS/4MWL7EO6GLRK9ZXs1cV4nAYqwaQ08A9cXyOM CQwHgBU0RTq/2IBiCw5KIu1gbWGF8peUKDH9m01ENqtKI34zGYMgi5E+G FPDr3PtVgrC34e/hFs60kCQEPHpgmIONbkVv/e149BRTw3fehPoHCIc3h E1WtQO1f0Pisy0L7Xl8IKfXDqLFe4O+0sE46GgJi9KTdB4dcmgRoDLWDM jtpyjhQux8vqMGavnRl+P1YPxHedvwL1G0I5Ef2BMamEgoN0kN4a696gY WEmxQX/WTxlMohBltqswdv+AO/3hUMbpiJtxGaVb8b/GaZxofubs19hJh g==; X-IronPort-AV: E=McAfee;i="6600,9927,10712"; a="379800871" X-IronPort-AV: E=Sophos;i="5.99,280,1677571200"; d="scan'208";a="379800871" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2023 16:23:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10712"; a="652007679" X-IronPort-AV: E=Sophos;i="5.99,280,1677571200"; d="scan'208";a="652007679" Received: from mtpanu-mobl1.amr.corp.intel.com (HELO [10.212.203.6]) ([10.212.203.6]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2023 16:23:55 -0700 Message-ID: <4f14a645-3569-2e3b-f55c-3b17b567845a@intel.com> Date: Tue, 16 May 2023 16:23:55 -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 5/6] KEY: Apply PKEY_ENFORCE_API to munmap Content-Language: en-US To: jeffxu@chromium.org, luto@kernel.org, jorgelo@chromium.org, keescook@chromium.org, groeck@chromium.org, jannh@google.com, sroettger@google.com Cc: akpm@linux-foundation.org, jeffxu@google.com, 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> <20230515130553.2311248-6-jeffxu@chromium.org> From: Dave Hansen In-Reply-To: <20230515130553.2311248-6-jeffxu@chromium.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: fm4mw7bzps1a7jeo5ynqfgfzfdgie98e X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E812C100007 X-Rspam-User: X-HE-Tag: 1684279437-153974 X-HE-Meta: U2FsdGVkX1+opYi8g6sVMduMv4ZP8ey+wdBusOjcjx4/77DjHy/t0G75KAXK12tBrgZUQBxwLR/R8VwlBCJDgae5hK522CXm35QLmOXa4WtqoXNIoffG24LvmxKPAqSxwc0afW6xMgFe2vtYp5qn6N7rAZMuQMklAPihvcsgVuKG7rgm9bvsYbJSpJb0Mf/AKEQRkz5aWnCXVgl4nsm2jlaNT/qz9oELZE2l1s5t0nje+Zmyvgwl4wmhdBfOsywq8irOrtXkRLkGOssGcDHvxkWJ0b9644VN7yYKAt9sfmSDvIqgUVZEFcbv24qCywrqkvXkB05SENyz4sOsVDrRJF35dhmvHMeWLugMMJxQ5nq8PNleuBTUbi5eQh9hxb44rPAkL/wL9x3ftqBuHrgudQNLE1+1D7h4n5AZlJVYUOEeKFU/navCjDKp+d6mxKlnWZSAY/iMvmhS8g+791bE8cWy9YbdSsUTLYxF8s3ryHlNUX+Tbe90vG9iinzETpO9upygomeCaAnjpSGeJtDbwLILs21QjgRqobKNg10d6hmRIQ0kYevXgbmaiLX5A4GWNMbaxI3uG7vne1AgZNIRuex9GZONAaUw2uyBsQy+/Zr0cIaMlX2Pwb67Rk7T1avfoOR28XfrcDQf+a708fm+0+FM+ZH3dgrSJGmWFLFKSgJf8ZKXaT/NVtyadnTBBZoMAdvlUp20QiUixK9Qzissv8CXDaDL0J2a8tMC8cXQn5CR7qmI8h8fsCL25pLzgar0k6SY9/Fh939NDU9a+193Dw1KENYYebfHvNJqaZQRSM698Fd6xQaaHdM9GByLGW+JsKZhySGJNNZehFDoJen05lNaiXhNqyyixVtvnYhycWGtXb6CX4ukGWLwb5heLWwjZNKl76Lr+nigjQFZ8aWCMpRlQ8q8kX6xHAXp63foF/V3ya9nsNpLWPP425z5a3t6gJJeeWHc+xD/k4QiEUD 8IlbelkZ XHGikBH3ogOhg/2TzWlYKHUckQTrGvluk2iEOUVOK0dQCiG5nUxBXYRPpzw4bOB7/gH+Y5xAgcWQLgL8K1XkEbB/cq1xXrL1Xri0W+wlnEqfRDujau7OF+VTXhfCLzSQDvJl7xqUSlOaAxSXLQgSTsqGpQifsqg62JQlCA69jOPDW2C0BIzGqAM3xijV9FanMTjRJa0MeX+/S2pZtJO5gDEQXXatoQOyMLIYqxRqegsrWU85kA9v77fUdtIH5MiFXH4G+BKoKUMXpZjo= 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/15/23 06:05, jeffxu@chromium.org wrote: > From: Jeff Xu > > This patch enables PKEY_ENFORCE_API for the munmap > syscall. The basic problem here is how we know when the set of syscalls that are patched here is good enough and how we catch future functionality that might need to be captured as well. This mechanism really needs to be able to defend against *any* changes to the address space. I assume that folks are using syscall filtering to prevent new syscalls from causing havoc, but is there anything that can be done for, say, things like madvise()? I bet it was harmless for a long time until MADV_DONTNEED showed up and made it able to effectively zero memory.