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 932F0C77B73 for ; Thu, 18 May 2023 22:52:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DA78B900004; Thu, 18 May 2023 18:52:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D582F900003; Thu, 18 May 2023 18:52:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C1F7A900004; Thu, 18 May 2023 18:52:18 -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 B2FCB900003 for ; Thu, 18 May 2023 18:52:18 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8773EA0964 for ; Thu, 18 May 2023 22:52:18 +0000 (UTC) X-FDA: 80804875956.09.8621F96 Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by imf10.hostedemail.com (Postfix) with ESMTP id B14DDC0005 for ; Thu, 18 May 2023 22:52:16 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=p1QNWoXO; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=jeffxu@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684450336; 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=jWnUteL7v7/EAzuWn1drf3iWgiZd3P6BMPM7r3CRrU4=; b=LZpmqfwtgsm0Md91UFsZE6wuywOU4Lx4+Bt/Muv/mDitb/OXWBKN+0zIi//NrsMvJayXv+ uxLCb8VhsdP6OxO0GX3AhX0U7PrhYztsCyHaeGnCvqk9HCN5BDbcN0f6DlODYpP05Vhznb H2oBF63MfPym4O+pHhuokrJjTQpOv78= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=p1QNWoXO; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=jeffxu@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684450336; a=rsa-sha256; cv=none; b=0HXleUV7NmHkqhsXAyMukDGsWc4gLhnfPl484DHcLkMeyhAPXyuc9q6LZWrMB+gSR7uWUC J057F797RwToanISyEvOfGlk67AV3a1zJqnrkCUZ5nFN6ntkthxvbecTHf1VQASo7dPOK3 X5uketrp+irOizLqiGdpHq2D8y0uPPo= Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-510e5a8704bso1530a12.1 for ; Thu, 18 May 2023 15:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684450335; x=1687042335; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jWnUteL7v7/EAzuWn1drf3iWgiZd3P6BMPM7r3CRrU4=; b=p1QNWoXOV1xgKiAp3Uawa5ywP62PFwgqLlo1IX/Z7lbukYiaO8h726vLk1ksYI/7qK SMove0r+bWiZcvsiSYWZVvJStA74wecehJFZuXtuZYpVjAd5Xlsi2RjcYi7IHBrmOv7i yzKLfoDu7FGmybhsjsdzoQ8+9IPnyeexOugE2vYPc8H+CF77m1kr5AMWA0qoQIpVvUeK sftIpAXu/jlLnagqS/IEHrCGZFL3YaUrmtF/yOHMwzEYlCPnOXXqpTnBBR/ORpDE38EB 3+IEJL2Q7VHbtlApuj2xkqYqRwVdFB0cMzSDD/LVhIzYEr1abR+8elMLu/GsxPG1m3us Utsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684450335; x=1687042335; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jWnUteL7v7/EAzuWn1drf3iWgiZd3P6BMPM7r3CRrU4=; b=CjBhdaELLxJVYp7a4tuWF0xU/sCS0R1UMW9Kpks5IqpSOvHG606/6ayx/TJjnuCb7G jnOwCMGSmLP93A5wLfKVr1K1Ai7Udig9wYKHsJGu6Bk6wxwiMA9wvdphfkEJwv0WASEF q4wszAT3sntoQxH1LXIX6zRm4jM0OwzTFophU+oLXMFHXg2kZzLjCaGmp2CRR2dc5NF6 frEJonJWdqw+1XvG87ibaUeiNNUWQ4Is7AR9Dx4IsG87+fX8wX0eEADkeK+Y1D8VdF67 yfIk3aYCSl5w2vJN3nUP00Egg9W9P5nDgObXhCIlgAKpjKWXTCDtLwvtdDydsdB63v0Q lUyA== X-Gm-Message-State: AC+VfDwFLhwQoQ8JD7XO0Ih9IZAwhjjAjmbMl8iubKWVxoRzreD7GdRT QIjTB1XxcLcoSkmorXUhAwA2yVTFVtoJsKKrVhOX9g== X-Google-Smtp-Source: ACHHUZ58Y4oMqMeXjqbXsW1ohvNxVWhDEQwCHRAmPCAwpg14J9f/4DWK5igsACs1JEnPwKg/pJtqoSJ6YjSrESVBaLo= X-Received: by 2002:a50:aac5:0:b0:502:2af:7b1d with SMTP id r5-20020a50aac5000000b0050202af7b1dmr18114edc.3.1684450334862; Thu, 18 May 2023 15:52:14 -0700 (PDT) MIME-Version: 1.0 References: <20230515130553.2311248-1-jeffxu@chromium.org> <20230515130553.2311248-3-jeffxu@chromium.org> <6dbbc3da-78c9-8101-d52a-0be47da9d67e@intel.com> In-Reply-To: <6dbbc3da-78c9-8101-d52a-0be47da9d67e@intel.com> From: Jeff Xu Date: Thu, 18 May 2023 15:51:38 -0700 Message-ID: Subject: Re: [PATCH 2/6] PKEY: Add arch_check_pkey_enforce_api() To: Dave Hansen 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: B14DDC0005 X-Stat-Signature: c9p3dgzumuhsgcbhzx91rjtnoq5jw8xm X-Rspam-User: X-HE-Tag: 1684450336-434865 X-HE-Meta: U2FsdGVkX1/jjqi24x+W78PBKjB/ntGZuSzfLF3tc92ryRhtaVUWkKXPxK2uY1xONex8QyOVeCcBzNW6B7t2Ll60fizcFD+YEfYjRKrAUlXE3adrgS3WAPEamiFfp3svkv4cbcdvfGa94zQC1You8Aqqz0D1bw5t5EcLSf9vKJFJoCibmPg2IZ4aBGSUL+DLy2fzAJO9OhKSJniobTixKdcypDqIHpyi9fWtzibtgVa4BletV3ZPbTcwX9YWQSUou+wAR0k3c1ULDRffKApYXWIcrmrzhLNhDiP4qabkrs0EJJwYu5lws5xk3dhZva+eYFFr5NLIzChI5FBLoP/+xLKcKaRT9QYU7FY+3J5SkibzZ4BeDN9bgQD1zRWmbsDv+S1bqKBQ360ITCF44cpfA0s4B0L/bv98cIck+tT4O55Rca31SwqAQ2Oi1rOLsx0VlAGzjTGB+eoIfNpunfoxpSucryfGurjX39DbzyTHVkUFPQeCD1FpJwVj3VQ/8k+7fPTlGxJG5a9CSyPnPUsw0GEBKxRiNylZMoppmtdQpP3rPXbq3Hcwd1HaAs7meJcWYz3OhjXeNpbV3cdt32/zXJ8T6Jnwv7isAtKzYPloXZx+3maBkrWqQn7C2eywgz2ZoNkUb8FiONlF8aVi99k7s0qNpjvy/vkH+kKS5vzTnV9LPsdAqmM4r0jaINPlu3Q3HAqiWPuAp5Fhmy5nv7wZrhAhZB5IpTPvjoyN9xGli0jE/RDpQR8RNepoA3EQLWI7vvA0hzzOMNUGAXmlSw7R1/C1H3Qn7euRYY0X/CZBeWoNC86YK/KBSiWYwp8Y/bl8S5ImXcHGs648UVuHXVZRtMqu5mNcfNFGRyQhU/G9N4C1aiJEy9Gmszw8LAy1oo1KglbWRSiukzLiawfW/enuwgw3FgiuljBMo/rgBsu683ZKvO65st6o3Z3Kf8BtcNv55YtTqm4FC7YqwJC5Ziv Eel0q6HY wKUx4SZi4DWHkeqpHzu+c7B0YKKiCNO8QOmaY+EXE8FZwphti0R0EIOhNHoK6z6jRLC1c7W2pP2zVdBglUR0vVHUAup6MOH7J/ddqVKPmVGK2UClW1ljJdvU2F/+lp25+jmtXua4IqIrgy38Sg15KvbaZOF0xmmBw6bm3PKwSAF/qGZuu3xnnMU9b4qHp1AABLYTS2iXNfIKO9Ysag7ZMrUeuExcPwCcwPXfWc0LeQSyCG6yQcN8aHnUSZqH78PqO+9ngS4g97s+fnx4VrE+wVf+0c+x+Vcwi6F7YDgnrBtm8IoHt8sBlyDZ9LEq0ljT1v53IFSXvx+yHg2XbRYqOg1PTfNHpYM/C05bu 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 Thu, May 18, 2023 at 2:43=E2=80=AFPM Dave Hansen = wrote: > > On 5/15/23 06:05, jeffxu@chromium.org wrote: > > +static inline int __arch_check_vma_pkey_for_write(struct vm_area_struc= t *vma) > > +{ > > + int pkey =3D 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? 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. 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 ? 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. Thanks -Jeff