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 8B550CDB47E for ; Wed, 18 Oct 2023 15:09:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 11D068D015C; Wed, 18 Oct 2023 11:09:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0CCCD8D0016; Wed, 18 Oct 2023 11:09:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EFE328D015C; Wed, 18 Oct 2023 11:09:29 -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 E11FC8D0016 for ; Wed, 18 Oct 2023 11:09:29 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B03D6C0367 for ; Wed, 18 Oct 2023 15:09:29 +0000 (UTC) X-FDA: 81358916058.09.923C053 Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) by imf15.hostedemail.com (Postfix) with ESMTP id D744CA0035 for ; Wed, 18 Oct 2023 15:09:27 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=EMgnOohe; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of jeffxu@google.com designates 209.85.160.182 as permitted sender) smtp.mailfrom=jeffxu@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697641767; a=rsa-sha256; cv=none; b=n++T/4WJLSXQe3DnDh0cCVvdJyvmHRFwI/lID3+TL7XWDOqxo6aAmKvEnIljNR9zRjy/LL d/79AhNpsr4/o8V6ZOLvBZFV7vvitPZZYqedxZJPKsRGXvB5cIdgdm+SWbDfWXOiqFu78/ +6VJ8ev14PIpPwK8/4tAEO/assQeAvo= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=EMgnOohe; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of jeffxu@google.com designates 209.85.160.182 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=1697641767; 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=PvfWp1C5xv3xuTQ6WUqjUh4zSLJkkTSPfVE2loOXpbY=; b=z0aJSwYw/VVhE59j++8O0N+aGO39VsZNttFiIP3hfjNqomofQs0FEhPt95dPkEmjrxaKud IEeYLLgNc3sDjuiwT0LDk6jFmkO1YVHp3eZWofHIVtbl4v1UpNMwOjTyiDxRPYvId2gOOC Jj1MTs2s7KOXL7q/yRQST+CkzsRBEdw= Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-41b19dda4c6so254371cf.1 for ; Wed, 18 Oct 2023 08:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1697641767; x=1698246567; darn=kvack.org; 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=PvfWp1C5xv3xuTQ6WUqjUh4zSLJkkTSPfVE2loOXpbY=; b=EMgnOoheDgp2KxalHSp/t+WqqUh7jp+mCufd6sfOstdB3FM82CyuiG619nhBmPQqd2 jtPMXleTUC3Ub3bJWV0lhmqZdJxWEkaQ46gsu8Q2loVoUu641uEhqz3NWCUxzphPMcPL CYbas3jcWu1s+gK5Yc9QH5IFCnVaBYS3YJo41EtKoskDwSR/9Znf7CncgPvlH4ZJC1AC C6w7mTs4KW6VpSb4GBoS1lOleS6lbXcnRfzYO5ulByUO4YiOmj4J64nb8NQMr0gRqF06 EBuOL/9bU4bYtiuSD/QU86rjn/8d11subim9TbZ5lZ8QXaZ2KxpmVabfrcNrzhESAAIM kPXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697641767; x=1698246567; 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=PvfWp1C5xv3xuTQ6WUqjUh4zSLJkkTSPfVE2loOXpbY=; b=QirPLto6GDBEIVORPn3hXvoIZqDiHpcJpF7EXsbjh/mTsOsbFrucvUE/v4HxkfABa3 XaNoXHt6RWI5gVI+jK2rgolSdykuCwSh601guOPyevf7J93gWMitFezal4k6Jd3iEkRF fTz1fnWrADBuIzoNch48vitws26wxmG0y48rAREGE8j+PRrXmdCnbVetVlaK64v+kCdn KzKzFv6versJnP3E8LZSCydtVaItkAP3i+T8nD93DYeatf5SYjqRChkc1YPJT80Ztgfm umBKbvLelGUrK8yLpCIsGHlEDERxv9Fk7fRgK0O5qGFtbBNivv6sxgWmEmSmWeJP5Z/p +dng== X-Gm-Message-State: AOJu0Yzt8PBM8af2sIiDJWo0/ZeeM+GwG8MHDneVjrzYR40U9D3SxGfL /Wv1O4gpZRgwJQxxxMLQVQCuBvt9/OeEa1cpA0Mzew== X-Google-Smtp-Source: AGHT+IFgbm8y7iUUT1tE/b9dwff4sTV8f+SQuOOmoj4EcmFYIHZ0gjVlcjmYUYdkCnzE862dRzyTETqhK35IYA7Fv4k= X-Received: by 2002:ac8:4b75:0:b0:410:9d31:68cd with SMTP id g21-20020ac84b75000000b004109d3168cdmr221871qts.27.1697641766704; Wed, 18 Oct 2023 08:09:26 -0700 (PDT) MIME-Version: 1.0 References: <20231017090815.1067790-1-jeffxu@chromium.org> <20231017090815.1067790-6-jeffxu@chromium.org> In-Reply-To: From: Jeff Xu Date: Wed, 18 Oct 2023 08:08:49 -0700 Message-ID: Subject: Re: [RFC PATCH v2 5/8] mseal: Check seal flag for munmap(2) To: Linus Torvalds Cc: jeffxu@chromium.org, akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.org, jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, surenb@google.com, alex.sierra@amd.com, apopple@nvidia.com, aneesh.kumar@linux.ibm.com, axelrasmussen@google.com, ben@decadent.org.uk, catalin.marinas@arm.com, david@redhat.com, dwmw@amazon.co.uk, ying.huang@intel.com, hughd@google.com, joey.gouly@arm.com, corbet@lwn.net, wangkefeng.wang@huawei.com, Liam.Howlett@oracle.com, lstoakes@gmail.com, mawupeng1@huawei.com, linmiaohe@huawei.com, namit@vmware.com, peterx@redhat.com, peterz@infradead.org, ryan.roberts@arm.com, shr@devkernel.io, vbabka@suse.cz, xiujianfeng@huawei.com, yu.ma@intel.com, zhangpeng362@huawei.com, dave.hansen@intel.com, luto@kernel.org, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D744CA0035 X-Stat-Signature: aajmdggkuh3ys1ztg7btih64igpixdns X-HE-Tag: 1697641767-24682 X-HE-Meta: U2FsdGVkX1+oMMko6a2P6lGjrVuB1vRq5VpBuJCn1KN+92b2E5PU197GSElBzZ7TwD/4TzV99WByGAdnSNNUa4Hf+xNXA1ZyK9ZeSQflsAmUiWZBDvI3hOGosz9duZL3hpWDuMRIGRETShSnBIqWR4RFOwsRhPrn6+Y+gVy47uW67LDwM6B3rWMq/eF927fErvYGWTKzypjOj2yv86Jpx9QQBecmHt+HKYily7pFBIAYaKem3Bez7m9OTL+ReJw6GU1PUNLbsjgOZRlHLUhgwUpR+BibJieOatqMfOiNnGR+i4T4FgGEMidvwJ+cPoXFLfFOqFPE/IRG917P6IY9GkfAD6SPFOdzmm02nSKykoPtMdYmiy8grtCAIc6w+bVB8S94H7ukpX58dpsicCd+oT98REE6D5FDb9rLPrlsnwNARVLTCe4RwOLMgluF9z6lpcPfyEYfQOoHym/MVxdCPkh1tl671gKXUI1gA7iuPgVMcJCBM4bKqn6LJK1bT5tI9cXdysxEy/5QHzqpP78JKoDlOJdhrFm0oZAALIUOvIbQ3QhvAXsausFqOq8RG+Nna07dAAq6D/qKwJ2IBdVpRgpgYjJ1HLRgPFmFPlEIiCxM+f0P6OtayyZrSeUwb2xfdP4UvSJgSWL3AlLMdhbxah50FRGauLYtE3JMrPuihKFN9oo2K5D3ohbJrrVcpBeSdk9wCxkRjsY19B7NnCb5bOcihkiKt4djQXBi6RDJRSakDSHDTQ0cp8R1vkhkiTY6eSF9ZRqKk28Mlh0rZJ6n6gBf4dzxLnll2By9OxyRgXshlEGIn/DNwyh5CnPr46BHt2VPsjktkBG1JJSvIzakiRo5yZ8XT2D47mxh/06vEnJhQ+5f3D+w3yJ3cve5Kprv0IX+hdrOHY2RelDrqD51GKyo7jgftfaFl0bpE2oSvmuQcfNStgV8PhN1hsmfvtwbuYkbTZooUG8kGQKrtpe 2/MAl5fQ wDy6ZMsKP6K+UhbNxBVju5X/kxjuihZSGyRFzQOxJFgDoniCll0mr/z1b+fpsjqv4R1hDaoWQS1wbXjvloqU81GooogR3ijrcoPXOlJjX5LboV8YGALlslZCvEoGtnS62NyoK1k72EmZAuO7N+SoAhpt6mGlIlHVNRtpSY0mb20Epcu8z46Y0V21zjUQn+INvFFm2Ov0v1sPa/7dILKuMqlapyHbPcYqEGI0v+ihbsN/2hjJZbIMFZdDorNzErXBIiJkr/WpzLRinJ/gbFJzuQ0WZxwCUTKJXQClJx18+g48A1or73PyGWuIcl9RGHODrRJjivD+rFW07BtU9HLkG+x6FSznsbryHcWdxxmUR14oqyJFSJer23GfcOyIPM69LL4G74Vg6SDDJki7YbIX47Vrm4w== 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 Tue, Oct 17, 2023 at 9:54=E2=80=AFAM Linus Torvalds wrote: > > On Tue, 17 Oct 2023 at 02:08, wrote: > > > > Of all the call paths that call into do_vmi_munmap(), > > this is the only place where checkSeals =3D MM_SEAL_MUNMAP. > > The rest has checkSeals =3D 0. > > Why? > > None of this makes sense. > > So you say "we can't munmap in this *one* place, but all others ignore > the sealing". > I apologize that previously, I described what this code does, and not reaso= ning. In our threat model, as Stephen R=C3=B6ttger point out in [1], and I quote: V8 exploits typically follow a similar pattern: an initial bug leads to memory corruption but often the initial corruption is limited and the attacker has to find a way to arbitrarily read/write in the whole address space. The memory correction is in the user space process, e.g. Chrome. Attackers will try to modify permission of the memory, by calling mprotect, or munmap then mmap to the same address but with different permission, etc. Sealing blocks mprotect/munmap/mremap/mmap call from the user space process, e.g. Chrome. At time of handling those 4 syscalls, we need to check the seal ( can_modify_mm), this requires locking the VMA ( mmap_write_lock_killable), and ideally, after validating the syscall input. The reasonable place for can_modify_mm() is from utility functions, such as do_mmap(), do_vmi_munmap(), etc. However, there is no guarantee that do_mmap() and do_vmi_munmap() are only reachable from mprotect/munmap/mremap/mmap syscall entry point (SYSCALL_DEFINE_XX). In theory, the kernel can call those in other scenarios, and some of them can be perfectly legit. Those other scenarios are not covered by our threat model at this time. Therefore, we need a flag, passed from the SYSCALL_DEFINE_XX entry , down to can_modify_mm(), to differentiate those other scenarios. Now, back to code, it did some optimization, i.e. doesn't pass the flag from SYSCALL_DEFINE_XX in all cases. If SYSCALL_DEFINE_XX calls do_a, and do_a has only one caller, I will set the flag in do_a, instead of SYSCALL_DEFINE_XX. Doing this reduces the size of the patchset, but it also makes the code less readable indeed. I could remove this optimization in V3. I welcome suggestions to improve readability on this. When handing the mmap/munmap/mremap/mmap, once the code passed can_modify_mm(), it means the memory area is not sealed, if the code continues to call the other utility functions, we don't need to check the seal again. This is the case for mremap(), the seal of src address and dest address (when applicable) are checked first, later when the code calls do_vmi_munmap(), it no longer needs to check the seal again. [1] https://v8.dev/blog/control-flow-integrity -Jeff