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 9F73DC77B73 for ; Fri, 19 May 2023 00:00:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EED9A900004; Thu, 18 May 2023 20:00:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E9D3C900003; Thu, 18 May 2023 20:00:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D652D900004; Thu, 18 May 2023 20:00:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id C4483900003 for ; Thu, 18 May 2023 20:00:20 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 91D8FC08A4 for ; Fri, 19 May 2023 00:00:20 +0000 (UTC) X-FDA: 80805047400.14.ADF4F74 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by imf22.hostedemail.com (Postfix) with ESMTP id 889ABC0012 for ; Fri, 19 May 2023 00:00:17 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="GUl+u8R/"; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf22.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=1684454418; 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=dzZQM/koflh/eg2iyctcm3t5Gh1tLorUlt7J1dEZKM8=; b=hKHmjrBc+D/Us1keYuc1Owo3hzYbRLj/SYjnwmcy+JLyTR5a0BEvC6iN+ggjio3+99XeGw cDkrl9+UdC0iLT6cLy2LRzL9OH6c8qXD08A0v1y/R5igEfrmfqxwnvucfK5Aqk3qkjhiKA OJg55EEpldh2dueRWmmki0RREeH6v3Y= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="GUl+u8R/"; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf22.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=1684454418; a=rsa-sha256; cv=none; b=XdVaZNYpoJNOJP/T1udwYtpkg9416lbkxIaDA/dk7ohyVvqiuEE5RhvnINBjmyuV5TaR5q Ni1RVasChBvWEN750zFAvhTkQsm3i1qvvgI3QibqU70Aj+dy33M9FYIDkRI9Nccw4NbjWG QR3/sLNm5YYsWrjMroLor4Z4AXtDdwA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1684454418; x=1715990418; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=5t/LbPMDhw3OuvazmSL5YCXrk6Z1rz2sQn9LegvfpFw=; b=GUl+u8R/xPIHlnaJdIqOhHyF433ktlNQycOLTV8ylfpoHRD4b9FCyqV1 4oh8uvDJsmz9RNlX1QbVN8/tdZYzPTq6kuOVMoioXif8Nv3u3P2D+bpul heqYhgZHVd3IwC73v3VkGUedlAN97B8/4AIQ/fxFCttrn1Af4KfQR4TUV 2FWcihdye1G9kxj21jD6tJ/SGYqiCu62KNcLILqS32c5IFlhZq6gFM8ps DcLJkaODzWxbPyRqFvS3NnNefMExCQWo7CGTzOEj37Mob32POCbfzGFm+ HCrTkdvefe6lGsvOMIwtpCkEyHr/4KGfXwRVZayLMNYIqAjrzYfIc4nGi Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10714"; a="352246437" X-IronPort-AV: E=Sophos;i="6.00,175,1681196400"; d="scan'208";a="352246437" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2023 17:00:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10714"; a="792144716" X-IronPort-AV: E=Sophos;i="6.00,175,1681196400"; d="scan'208";a="792144716" Received: from mkim1-mobl.amr.corp.intel.com (HELO [10.209.118.171]) ([10.209.118.171]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2023 17:00:02 -0700 Message-ID: Date: Thu, 18 May 2023 17:00:01 -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 2/6] PKEY: Add arch_check_pkey_enforce_api() Content-Language: en-US To: Jeff Xu Cc: jeffxu@chromium.org, luto@kernel.org, jorgelo@chromium.org, keescook@chromium.org, groeck@chromium.org, jannh@google.com, sroettger@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> <20230515130553.2311248-3-jeffxu@chromium.org> <6dbbc3da-78c9-8101-d52a-0be47da9d67e@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 889ABC0012 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: wsqb83sfhb9eq4sm6jtwm8prek5fi5pp X-HE-Tag: 1684454417-46112 X-HE-Meta: U2FsdGVkX1/FGhuZArb389OjAyp3Rx0tj1zUbup6lw/RRe7xo659AvTPsgjW1zN4Z2CyhNe6y178TdjcnFfpodYciFL371yn0t91S4Pt/+UcCbTksRz7XyZXGM/Nd33IsVFol7tdZTfvaKpd/qv2aAvTOW5TGazozv5/FbepiXa1dQjwXTRvyQ88lUJygby+RUKFpaHUoKpDMuii3x5ot3dfhJXRonxSEJAUhAUKjK/t3tqFwqMIa+INkyt41W5ZcEtbdz/gO70KAsS4J5nzm5G7BcXfRsLKzk1eb787yOoXHn/W30C42y9eSGcM/FFFDb9UaJr2ct7RX4CzGwZTaO25A4A4wfRA94qyA1ZxrmHyVefy6fBNb+A5ty4VN6gA8xwuetf1Y9roaTDTefogI9Wy9HP2nt2EyuIgB/XX80k6Hom39cfLB8SPcs5Hxr5mlWss/LitlMGHeCh21OyLgjU0QHgAFi4Xvu7rovVCisY0qYib5FeTaQ3DHqWDdmtVo+Nwx9O2giG0snj9AxtJHM80F1MIFZsHRiBI75/sE6BBVVHIj5AmumV2GJvU7nSM9VOcB2a6du0XFbArr2thXmiJrQWrMqufPklID8CKWYbmusix1682sHiI3uB8vnidZvAqJPNEfbDQpMt8mcckfnCTlaIXxync845QofCRzMWcKZpZZ7m66DF4tXgLhJ0zXVXGfWc0t9Y1mdMyWf6BLAIhuraXOLmYGKdlscFGzx1bQlvZhn0sP2v8g2JHKhjzRXX1Ax79MiQ8hnAYphMVq8fwFaYwIC7B7B6Jqs2xyqTN/MYm4sEL/itcLWfaRo0W4zNG+dwheoKDmRKp+Z2zwSApFlcrLZq36PAn8WSPmOUEj2BAIHwxjP8ySdb/f+rIYxFVT720E+3+PjQmbesxJ83B8g+rya2E9Azvr1wOWAVcO7mNswloMbfddWuD9gK+VMtO15BEK7OBAI5G1Jt SSP0vQIB Lxd5gj6mF8KBFO8lnTRNCda74uJMneo3Z+raWr1pq+tpDEz1uoW8YR7Mdv8K1DiU2EbQHNmBM3Na2ylLSuQds8U/doCzHLQwFzyotpBFPGlywqv5exJNeHK0Pb4eIGKuRXvyvjEGrCOt8XDDn0j/9ca8nFreO3xZetfBNa47FBLCw3Gkinz8E5W/1du47QxHf7pw5 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/18/23 15:51, Jeff Xu wrote: >> Do you have a solid handle on all call paths that will reach >> __arch_check_vma_pkey_for_write() and can you ensure they are all >> non-remote? > Is this about the attack scenario where the attacker uses ptrace() > into the chrome process ? if so it is not in our threat model, and > that is more related to sandboxing on the host. The attacker would use *some* remote interface. ptrace() is just one of those remote interfaces. > Or is this about io_uring? Yes, io_uring kernel thread breaks our > expectations of PKRU & user space threads, however I thought the break > is not just for this - any syscall involved in memory operation will > break after into io_uring ? I'm not quite following. Please just do me a favor: have the io_uring maintainers look at your proposal. Make sure that the defenses you are building can work in a process where io_uring is in use by the benign threads. Those same folks are pretty familiar with the other, more traditional I/O syscalls that have in-memory descriptors that control syscall behavior like readv/writev. Those also need a close look. > Other than those, yes, I try to ensure the check is only used at the > beginning of syscall entry in all cases, which should be non-remote I > hope. You're right that synchronous, shallow syscall paths are usually non-remote. But those aren't the problem. The problem is that there *ARE* remote accesses and those are a potential hole for this whole mechanism. Can they be closed? I don't know. I honestly don't have a great grasp on how widespread these things are. You'll need a much more complete grasp on them than I have before this thing can go forward.