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 BAFAAC77B7F for ; Tue, 16 May 2023 22:41:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 38E85900008; Tue, 16 May 2023 18:41:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 315FF900007; Tue, 16 May 2023 18:41:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 19160900008; Tue, 16 May 2023 18:41:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 02128900007 for ; Tue, 16 May 2023 18:41:45 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A5EF11C6D3C for ; Tue, 16 May 2023 22:41:45 +0000 (UTC) X-FDA: 80797591770.23.CAE21BD Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf23.hostedemail.com (Postfix) with ESMTP id CEFDC140014 for ; Tue, 16 May 2023 22:41:42 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SlYGxF8A; spf=pass (imf23.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.120 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=1684276903; 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=5Zvlr5VPAlTME3LBradBl4JK+a3V5dewnwQSN0YTkas=; b=P9x/hAkIL3fnAVZuzU5i69TOMKf8tg4ls3uXC1rqU4jjnqduN31aElk4Oy9wJYfN5vyCw5 5ILlR+MMH1/ymjHmHMTS6UM9f8effq32eavze71BAhLx3Hb+p7bCvEb8SgWmtVUQHr36Pq u5Ynlkhjv/2xc/wYdckPmhDomj7y4sw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684276903; a=rsa-sha256; cv=none; b=CVY3toa+o2R/YWlp1rZ//gJUm1Jyyycbm2O9RYIZdovHCDANVtLn30+2g0KoDVHqSh35v4 U1utlEurwO5oHZ9MS89N7dogMKbIExyIIEGosQYO9cYT2DWVRMA35grgKCybLvnOUqPecm Z5HnKCQqx9aB3eDZb1pSkcqTUbYF7xA= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SlYGxF8A; spf=pass (imf23.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.120 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=1684276902; x=1715812902; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=IDhBF4fgjJGRK2kGvqetdUuW5dTqUG9nUhpZg9K0OCo=; b=SlYGxF8A7nr+zb9r8dcxEtgtaPZJn7IIz065aAGahybSX877SZSz6097 kWRCsQ15rJAQbOGllgPFgXgcEkAzfZ2RuRc4Tyd/YVlEA+NlpIHEebkIa o+0bNzjCalcARjVKW9xZsMig9tm7kzx60FPiRnWwFOfhRM41n6/kI2IuP Of6bQqw0xS+Jr7fxNUir9UwCD7yq7rhG438P7o1FoMvggpEC/SRYvZEDE 9HxJytBqCyFsMNzoA84LGYVjyz6Tf2GeXtUYi6hwjScC4tRAn4VmurK08 bf+oHPPZfsZ0EWo/VwdPhb3LoVba/WpO0Pwa96czIDTU3Lk2shlbXV00n g==; X-IronPort-AV: E=McAfee;i="6600,9927,10712"; a="350447271" X-IronPort-AV: E=Sophos;i="5.99,280,1677571200"; d="scan'208";a="350447271" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2023 15:41:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10712"; a="766534490" X-IronPort-AV: E=Sophos;i="5.99,280,1677571200"; d="scan'208";a="766534490" Received: from mtpanu-mobl1.amr.corp.intel.com (HELO [10.212.203.6]) ([10.212.203.6]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2023 15:41:40 -0700 Message-ID: Date: Tue, 16 May 2023 15:41:39 -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: =?UTF-8?Q?Stephen_R=c3=b6ttger?= Cc: jeffxu@chromium.org, luto@kernel.org, jorgelo@chromium.org, keescook@chromium.org, groeck@chromium.org, jannh@google.com, 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> <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: CEFDC140014 X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: zobexrdqh7jbtq5ra1ct3ewzioozd7hn X-HE-Tag: 1684276902-281989 X-HE-Meta: U2FsdGVkX1/tRsIZ2Fq9JyHvpdUtqqpWyM7d7yoA2AFd0aDTB5+Pdri2vTdWAQuZNQMf+Bknbouhgw4mJzQwe7P9kdpCbJm2C25hvaB9L053TMiMNdNs4jpUWqnrOL9dYQxsm6xIoItA3zQmdAJF1H8yKiLg6591aoZdcjWlmvCV8fnI5YcTt9k2dRCARrTXH8T0aRGoJAYKIM5KIJAzAnPfKTjYadsxqMzxCDh+Ln+H8esg7jStSJfx92bTcbYCbfoEZd5ComlkYyW43cdoEI7FkXjV7xYUN9AXDdmzUrMxVju6hOz26z2PTGGOUKoLObtJ1slT5mzFG30z13UsuQ/MASrLYwicY8zSXpNj0j3fBURuGrUCaqRd6zglx7NAa2Gqs4y2HLKcKBPIPBkYBP3oS0ra+bCA7oRshIdxHcSQxjm2rZd+UU3trNOlCHKrp1zYkllYxWpRjXkdJwMeYsZyDioRrLQoRE7MNvSANOR7vDB6dB7vh545ccpUVvZAXYYxB5V44Il8YrZE6GSGTI1nJJQPsA52LISYqaoQIAOeYUOAeLiv1C50BvpCFMJUSa9ejymv3EW/VSwt5WEG5rnP3n0JD1ihgpEmjPY/tVXz5IbfVoysNRcoORXW6geo/L4Pjc4h631twjnb2l81AaIpw25IaZnZ8hBdpSKtGDb2sksAPNdi/CmCMVVzChAlZcuWmQfrcSi2q4Rur5MEyU7F/JFn5C/vDKQR8cu7e2nbCIxe367Mb3nWer38bP9tFTgiQMm9mASc/DNG4LsAtDGboa9hYfG8AROt1hQTzgZ9WcqucR3HH4HJUchsQ5pLihau3VeGJ3t9Dkl75cuFFzbDLYrmS6d5nR8LY4/iZ/wgjV6vLhPfDtjZuLky4Z9hF3CQWaoHnKtua3Zz2UNLnXSLO/UeXKc7kVpWU5OZBNAbRu1k8RjohmH/bIRjpscQa5UZYj3EURSf6ES2y17 r7JhniYy EraDfuHK6x2iZ4Ec2favDnUA2XBUHVoTlp40P4ZAEX/72qGGZ8iejR2E9J+2hKsIsNLgIrPco1x3b5UFmpbR5hdwqP+Oz9u1BU5MonGyxHhbhegh1IKsFX3STF9zW7C1tVS1xg0Y5drJ2o+xtlA2su5sPnq5X6C0OHOa7KzdkVIggq/zO//8TgvJeii2ROdljS4+TV506pkyD8fDYzhn56bbZg0jXvgjIHGvS 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/16/23 00:06, Stephen Röttger wrote: > On Mon, May 15, 2023 at 4:28 PM Dave Hansen wrote: >> >> On 5/15/23 06:05, jeffxu@chromium.org wrote: >>> We're using PKU for in-process isolation to enforce control-flow integrity >>> for a JIT compiler. In our threat model, an attacker exploits a >>> vulnerability and has arbitrary read/write access to the whole process >>> space concurrently to other threads being executed. This attacker can >>> manipulate some arguments to syscalls from some threads. >> >> This all sounds like it hinges on the contents of PKRU in the attacker >> thread. >> >> Could you talk a bit about how the attacker is prevented from running >> WRPKRU, XRSTOR or compelling the kernel to write to PKRU like at sigreturn? > > (resending without html) > > Since we're using the feature for control-flow integrity, we assume > the control-flow is still intact at this point. I.e. the attacker > thread can't run arbitrary instructions. Can't run arbitrary instructions, but can make (pretty) arbitrary syscalls? > * For JIT code, we're going to scan it for wrpkru instructions before > writing it to executable memory ... and XRSTOR, right? > * For regular code, we only use wrpkru around short critical sections > to temporarily enable write access > > Sigreturn is a separate problem that we hope to solve by adding pkey > support to sigaltstack What kind of support were you planning to add? I was thinking that an attacker with arbitrary write access would wait until PKRU was on the userspace stack and *JUST* before the kernel sigreturn code restores it to write a malicious value. It could presumably do this with some asynchronous mechanism so that even if there was only one attacker thread, it could change its own value. Also, the kernel side respect for PKRU is ... well ... rather weak. It's a best effort and if we *happen* to be in a kernel context where PKRU is relevant, we can try to respect PKRU. But there are a whole bunch of things like get_user_pages_remote() that just plain don't have PKRU available and can't respect it at all. I think io_uring also greatly expanded how common "remote" access to process memory is. So, overall, I'm thrilled to see another potential user for pkeys. It sounds like there's an actual user lined up here, which would be wonderful. But, I also want to make sure we don't go to the trouble to build something that doesn't actually present meaningful, durable obstacles to an attacker. I also haven't more than glanced at the code.