Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3527877pxb; Mon, 24 Jan 2022 11:27:32 -0800 (PST) X-Google-Smtp-Source: ABdhPJzGDeieTQSKuVl42KwVuUtLwHhRmZtvWKt6W0YUfg8lZjb3u4ZWYJQzdUZrlvLVLebpDIQT X-Received: by 2002:a05:6a00:853:b0:4c0:3e77:22ea with SMTP id q19-20020a056a00085300b004c03e7722eamr15216355pfk.74.1643052452449; Mon, 24 Jan 2022 11:27:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643052452; cv=none; d=google.com; s=arc-20160816; b=awz3goB85LE2dlR+HXkNIKt6cs4ZYCEmUXj7pqlxGO0RIOTMfVQuTJZu+VtDnOKvQt A83+BdHKSYtqmMI+uigy3KOToSC92enEvpLAv+cGrSS+fztOyPoaODILqzUulZpEsGjL O68rF8b9QOU5giUbqe8KmX1x3Rvq4Bt6ZPfgHH1cdyBoFVCh6klK//GV+wMJrplfldI3 tmouI3fhNno0+4akX5tlnAKu2tqHPZn8ljL5svBXfiy0TOSgggjGc/R2654eloA99+EH bFw5e45rzTeuCdmdYe92Dcu6OYHVz2fxK7p3W1ro38sk/SF84Kl3rju0yFnvPSgiX1Dy G2MQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=FxT0fvTiG1ZWES/dHbuuGT9jetIKmcYAgeRuTAT+qns=; b=Jq2FpIGZ3oVT7kPPIp8bfCqvtryyTSFoQQwLdvvOhnfzodp7VdemxewsIqT7MQ6taK n6KRyrFaPJEMyQhygV2hETj8lsOq0cNkA2Lauxh6qCYsfUhbpsXOqILIGowoKqQ6ZHg8 SlLs46GEvLavZ3M4Lb9s2oEmod4xc3A/d8OZOkoW3xdzxPAmsxAqlfYSWbCO5q0X0exj bUIMudyukQ3kDK/Vi9y059TIgUSX18puYYRMZNPoQhQJfiEJzRWGPDhEZl1jB9ZEIjqA xQGC6zW5e2fGdxwdIdRIEAKkLAoUtEjqixttgGb7PSNuYe23H9STaS3Pzj+eg3uZJ0YS CRsg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="DvE0n/LI"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ip13si202254pjb.161.2022.01.24.11.27.20; Mon, 24 Jan 2022 11:27:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="DvE0n/LI"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242742AbiAXP1u (ORCPT + 99 others); Mon, 24 Jan 2022 10:27:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50786 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238433AbiAXP1s (ORCPT ); Mon, 24 Jan 2022 10:27:48 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C61B5C06173B for ; Mon, 24 Jan 2022 07:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=FxT0fvTiG1ZWES/dHbuuGT9jetIKmcYAgeRuTAT+qns=; b=DvE0n/LIurw9q3NLQ/WXt9lf5B mGo5yLGsSQ0g1aWtV79v3Ezbi9mI00Ut94vA3MviH3rFaIZFkPcTCfALmMXNx6mCxhT0KCaSMpgaT wdjj9Dhs005TOYrWdhIBSzggcPhGOong4O1QNt3xlZkhYsPvSzxE4p2J9qmhq9yrBZu+fNkG2Msbm Kv/qVjAeIHMIStIC5EB2tM/oH+QQMqQI5Ja4JIVpeWSr6j7RjbObNP81e6+EKIhmBHRnKDA9l9H9E F+XEMrPigAC/Do2Fe4fjkkwGO2TQGgga96jgf/GSII8Y4zlliLI/z9EL7Iy2JzKj6XgnfrMpg+YgX 4+4S6vvA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nC1Fe-000p5y-4V; Mon, 24 Jan 2022 15:27:26 +0000 Date: Mon, 24 Jan 2022 15:27:26 +0000 From: Matthew Wilcox To: Mark Hemment Cc: Khalid Aziz , Andrew Morton , longpeng2@huawei.com, arnd@arndb.de, dave.hansen@linux.intel.com, david@redhat.com, rppt@kernel.org, Suren Baghdasaryan , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH 0/6] Add support for shared PTEs across processes Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 24, 2022 at 03:15:36PM +0000, Mark Hemment wrote: > From the code sample in your initial email (simplified), where a > process creates a msharefs file with the anonymous mmap()ed region to > be shared; > addr = mmap(RDWR, ANON); > mshare("testregion", addr, len, CREAT|RDWR|EXCL, 0600); > > Now, consider the case where the mmap() is named (that is, against a > file). I believe this is the usecase for Oracle's SGA. > My (simplified) code for msharing a named file ("SGA") using your > proposed API (does not matter if the mapping is PRIVATE or SHARED); > fd = open("SGA", RDWR); > addr = mmap(RDWR, ..., fd); > mshare("SGA-region", addr, len, CREAT|RDWR|EXCL, 0600); Don't think of an mshared region as containing only one file. It might easily contain dozens. Or none at the start. They're dynamic; the mshare fd represents a chunk of address space, not whatever is currently mapped there. > If the permissions (usr/grp+perms+ACL) between the "SGA" file and the > "SGA-region" msharefs are different, then it is very likely a serious > security issue. Only in the same sense that an application might open() a file that it has permission to access and then open a pipe/socket to a process that does not have permission and send the data to it.