Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp6045938rdb; Thu, 14 Dec 2023 07:04:52 -0800 (PST) X-Google-Smtp-Source: AGHT+IEz6indSkBoo/1xz1++FEVFQkK7TCM8RO7LflBBzasbjAGEvPDBN2LGU8ZHn6VG2AKDQSQH X-Received: by 2002:a05:6300:808c:b0:191:e72c:24d0 with SMTP id ap12-20020a056300808c00b00191e72c24d0mr2814149pzc.9.1702566292137; Thu, 14 Dec 2023 07:04:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702566292; cv=none; d=google.com; s=arc-20160816; b=EcqVBnJ9iSaKpkmLF1H1CMEP2M4rF88sqZcNQ3sre+PXSOU6yRqPqe93SgfOu2H/hO r9SUtwpJToKz2iEHdVq95meMjfYqcBtF0t4+CvVa43/eXPr01pah+YH8oW3ac60Vf2zj G0OBWPSK4eHojBJkEx5D+x94H74pr6XlJ/bVuvw+yeHgfIxOq8r0IwYbPA8KsiCoWmGd rkJGpSjk33EuFe5+u8zi9peeTAi2n+zv+EBPwtLgiOdYDn+j2uDoVhgpU/GJiP2t9St0 qMSSGu/S+zAq6BBhGDHm4cTIMndySIpBsY1pOWwYYDZRi5N/eTOK706vfx+nya0cwxnV mEow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:content-id:mime-version:comments :references:in-reply-to:subject:cc:to:from:dkim-signature; bh=gknNQKGWicqnPtTyVrZrbLAwR3hIDB1ayLRPXlU++D4=; fh=5kvza0GUGju7Txpf7xXTT8LXQMsSKONSVee7GfgWsuc=; b=VVkq2aTDNK7FmWHhsFaRaH2c7JsiiOwiRlyx0p0Qe/LLGgRFCcVk9mJm42Qp0sW3sb C0G+8z+x+XAJBGklOCM+9buiHtwdzxEuXhIlt36kqYMYj2luM5/Pc01UsnRvl+K7aW+L gr+Aor1wHzmounahASSebscDsIzHxD19LP3+N4RYfpHVRR0s+gdT7UToe7UPbsn+X8VO NO2G4MkO9BWLznUXbNXi3U6ecueN0Z1qoWZkyiuNdxzO9RuH7EOdVzPci/Mc25shzK+2 8lZDrCxqwrgI2EqpDfrABtczZkMuDbvGseyjYMBAXlEq1O5Jhk3Ccq9P1zQrBTOSSvYK ZzAA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@openbsd.org header.s=selector1 header.b=PLBrEZS7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id x10-20020a056a00270a00b006cbb132d46dsi11422281pfv.244.2023.12.14.07.04.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Dec 2023 07:04:52 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=fail header.i=@openbsd.org header.s=selector1 header.b=PLBrEZS7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id E4C46807516A; Thu, 14 Dec 2023 07:04:34 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1573627AbjLNPEV (ORCPT + 99 others); Thu, 14 Dec 2023 10:04:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51758 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1573618AbjLNPEU (ORCPT ); Thu, 14 Dec 2023 10:04:20 -0500 Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF7B6126; Thu, 14 Dec 2023 07:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=selector1; bh=lCD3+ezRCh upqVYtTsaKKo9VlIgR426K/Lj3+3UW9Lk=; h=date:references:in-reply-to: subject:cc:to:from; d=openbsd.org; b=PLBrEZS7k+fCdGI14dJhB2v1zvxNnsWk9 IRwAQdeRVII3pH1g8hvSp+4wXgOErhxma+bYwWSm5xauaUQ7o3ffHh9OwSJzgvv2i/oDYi VneeJ/r+5fLESiWCho3NPSaIEg6rUw+rjBNVz4k66s1r3y1wCdshT9EKiPlkNE4mbXJjX/ SEWhtsxcFVJeJ9VkAIHz3IHXHnCGM+/CR6YeSCNq93e96JeAcu30WBjiCFdN0lHJdV98la hs2BPr3p9m/QblAm7HJWcF+fkLeiryOsxRzUdb1oxWVACdHezLgxWljow4bGg4NxJx2zfO ZJN7G4XowUUmBY/c7b9ZyrP2GrDzg== Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (OpenSMTPD) with ESMTP id fdf4dfe5; Thu, 14 Dec 2023 08:04:23 -0700 (MST) From: "Theo de Raadt" To: Jeff Xu cc: Linus Torvalds , 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, pedro.falcato@gmail.com, dave.hansen@intel.com, linux-hardening@vger.kernel.org Subject: Re: [RFC PATCH v3 11/11] mseal:add documentation In-reply-to: References: <20231212231706.2680890-1-jeffxu@chromium.org> <20231212231706.2680890-12-jeffxu@chromium.org> Comments: In-reply-to Jeff Xu message dated "Wed, 13 Dec 2023 16:35:26 -0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <63611.1702566263.1@cvs.openbsd.org> Date: Thu, 14 Dec 2023 08:04:23 -0700 Message-ID: <56221.1702566263@cvs.openbsd.org> X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Thu, 14 Dec 2023 07:04:35 -0800 (PST) Jeff Xu wrote: > In short, BSD's immutable is designed specific for libc case, and Chrome > case is just different (e.g. the lifetime of those mappings and requirement of > free/discard unused memory). That is not true. During the mimmutable design I took the entire software ecosystem into consideration. Not just libc. That is either uncharitable or uninformed. In OpenBSD, pretty much the only thing which calls mimmutable() is the shared library linker, which does so on all possible regions of all DSO objects, not just libc. For example, chrome loads 96 libraries, and all their text/data/bss/etc are immutable. All the static address space is immutable. It's the same for all other programs running in OpenBSD -- only transient heap and mmap spaces remain permission mutable. It is not just libc. What you are trying to do here with chrome is bring some sort of soft-immutable management to regions of memory, so that trusted parts of chrome can still change the permissions, but untrusted / gadgetry parts of chrome cannot change the permissions. That's a very different thing than what I set out to do with mimmutable(). I'm not aware of any other piece of software that needs this. I still can't wrap my head around the assurance model of the design. Maybe it is time to stop comparing mseal() to mimmutable(). Also, maybe this proposal should be using the name chromesyscall() instead -- then it could be extended indefinitely in the future...