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 7EC04C77B7A for ; Wed, 17 May 2023 15:29:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F0C33900004; Wed, 17 May 2023 11:29:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EBC19900003; Wed, 17 May 2023 11:29:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DAB08900004; Wed, 17 May 2023 11:29:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CE786900003 for ; Wed, 17 May 2023 11:29:52 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 9171DA0657 for ; Wed, 17 May 2023 15:29:52 +0000 (UTC) X-FDA: 80800132224.27.5AEC3E8 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf02.hostedemail.com (Postfix) with ESMTP id 9A7EC80010 for ; Wed, 17 May 2023 15:29:49 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Bc+USvh1; spf=pass (imf02.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.93 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=1684337390; 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=KDm6SS8dafehl0JiQkfaHbx/8Lt4OV4WNnaeJtIvQyg=; b=Pc7O66s0yEH02KnKCTLX9FFcSH+e68Be8DGs/ny+F1vZP5vogmuM6Ii2mqtvqyLDVWvm9z YD3j1km4HglROPeiSl0m/iW8ckbdpttFy5UthiMXQD5IYF6eT1CLBPw7BpTJXbvwDYLUpE Kge11PK0SFhp5bIY2z1h1a+DOoO8ezA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684337390; a=rsa-sha256; cv=none; b=RXPe28PAm2QE/bjhk5Ua2r4Tt8GoqRwAKiOmk/ZbIIMuwhINdTJEuDvSMH5oo4qMGWusu/ gpZ+MqB4OTdY4HEvbEzUKVaUD3Z4pXrrNl/LWhx+pH7ZtbNh6yfuuNC085GhzDc6TWJDUK hRMaSCEHmYZjZYokVuMckNBM7J3koQI= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Bc+USvh1; spf=pass (imf02.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.93 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=1684337389; x=1715873389; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=s7w7liuVQK6OILCFceYzFS73/MrLg8U8eXJ3628P3TM=; b=Bc+USvh1KQRiGE6xeMo6aQwvoniQ2ZMtDeYBNirHM4X0oROPtycCGCvh wPTWfoXWsn52nXvW3xVNI5bQsgJzc6kAhvmq8ZTvM9K6g7jIQ6DpUg/4s DJ0Ud6TrsLAIjy1L62R4O3PCx+aaDaOcyGZenrGwgd/HyKi7Wu1pcScbB 9RUzQ1eP5CcR3OB+CesaVl0ZPoLZ3ByO/9GXWsTzS6aLUps5HsV3YyMsv cDwEHgIqwgAug7AWR8BCDSbwdxvETDoucS6EmavG1iG58m92H+0JQiu6C HmIiNgiy+ixQoN2rjHj5jHAQ3SbXsMMQPLXC4P0LyFv2Qj71HkvAjUSyc w==; X-IronPort-AV: E=McAfee;i="6600,9927,10713"; a="349294761" X-IronPort-AV: E=Sophos;i="5.99,282,1677571200"; d="scan'208";a="349294761" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 May 2023 08:29:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10713"; a="695907865" X-IronPort-AV: E=Sophos;i="5.99,282,1677571200"; d="scan'208";a="695907865" Received: from cbrown-mobl1.amr.corp.intel.com (HELO [10.212.129.207]) ([10.212.129.207]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 May 2023 08:29:47 -0700 Message-ID: Date: Wed, 17 May 2023 08:29:47 -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: 8bit X-Rspamd-Queue-Id: 9A7EC80010 X-Stat-Signature: einda4kidx7jo6hmwg847ue7beuf9bup X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1684337389-854411 X-HE-Meta: U2FsdGVkX1/rLKRsqVtsJTiw/OvfKqmdGV+dR66HjgGHfs99jguZyLvHKENa6lttwFac4LJmmsxPsLYMkB1ZaAYspyj/yDXO85IYOTS0s/MPcl9qDh0+85Z+fxqbu3hEPEux5u8yxYPZ9tDbPWK0F83Ph3RVY02XhfRVXOebTXZr0qz8S0vEoND6COLSA2m+8THZt30T1+zh/4ah9HfT1C7ex7dY1sys4Zo7m5dZSqVJkFaKdkO57zAIxCUjgjYm8OaMS7qMgsVbXEWlNPcRI87FjGzZrPAm57hd0tkQK978xhp2k3yb9sFpQAuLZT0TqQe4HytxVHungseccz3V8vFTvtdYgvmfImSv4YSThPkiStaaJd9WBVTP2XdjjJotTPEMmABsWrqIIUyxjCoPZd0KKuDgBMcy9aSUArQhQWEim67w6XRt72z0E32QeRZlv5tC2xk4+tOlOepB/BS3mF4jX3MUj+dZ8vi+QhqcZA59TscDZIrdmT7DokuxRAvjQCijLSCFW53t9t4GauWCwtICPQN13JzBg/FOB9datKoTaw+4SXtbB/v1NX/keIiNWBl0+PZNEs9zpG+aKJ6Vuln3EfugIAnq6WNWOyqGAQqSj8GKAwzxN+Y/DIYeJXuKmqqr6sQF7yzA/cayScMkx5L/v3Sitp4xSAHs9nHOZQcsSU5l17iDGkGwq3udWZ84Pwxmf89p7ff2bHfEPtM93x3vVLhNYr+YBg1AhM/uBO2ako2VETv8xwqVksXTPX3t9SLU94j714gyuOFCaQHt7Qxk4txQAX27ocYYYJ6jE9/JovNLLgev0B4001cl3u75JKzkeAw8k+PAIOfWFm4eEiYj9T/u2UQb71MJtfollMo5wTPySPrOw8M4YGYgn+9Mwh4PYcaAszIKTlApD040todCXUTJGEu6ImeFrZzqeek8GRrLfKo3oV2XobPAI/ViD7rlmIpTmym+RUdkAcu q5BVHyFB GdId5TTMRiPc4xVXEqlqRc4EG5rJRrWECozYfLCvnccjGn7EhFf0sufjnRA7K+IcEf+KcQ4D9LDvu/XKRPJ45rXpPIyiDwTPYeDT51AV9YZupwilMa+bsTrxPRdOxP5whsLiWNGholSuC6xs= 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 08:21, Jeff Xu wrote: >>> I’m not sure I follow the details, can you give an example of an asynchronous >>> mechanism to do this? E.g. would this be the kernel writing to the memory in a >>> syscall for example? >> I was thinking of all of the IORING_OP_*'s that can write to memory or >> aio(7). > IORING is challenging from security perspectives, for now, it is > disabled in ChromeOS. Though I'm not sure how aio is related ? Let's say you're the attacking thread and you're the *only* attacking thread. You have three things at your disposal: 1. A benign thread doing aio_read() 2. An arbitrary write primitive 3. You can send signals to yourself 4. You can calculate where your signal stack will be You calculate the address of PKRU on the future signal stack. You then leverage the otherwise benign aio_write() to write a 0 to that PKRU location. Then, send a signal to yourself. The attacker's PKRU value will be written to the stack. If you can time it right, the AIO will complete while the signal handler is in progress and PKRU is on the stack. On sigreturn, the kernel restores the aio_read()-placed, attacker-provided PKRU value. Now the attacker has PKRU==0. It effectively build a WRPKRU primitive out of those other pieces.