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 E1CF8C77B7D for ; Wed, 17 May 2023 15:22:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3ED3E900004; Wed, 17 May 2023 11:22:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3758E900003; Wed, 17 May 2023 11:22:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 21624900004; Wed, 17 May 2023 11:22:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 12DBD900003 for ; Wed, 17 May 2023 11:22:06 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C5C52ADE3E for ; Wed, 17 May 2023 15:22:05 +0000 (UTC) X-FDA: 80800112610.21.E94F53A Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by imf27.hostedemail.com (Postfix) with ESMTP id E4B4440010 for ; Wed, 17 May 2023 15:22:02 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=eAbUHob0; spf=pass (imf27.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=jeffxu@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684336923; 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=HphpZG1cfp4ZuEeq32BSNbxONoUw/U/BOfxh6PlDKrI=; b=onfNQjGOW4SAOrulQZwhjLaYXiFeWsQXdYvMHovJriDf0XZQekS0f+9+9eOHR575g41DyU xXpRtrn+lnhc5dt8AE5+JnMzqYmv9UlvXRgwhmLfESu1mZgSoJ7GgGdhcW+KNx2lutDjvy WI02wf1MvMBgpyHooCkaeK6yWk18/Wg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684336923; a=rsa-sha256; cv=none; b=YffnCf2xOqYzoyEOW+YMjhKUAjn78KtmcucCKMjRy7S59VMiWmxGpd67UB3a46iDRQqTto d28qu0+jHep+v16B76YlGPadEVXOpSJ9HfeR8PRlat61O6D2q/hFGBXpv/wqCFcDDdO43A OfQ87/ZadyliAFvNVlvMQEitQsOeEss= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=eAbUHob0; spf=pass (imf27.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=jeffxu@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-50dba8a52dcso7110a12.0 for ; Wed, 17 May 2023 08:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684336921; x=1686928921; 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=HphpZG1cfp4ZuEeq32BSNbxONoUw/U/BOfxh6PlDKrI=; b=eAbUHob0fvSN+keUC4LH8COrh2z6bi/dUGViO2F8YhgafASrYUyJhiI1nnoxS4F0u4 oOfvp6HZwnW+7ZfQ2maR569eeTSTLJqZDlCfUMGU6qnqnDBNZpvxvn+l3qLbZ3DaHhdb a55sDMdXNOWilq21OpS2MBescQVd1sIMEM17wvmciHj0af+PfkCl85wEyMoh5aFLrajy DcGHkMp6BYdqoPD2RcQfHhWkgxWez0NVDti2+0XbaXRdjsOLPa4nnRP2WQAoOpQJImS5 weEUDQRHGB6LPTpDTSs8ROoEpiKzYsac6RzNDnYZsGsvgTG5tIfLmcHbQeuoEEoZ1Pos U/qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684336921; x=1686928921; 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=HphpZG1cfp4ZuEeq32BSNbxONoUw/U/BOfxh6PlDKrI=; b=jNhVv0PInEnJMzsnsmcSRBiDsoUCHhpHD2Q6pAHKbb2WScvKjpkWB67j97ZhVKIYJH WzDmyO7qSXIrIQ0KKhqnWnRbw0lm7gxvI0ABw0nj8fiKHit3eNgClXj1PJ+zx3DsxaZf kg3JpBMco9UhwVOKdvcMFCZRT3oWruxlBsv8vXwuCzm/f5mWNL/BOFe4dAGRYbouL24i 8r5nxlQGSQQVM0p3Roxf/C+hPWNQuJQdGP5tEIdBR0IRahp6J4lmd724dpIcw6iHSKKH J1ubYMU1qd/vIz89jTc5BlsI7fQVlRTBpSmlILp6B9gUkwHgZwaffxSmSUaV/MGzwoDa XCqg== X-Gm-Message-State: AC+VfDxh1ltIGztEb6oKGipxOa+p5Ufx4gI+oMsxiW10EGiv0uJiGh2f Q/IHvMs73DM+1wHkN/JtVtJ1uiIZ49t00qxAaGg8Mw== X-Google-Smtp-Source: ACHHUZ4G7d3trM79A9+Z27qD8TGxLp9bh/6bY2sGZ9ppET4JtI3nyUXUpn97bcd2BZ3TlAms6Z2VtD3tYpahhrHXcQw= X-Received: by 2002:a50:aadd:0:b0:50b:f6ce:2f3d with SMTP id r29-20020a50aadd000000b0050bf6ce2f3dmr142899edc.0.1684336921213; Wed, 17 May 2023 08:22:01 -0700 (PDT) MIME-Version: 1.0 References: <20230515130553.2311248-1-jeffxu@chromium.org> <2bcffc9f-9244-0362-2da9-ece230055320@intel.com> In-Reply-To: From: Jeff Xu Date: Wed, 17 May 2023 08:21:23 -0700 Message-ID: Subject: Re: [PATCH 0/6] Memory Mapping (VMA) protection using PKU - set 1 To: Dave Hansen 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: E4B4440010 X-Stat-Signature: 874ngajmboq3o4hdzc5oxoei8dfoamg4 X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1684336922-292759 X-HE-Meta: U2FsdGVkX1+26Z9Tzym1NUQJ5pcQ7vuiO0igQq7GyupD6pmrBznR/o+iT4F/YWMNfD8HzhJXX+xs+wvpccEsT21SJn9mHFg3Odj0th4IjchfIrHKTs8XTPtizGfa/E8kHi+xkMOGj+AfxfRzxgZJKrG62Q/BOWuFrpd9Nl9xQ2ursLGO0j3P9YrQr0+gXdyinQ7qVh1zVgCw8DJ2tsGaOv69RbnO8N36X8KTxg53/lKQdADcJqP1Ioj99eFjx662phADBTeuGMDBrcHvlvZrQQ/aVooidq+FT+kCdVDb7vNAt4CM0L68Z4ZoVM1V3rmedEFqJa/iyU0480bSbrW9umcBVLuGTyuJDDBvzZ/UemlYSxxW7Qo7SlrSp/POUV3eArD3JFk98dppG1eDmJOj6UwpqYn7DoHLWoexP++ahSdKlHc/29nUvFaq0vDb6dxfIPNqoy8fdW5nCDM7TU/mv6Kyub6O5YsWehOih5XqrtZOXIHop0RymEmsOVcA3qEz1+BVD8dGVGkXCzHEndH7uSG0aYavLBkA0DPHVEKSUs3DyiyWkHy0o6RB0AJu4VEEUWCU52KaFvwNh3EmXKykkGQ41Dw/eqMt2LaaqeZNcFZ5OvJIllr5JDVcaJN2oJLTQylZAvKvdornfV/wSfcU/eVMO+2NvbZ9Q4NQRaDdoH2O8iYeFVgtV51PTZExJnNqiJCmIyuseVrY6ScavC1BKJhwIjMoIyHA7LJ4I+S0E7hG8C8MHtLx3dvsWh1TqhQJ6HXgvsjkmNvT2UYrYPhR4s74JanJrbCZ60pxVjwLDkE/adn9AFF1cCXAoyfpEr9e8CizvzU7L0pxd2gcXrloTashOXC6Z3KFyInZ1wpZEE6wVHbIOoaRab6C5ZKrnNOfMjTiNCdgKoqPLz1xxv4kw27pgV03QOFXvPeUlZa2ZicQ6cPrj/F4sM0PTX4L68x9HmfMBfMCwuTvN/lVSTz aW1aupn/ 9BoAuGroM+rJD9zAqaKuyvagxeY5Tk01YxVjGWemD525ZryoQTVQ3Mk3hHC9jUG1a3tnnTEaHASdg4sWAO9nx5/DyD1V1W8141ESYIwmNHdNsej0iTR+yWRoW51kZlQDvfja5Uu6l9ubgbYQicbAgsuAPq78/E9ZvjoprYKjmGX3ArS5oeA/vwL0InyXndZ7fPng6ACAP9QCbZLudNTYvWfNKQrVZPLFxFZJXjBqAcduUXVpPUN8DYDbR9g== 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 Wed, May 17, 2023 at 8:07=E2=80=AFAM Dave Hansen = wrote: > > On 5/17/23 03:51, Stephen R=C3=B6ttger wrote: > > On Wed, May 17, 2023 at 12:41=E2=80=AFAM Dave Hansen wrote: > >> Can't run arbitrary instructions, but can make (pretty) arbitrary sysc= alls? > > > > The threat model is that the attacker has arbitrary read/write, while o= ther > > threads run in parallel. So whenever a regular thread performs a syscal= l and > > takes a syscall argument from memory, we assume that argument can be at= tacker > > controlled. > > Unfortunately, the line is a bit blurry which syscalls / syscall argume= nts we > > need to assume to be attacker controlled. > > Ahh, OK. So, it's not that the *attacker* can make arbitrary syscalls. > It's that the attacker might leverage its arbitrary write to trick a > victim thread into turning what would otherwise be a good syscall into a > bad one with attacker-controlled content. > > I guess that makes the readv/writev-style of things a bad idea in this > environment. > > >>> 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? > > > > We=E2=80=99d like to allow registering pkey-tagged memory as a sigaltst= ack. This would > > allow the signal handler to run isolated from other threads. Right now,= the > > main reason this doesn=E2=80=99t work is that the kernel would need to = change the pkru > > state before storing the register state on the stack. > > > >> 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. > > > > I=E2=80=99m not sure I follow the details, can you give an example of a= n asynchronous > > mechanism to do this? E.g. would this be the kernel writing to the memo= ry 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 ? Thanks -Jeff