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 A6730C7EE2C for ; Thu, 18 May 2023 21:43:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3B058900004; Thu, 18 May 2023 17:43:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 368E9900003; Thu, 18 May 2023 17:43:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 22770900004; Thu, 18 May 2023 17:43:40 -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 10434900003 for ; Thu, 18 May 2023 17:43:40 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C870BA01F5 for ; Thu, 18 May 2023 21:43:39 +0000 (UTC) X-FDA: 80804702958.16.A5D3B5F Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf24.hostedemail.com (Postfix) with ESMTP id E98E7180016 for ; Thu, 18 May 2023 21:43:36 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=jEm5kcYn; spf=pass (imf24.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.24 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=1684446217; 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=hN6CaoDx+Zr9B8ZkJv7Dp8yj8RP1xEvR8rlnNY5Zv+c=; b=iVjzxaeHCxOmH/6X9yjMHGfW2MEJwDot7HWSW4N9legd7LuBS1W2Lt1YdCQ9qWJut7WvfT tbDh3O1MlHcv3pz0CZj8plXC1XuIiisMMs3fT9vctE8/duU8uS8tRx5MXfYwopz7WStX7N 301LsEFfAmq372nk5bqGIzBgZReIriM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684446217; a=rsa-sha256; cv=none; b=Dprev3+zySVOszl4T1f9REyp1VvkUh3bPAcorVv+b1ljd+HuGm3RKuNFc7kxlnW5LUO4kC wplrMJnB/7UrpbQ4ZSqu5F2D7QsZ3a/nolH/R3ZCn9vCKvRSS1LanQeEgBWHwDSeVfQsvk bxDGVvYrwAXpN7YFmcACN+ahylfPGHo= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=jEm5kcYn; spf=pass (imf24.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.24 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=1684446217; x=1715982217; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=FCvlPDXlcdJACB4EQCU/Yj0sO6IJ/Dvvnamlu77Mjcs=; b=jEm5kcYn1iQKrkZeOwcuWKgWDn3vHo3nvfDieA8nU6VPLo7g/xmZsY5X tqf7LCu+LJ1550FPize6yeGq7uFovgxSYm9/zhSEGNtpMjKPunl42EwNM nDEN4q4lfvcg2dmyQMda9uXwL3r5Adw+o8xp2Qa4Mah1fNX0nVqxsS64H zjRR2K3o5gvxMNoRTtrP01Ai3QeL3qUYQliaqL8xTyPMX39QIi0+qXyw2 sdttOjS97CvJdTkobrsHDDjLZled2sHbNSbPp3mvkmOvNMEgJVe9DZxJw KWqZfE+Z5mfuu1HzaqbY2Xn709SMGvegeZt4Wg8/aDv3tfGWRbBIr158P A==; X-IronPort-AV: E=McAfee;i="6600,9927,10714"; a="354547435" X-IronPort-AV: E=Sophos;i="6.00,175,1681196400"; d="scan'208";a="354547435" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2023 14:43:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10714"; a="948850882" X-IronPort-AV: E=Sophos;i="6.00,175,1681196400"; d="scan'208";a="948850882" Received: from nroy-mobl1.amr.corp.intel.com (HELO [10.209.81.123]) ([10.209.81.123]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2023 14:43:26 -0700 Message-ID: <6dbbc3da-78c9-8101-d52a-0be47da9d67e@intel.com> Date: Thu, 18 May 2023 14:43:25 -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: 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-3-jeffxu@chromium.org> From: Dave Hansen In-Reply-To: <20230515130553.2311248-3-jeffxu@chromium.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: E98E7180016 X-Rspam-User: X-Stat-Signature: c1zrqjyc1tcbdpc588mftfsect1pezaj X-Rspamd-Server: rspam03 X-HE-Tag: 1684446216-541597 X-HE-Meta: U2FsdGVkX19C0aKjkinPx7ajy+mtlELYdccr1ZwFrXJiePdjzvLimZSwviyUVIRN6S8jh5MOP5VRr3NbPMQe4UA64sHrTk9OQr/PvGGGqQj5SHb9g3Jt1VmRfwi2xKsObyeeGC0Fm90vxDGiPGmEWiKlE87saZgIB+uHAq2g0Hw5sICFE/fUbypvpjl03x946kWBvdzOkAlxgQ+dw8WJh8nk282YPB/m/sgGt03fwZWNZWAP7bZX3dcJr2BL7zVbhn9817HvTXSjmtnr0GCEBg46fyrw9c89D+tHZfjl9UgBIg0S+UAHGVrn+ILPtPljc/r77W9KXfZ71ZmwSuRGd7TjkITxzSig4Gg3bd+NlzycABZBrS6r+o8MvEwrAA/NkbBTOKaeIc4iweMnLgkONX8KPMFZ/66HVwFoO8LtJ0lHtJBnczEpCsTnWNXDDUfZ9LM2MfeIyvlnxuYvH4DsJCa9+Ugy3YQVyJGMYUdf/QP3q3Y+7mlgHAu8d1oV0jP3esXJuJxHx/u1674aniOwVLSdFYSd1qbdTw09n6GNFm28xigYPYr7NkqSYROhjxrwhXhXDFW5m44efSRCgT4LlCdhVMUJfTxP8kvZHgJ48LVbhfsvwq48FySAITj+Zt3NITFZ6Q79rcWRfZLNn6stbjXD7SJu3vVOau3LHJtPWqo5ngnA2pmvCdijZlA7pXIUPSU1Onp3VVs8rV/xXyYKFUkcdpiU4kyG6vdkLPpg13x55EwWEaRB27C92q8YJ6NOk7jV3bq6HQPmwWe92lYWaLJdMk6fYR3ud6obi9DCZKu35CxbVi/BoTHLqnbC2IO9ktnGHtHbomTpFCjlJOh7cZHfnDx7H7zPBja7O0JFrd3Lntx4FPI3rn3rL8k8zA+SxBWdCrmRsMXpaimSZmDcEYgGSOJdMBsJkfFtu04qjdEhtZwqQqep3wJGKRXlh0IE7Uv8lCCGUV6hLn+Aw4r a1+wqhf6 8CLj3/YI6sxRe39Bvx9Fq5CyRD1cidcdiNFJUdASmbSvjyplcpCxPm435SeRSGc8Kno19JKisscpIKDSCtHtX231mGvSZCnio7JJ12tVTmX61tkm88WfjgqtpCc6TQDCv7RIUrz7iMMiH2Koz7da0MhRfiZdHUWtiKb6kAery3avA+Ip9eIJ70xvhpabPToCdtLcSGTL331jDIA8Gwlntn4xnShp7Ht6OVrm9vKvz0ffTwnoprrsfqcsynPpMhLYB21lB 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: > +static inline int __arch_check_vma_pkey_for_write(struct vm_area_struct *vma) > +{ > + int pkey = vma_pkey(vma); > + > + if (mm_pkey_enforce_api(vma->vm_mm, pkey)) { > + if (!__pkru_allows_write(read_pkru(), pkey)) > + return -EACCES; > + } > + > + return 0; > +} Please think very carefully about what I'm about to say: What connects vma->vm_mm to read_pkru() here? Now think about what happens when we have kthread_use_mm() or a ptrace() doing get_task_mm() and working on another process's mm or VMA. Look at arch_vma_access_permitted() and notice how it avoids read_pkru() for 'foreign' aka. 'remote' accesses: > static inline bool arch_vma_access_permitted(struct vm_area_struct *vma, > bool write, bool execute, bool foreign) > { ... > if (foreign || vma_is_foreign(vma)) > return true; > return // check read_pkru() > } In other words, it lets all remote accesses right through. That's because there is *NOTHING* that fundamentally and tightly connects the PKRU value in this context to the VMA or the context that initiated this operation. If your security model depends on PKRU protection, this 'remote' disconnection is problematic. The PKRU enforcement inside the kernel is best-effort. That usually doesn't map into the security space very well. 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?