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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2EAA5CDB482 for ; Wed, 18 Oct 2023 18:55:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229447AbjJRSzC (ORCPT ); Wed, 18 Oct 2023 14:55:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43914 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229441AbjJRSzB (ORCPT ); Wed, 18 Oct 2023 14:55:01 -0400 Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 82DC9118 for ; Wed, 18 Oct 2023 11:54:59 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id d75a77b69052e-41b813f0a29so51301cf.0 for ; Wed, 18 Oct 2023 11:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1697655298; x=1698260098; darn=vger.kernel.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=NFJlA+mQhi+0DERBwp78bB/+mqro8rSJvhQZ9F+v2NE=; b=WlSvcMi5F/jYXxVjjQcOVuG7FVY9JhBio0abDr6dtY+dGMzncWxQZdEqvyjdLwY3H5 mgSRekPrWheEXYi4QVxifQo8Z8b5FxJZX4fDGDhXv4Tv8OGRmSnFFAf8HoZceAyu5r63 J9k7UcPcoJgm4g8JjwCTAsoSkgVTa9J7OCIIK3G+XQrp8okByvd4G44x5Cntvz5V8Vgq ZYmUuQTUEhhOxagJPOZYcS3LbvLUJtxj7KL7Tz4KP2f4EWQK1U9/pZk5m/NAuWfoQg2i 5bLKP4tBEULzUa5+vGvAyBdxYUxjJa+ue2vgWmh4WBa9NQcelU9GLW7N50/6hxDU90kA H0yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697655298; x=1698260098; 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=NFJlA+mQhi+0DERBwp78bB/+mqro8rSJvhQZ9F+v2NE=; b=pVpBwqnjpIeP1GXSCggBFQW91nu8cU8z+cDzmAmK7YBNz4krS4d65wcWFZErkKWjrY BHSsHxbDaDh/E9exCNIR4499VN7Xi1JCbbpz4ZxTnzlj627fKYO1Q2RQVG2N/FjmAvhT tcxO3efIl0Gffdxbw0XPJHwyJ5JXtbEzQZ4HMm7gnEnN9LJ77Qlym/XLPbHUVCt6i65p kkYwRUndcmRi3f7o2eDxI3luhmYAedUSVOjlHcZ06ms7PjY9gOG7KqELS+kcQNwbWNR1 uTEyhWiFJ91nOrPYVYSu7EtjyixOXSjlzdZp+K3AfcYwsmiZToAYgOoESazs43j3+Y50 td+w== X-Gm-Message-State: AOJu0Yy5cbmPqM5G+nN4EOAqNC0oa1i0lxagZ1bvUF+I+PsYQhBCtz2I tluw5LdtMfv2xx9otUFrgJ1VLvIWTjH+E/tcpqL4VQ== X-Google-Smtp-Source: AGHT+IGjizzkFJ61gHRpVi03W6jxKFHsg7oR29EE+XHiKGg+Nd1AGPkE/bY4MhXNSrPSxo096Ldf5GQvn/xYA+BV/to= X-Received: by 2002:a05:622a:668a:b0:419:77b7:da5f with SMTP id hx10-20020a05622a668a00b0041977b7da5fmr39818qtb.11.1697655298459; Wed, 18 Oct 2023 11:54:58 -0700 (PDT) MIME-Version: 1.0 References: <20231016143828.647848-1-jeffxu@chromium.org> <55960.1697566804@cvs.openbsd.org> <95482.1697587015@cvs.openbsd.org> In-Reply-To: From: Jeff Xu Date: Wed, 18 Oct 2023 11:54:22 -0700 Message-ID: Subject: Re: [RFC PATCH v1 0/8] Introduce mseal() syscall To: Matthew Wilcox Cc: Theo de Raadt , Linus Torvalds , jeffxu@chromium.org, akpm@linux-foundation.org, keescook@chromium.org, sroettger@google.com, jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, jannh@google.com, 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 18, 2023 at 8:17=E2=80=AFAM Matthew Wilcox wrote: > > Let's start with the purpose. The point of mimmutable/mseal/whatever is > to fix the mapping of an address range to its underlying object, be it > a particular file mapping or anonymous memory. After the call succeeds, > it must not be possible to make any address in that virtual range point > into any other object. > > The secondary purpose is to lock down permissions on that range. > Possibly to fix them where they are, possibly to allow RW->RO transitions= . > > With those purposes in mind, you should be able to deduce for any syscall > or any madvise(), ... whether it should be allowed. > I got it. IMO: The approaches mimmutable() and mseal() took are different, but we all want to seal the memory from attackers and make the linux application safer. mimmutable() started with "none of updates to the sealed address is allowed once marked as immutable", this includes from within kernel space including driver, or any new syscalls. It is reasonable to me. mseal() starts with 4 syscalls from userspace, which is just a way (among m= any other ways) to demo what memory operation can be sealed, which happens to meet what Chome wants. This is an RFC, I appreciate your input. Best regards, -Jeff