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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 21F72C433E2 for ; Mon, 7 Sep 2020 08:38:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 987B72168B for ; Mon, 7 Sep 2020 08:38:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 987B72168B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ubuntu.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A26586B005A; Mon, 7 Sep 2020 04:38:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D4996B005C; Mon, 7 Sep 2020 04:38:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C2EE6B0068; Mon, 7 Sep 2020 04:38:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0092.hostedemail.com [216.40.44.92]) by kanga.kvack.org (Postfix) with ESMTP id 735BC6B005A for ; Mon, 7 Sep 2020 04:38:12 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 3816C362A for ; Mon, 7 Sep 2020 08:38:12 +0000 (UTC) X-FDA: 77235613224.03.lace39_1f115f0270ca Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 1246A28A4E8 for ; Mon, 7 Sep 2020 08:38:12 +0000 (UTC) X-HE-Tag: lace39_1f115f0270ca X-Filterd-Recvd-Size: 4800 Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Mon, 7 Sep 2020 08:38:11 +0000 (UTC) Received: from ip5f5af70b.dynamic.kabel-deutschland.de ([95.90.247.11] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kFCf9-0004Rn-HI; Mon, 07 Sep 2020 08:38:07 +0000 Date: Mon, 7 Sep 2020 10:38:06 +0200 From: Christian Brauner To: Paolo Bonzini Cc: Andy Lutomirski , Adalbert =?utf-8?B?TGF6xINy?= , Linux-MM , Linux API , Andrew Morton , Alexander Graf , Stefan Hajnoczi , Jerome Glisse , Mihai =?utf-8?B?RG9uyJt1?= , Mircea Cirjaliu , Arnd Bergmann , Sargun Dhillon , Aleksa Sarai , Oleg Nesterov , Jann Horn , Kees Cook , Matthew Wilcox Subject: Re: [RESEND RFC PATCH 0/5] Remote mapping Message-ID: <20200907083806.krehiwqtfiw42wmy@wittgenstein> References: <70D23368-A24D-4A15-8FC7-FA728D102475@amacapital.net> <836cff86-e670-8c69-6cbd-b22c5b5538df@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 1246A28A4E8 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, Sep 05, 2020 at 08:27:29PM +0200, Paolo Bonzini wrote: > On 05/09/20 01:17, Andy Lutomirski wrote: > > There's sev_pin_memory(), so QEMU must have at least some idea of > > which memory could potentially be encrypted. Is it in fact the case > > that QEMU doesn't know that some SEV pinned memory might actually be > > used for DMA until the guest tries to do DMA on that memory? If so, > > yuck. > > Yes. All the memory is pinned, all the memory could potentially be used > for DMA (of garbage if it's encrypted). And it's the same for pretty > much all protected VM extensions (SEV, POWER, s390, Intel TDX). > > >> The primary VM and the enclave VM(s) would each get a different memory > >> access file descriptor. QEMU would treat them no differently from any > >> other externally-provided memory backend, say hugetlbfs or memfd, so > >> yeah they would be mmap-ed to userspace and the host virtual address > >> passed as usual to KVM. > > > > Would the VM processes mmap() these descriptors, or would KVM learn > > how to handle that memory without it being mapped? > > The idea is that the process mmaps them, QEMU would treat them just the > same as a hugetlbfs file descriptor for example. > > >> The manager can decide at any time to hide some memory from the parent > >> VM (in order to give it to an enclave). This would actually be done on > >> request of the parent VM itself [...] But QEMU is > >> untrusted, so the manager cannot rely on QEMU behaving well. Hence the > >> privilege separation model that was implemented here. > > > > How does this work? Is there a revoke mechanism, or does the parent > > just munmap() the memory itself? > > The parent has ioctls to add and remove memory from the pidfd-mem. So > unmapping is just calling the ioctl that removes a range. I would strongly suggest we move away from ioctl() patterns. If something like this comes up in the future, just propose them as system calls. > > >> So what you are suggesting is that KVM manages its own address space > >> instead of host virtual addresses (and with no relationship to host > >> virtual addresses, it would be just a "cookie")? > > > > [...] For this pidfd-mem scheme in particular, it might avoid the nasty > > corner case I mentioned. With pidfd-mem as in this patchset, I'm > > concerned about what happens when process A maps some process B > > memory, process B maps some of process A's memory, and there's a > > recursive mapping that results. Or when a process maps its own > > memory, for that matter. > > > > Or memfd could get fancier with operations to split memfds, remove > > pages from memfds, etc. Maybe that's overkill. > > Doing it directly with memfd is certainly an option, especially since > MFD_HUGE_* exists. Basically you'd have a system call to create a I like that idea way better to be honest. Christian