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 X-Spam-Level: X-Spam-Status: No, score=-8.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3073CC433EB for ; Mon, 20 Jul 2020 15:53:03 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F3E4C206E9 for ; Mon, 20 Jul 2020 15:53:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="n2HLY5S5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F3E4C206E9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:Reply-To:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Mime-Version:References:In-Reply-To:Date:To:From: Subject:Message-ID:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=vGytFGJaIfcoXcWlUSAXID9KY5d7Bv2+nr8WIhZCUkU=; b=n2HLY5S5x3Kx9RbWloMhEeaHON 7LmCpMbDs1+1YIF8FK6gKGsg7YmvipK8Yub/ehoO7B79eJ2181iqxC030yD+PAYTEbDDKeM0ToXRa xi3YwxBXGR7gKh1y5U+EwcalznhHza28ff4YOg2hAS8CxjkeyMNnOOqYEOEaIviMhvakSmny8AbeZ WR9AyhFDLKTKSV4PdLz/6pSYPzqWO9j0Dl3YGcECiVdk+c6HtU8xHcvz7PWr50yP7uPlKIV5UIXwa k9qVKxKYitrJp80XnxW3jMCpDyqlQvlEdQgGZ4InuujCTsNks9SPsUCBwRi80G8REttWGWrD2dMPE sugJrqPQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jxY5v-0005Rb-28; Mon, 20 Jul 2020 15:52:47 +0000 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jxY5q-0005Q2-1M; Mon, 20 Jul 2020 15:52:42 +0000 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06KFZClQ100188; Mon, 20 Jul 2020 11:51:58 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 32d5h7sk2a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Jul 2020 11:51:57 -0400 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 06KFaXMR110773; Mon, 20 Jul 2020 11:51:57 -0400 Received: from ppma02wdc.us.ibm.com (aa.5b.37a9.ip4.static.sl-reverse.com [169.55.91.170]) by mx0a-001b2d01.pphosted.com with ESMTP id 32d5h7sk1c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Jul 2020 11:51:57 -0400 Received: from pps.filterd (ppma02wdc.us.ibm.com [127.0.0.1]) by ppma02wdc.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 06KFYvFQ012130; Mon, 20 Jul 2020 15:51:55 GMT Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by ppma02wdc.us.ibm.com with ESMTP id 32brq8tb75-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Jul 2020 15:51:55 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 06KFps6657934112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Jul 2020 15:51:54 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5A87178060; Mon, 20 Jul 2020 15:51:54 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id ED0747805E; Mon, 20 Jul 2020 15:51:46 +0000 (GMT) Received: from [153.66.254.194] (unknown [9.85.132.116]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Mon, 20 Jul 2020 15:51:46 +0000 (GMT) Message-ID: <1595260305.4554.9.camel@linux.ibm.com> Subject: Re: [PATCH 3/6] mm: introduce secretmemfd system call to create "secret" memory areas From: James Bottomley To: Arnd Bergmann , Mike Rapoport Date: Mon, 20 Jul 2020 08:51:45 -0700 In-Reply-To: References: <20200720092435.17469-1-rppt@kernel.org> <20200720092435.17469-4-rppt@kernel.org> X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-20_09:2020-07-20, 2020-07-20 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 phishscore=0 mlxlogscore=999 spamscore=0 adultscore=0 clxscore=1011 mlxscore=0 priorityscore=1501 bulkscore=0 impostorscore=0 suspectscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007200106 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200720_115242_193713_CBE0C656 X-CRM114-Status: GOOD ( 30.16 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: jejb@linux.ibm.com Cc: Peter Zijlstra , Catalin Marinas , Dave Hansen , Linux-MM , "H. Peter Anvin" , Christopher Lameter , Will Deacon , Dan Williams , Elena Reshetova , linux-arch , Tycho Andersen , linux-nvdimm@lists.01.org, Idan Yaniv , the arch/x86 maintainers , Matthew Wilcox , Mike Rapoport , Ingo Molnar , linaro-mm-sig@lists.linaro.org, Borislav Petkov , Alexander Viro , Andy Lutomirski , Paul Walmsley , "Kirill A. Shutemov" , Thomas Gleixner , Linux ARM , Linux API , "linux-kernel@vger.kernel.org" , linux-riscv , Palmer Dabbelt , Linux FS-devel Mailing List , Andrew Morton , Sumit Semwal Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Mon, 2020-07-20 at 13:30 +0200, Arnd Bergmann wrote: > On Mon, Jul 20, 2020 at 11:25 AM Mike Rapoport > wrote: > > > > From: Mike Rapoport > > > > Introduce "secretmemfd" system call with the ability to create > > memory areas visible only in the context of the owning process and > > not mapped not only to other processes but in the kernel page > > tables as well. > > > > The user will create a file descriptor using the secretmemfd system > > call where flags supplied as a parameter to this system call will > > define the desired protection mode for the memory associated with > > that file descriptor. Currently there are two protection modes: > > > > * exclusive - the memory area is unmapped from the kernel direct > > map and it > > is present only in the page tables of the owning mm. > > * uncached - the memory area is present only in the page tables of > > the > > owning mm and it is mapped there as uncached. > > > > For instance, the following example will create an uncached mapping > > (error handling is omitted): > > > > fd = secretmemfd(SECRETMEM_UNCACHED); > > ftruncate(fd, MAP_SIZE); > > ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, > > MAP_SHARED, > > fd, 0); > > > > Signed-off-by: Mike Rapoport > > I wonder if this should be more closely related to dmabuf file > descriptors, which are already used for a similar purpose: sharing > access to secret memory areas that are not visible to the OS but can > be shared with hardware through device drivers that can import a > dmabuf file descriptor. I'll assume you mean the dmabuf userspace API? Because the kernel API is completely device exchange specific and wholly inappropriate for this use case. The user space API of dmabuf uses a pseudo-filesystem. So you mount the dmabuf file type (and by "you" I mean root because an ordinary user doesn't have sufficient privilege). This is basically because every dmabuf is usable by any user who has permissions. This really isn't the initial interface we want for secret memory because secret regions are supposed to be per process and not shared (at least we don't want other tenants to see who's using what). Once you have the fd, you can seek to find the size, mmap, poll and ioctl it. The ioctls are all to do with memory synchronization (as you'd expect from a device backed region) and the mmap is handled by the dma_buf_ops, which is device specific. Sizing is missing because that's reported by the device not settable by the user. What we want is the ability to get an fd, set the properties and the size and mmap it. This is pretty much a 100% overlap with the memfd API and not much overlap with the dmabuf one, which is why I don't think the interface is very well suited. James _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv