Received: by 2002:a05:7412:d8a:b0:e2:908c:2ebd with SMTP id b10csp3317985rdg; Tue, 17 Oct 2023 10:44:13 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEHYISGgFCNrlzv8krJU85Lgo3WeDl0dhw5bmfPTybTAXL9S/P58FabJxB9dtINKbBYQtXo X-Received: by 2002:a17:90a:df8d:b0:27d:2ed1:6b87 with SMTP id p13-20020a17090adf8d00b0027d2ed16b87mr2663196pjv.40.1697564652614; Tue, 17 Oct 2023 10:44:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697564652; cv=none; d=google.com; s=arc-20160816; b=lkXmi4f+N9k0kfb947jkzF66AWaxAhsynDgp00RkRZMGj2Ntg8nIR1I6XMYNo/VV4P ZkM8j3SGYdms8s+x0TgLyO9c5cVYfF1PnFOZZrae7oMwq1lfdp7kyKTyT6KhLntpWoGK 1n0EthkA589oT5WMGfSYDxWHLVFlhmaeWl6QLKyIv2tc9d1ASHurN7M0W8hSx8lP3Mfu Rjur1UVjZGoz72ydjaD3ulBspl7CEZub7v71v9JXYmMcHzwymUfX/8c0IljZV0iu7Ivd 0CPLKkF6NTJ1ctjLfOpbO5atFGKG4dt/Qkb5gPYFSo9oNKuJT702+iWik659Nuuc9Tad FanA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=EJ+grLHpGUzgQCivN/ck9HANlKle5gcz1nC0C6eh5V4=; fh=nswF69hjdg2QPgO9e4zWPt6GO2V9GP/lyxM0mb39GV0=; b=nLyOCY0W4n4kXHl0iW/yOpwhqn64AcMlVGmY+sVAgbEz0osuw/bnLwiy8dvnvn+RqB ZIAJk9gkWzr3VaRp8PiQu94wnKCdDLbAlvN4Jxdmyr9jrZwrMqHJsrozCT6zjmviknQ2 d3fH6VUJzcdy7qqe5Dfm6ptGwcqT0a5rLxTS+Us4RoETo5IRcIKd31nrWAycAWxMCnLz DOarWKqLIUegilcyMzsJDYOqDhcNANpmtbsbCZTxr5l8PQhDumQqVBmYk7LkFt1NT5Ej kUdncuzlZxFCOn1/cAQ790cd5m7mj7lg5/B3GRfsoHz3HkwYEf/R90wh8VxWhuWVZfd3 mMLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=QqF65grA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id j187-20020a638bc4000000b00565f182839asi241436pge.28.2023.10.17.10.44.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 10:44:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=QqF65grA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 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 10BCC8096457; Tue, 17 Oct 2023 10:44:10 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234304AbjJQRoE (ORCPT + 99 others); Tue, 17 Oct 2023 13:44:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35968 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230343AbjJQRoD (ORCPT ); Tue, 17 Oct 2023 13:44:03 -0400 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A58679B for ; Tue, 17 Oct 2023 10:43:59 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-53e3e7e478bso7327028a12.0 for ; Tue, 17 Oct 2023 10:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1697564638; x=1698169438; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EJ+grLHpGUzgQCivN/ck9HANlKle5gcz1nC0C6eh5V4=; b=QqF65grAoYKu2Mqgf4gfrzrq39ihiujhQSENEeytM4A4K3wI4rzF8UMyoBtgm97AIp VshqgTJULVVqs9g/7WVIC+k0f7J6oDynXG/IQcfShqXLNQE8o4NrcX+eOP1wU2ck6UOl 2zbCCXPVEQvUfET5wtLD0uhIQBz7rgZd0KOO4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697564638; x=1698169438; h=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=EJ+grLHpGUzgQCivN/ck9HANlKle5gcz1nC0C6eh5V4=; b=kzGHtkTPhyjZZB3+NJTh8CDSfG3HMQsxNCkTxqYAkhxuAhMGeziYjGtK72acmuqJnh 9TmtKOBMux2JOJuVkPcY6/9SZeE1oEPGj34ujOslFmVqs4CUoNWDr8c/vrUIFTQ2ga2M Qux2UCwOXhjj0G1/1wL7qHl6FKHC4FM2gigerVox28hedMQlOXAgFti4q+StspcU8/n1 MA/Jl5Deflw2A32HPph2juAwWOv+PNPQSNCQ7Ic4LTXLnih1SrmFpO6YdpIjAfR01Y30 XGD5Ooi0dtOCH3Tn1XthJNL5DXckRlg7I5IHva+mv4zvcPwzT7d6WicY+4Zr+TWc+y86 DKIw== X-Gm-Message-State: AOJu0YyPF/tte0ZoDNv9Fs96DjYPOcV/D2uF7X0oQ59zjgoDyhRcEZva Zjpuitpp9tP5tnZ4MwUP3TVVerSYUPhRqmp0LEurzTg4 X-Received: by 2002:a50:c2c1:0:b0:53e:d0cf:453c with SMTP id u1-20020a50c2c1000000b0053ed0cf453cmr2485210edf.9.1697564637843; Tue, 17 Oct 2023 10:43:57 -0700 (PDT) Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com. [209.85.208.53]) by smtp.gmail.com with ESMTPSA id s23-20020a508d17000000b00536031525e5sm1547334eds.91.2023.10.17.10.43.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Oct 2023 10:43:56 -0700 (PDT) Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-53e07db272cso9307009a12.3 for ; Tue, 17 Oct 2023 10:43:56 -0700 (PDT) X-Received: by 2002:a17:907:9306:b0:9bd:8cfd:e588 with SMTP id bu6-20020a170907930600b009bd8cfde588mr2685824ejc.27.1697564636390; Tue, 17 Oct 2023 10:43:56 -0700 (PDT) MIME-Version: 1.0 References: <20231017090815.1067790-1-jeffxu@chromium.org> <20231017090815.1067790-8-jeffxu@chromium.org> In-Reply-To: From: Linus Torvalds Date: Tue, 17 Oct 2023 10:43:39 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v2 7/8] mseal:Check seal flag for mmap(2) To: jeffxu@chromium.org Cc: akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.org, jeffxu@google.com, 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" X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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]); Tue, 17 Oct 2023 10:44:10 -0700 (PDT) On Tue, 17 Oct 2023 at 10:04, Linus Torvalds wrote: > > Honestly, there is only two kinds of sealing that makes sense: > > - you cannot change the permissions of some area > > - you cannot unmap an area Actually, I guess at least theoretically, there could be three different things: - you cannot move an area although I do think that maybe just saying "you cannot unmap" might also include "you cannot move". But I guess it depends on whether you feel it's the virtual _address_ you are protecting, or whether it's the concept of mapping something. I personally think that from a security perspective, what you want to protect is a particular address. That implies that "seal from unmapping" would thus also include "you can't move this area elsewhere". But at least conceptually, splitting "unmap" and "move" apart might make some sense. I would like to hear a practical reason for it, though. Without that practical reason, I think the only two sane sealing operations are: - SEAL_MUNMAP: "don't allow this mapping address to go away" IOW no unmap, no shrinking, no moving mremap - SEAL_MPROTECT: "don't allow any mapping permission changes" Again, that permission case might end up being "don't allow _additional_ permissions" and "don't allow taking permissions away". Or it could be split by operation (ie "don't allow permission changes to writability / readability / executability respectively"). I suspect there isn't a real-life example of splitting the SEAL_MPROTECT (the same way I doubt there's a real-life example for splitting the UNMAP into "unmap vs move"), so unless there is some real reason, I'd keep the sealing minimal and to just those two flags. We could always add more flags later, if there is a real use case (IOW, if we start with "don't allow any permission changes", we could add a flag later that just says "don't allow writability changes"). Linus