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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 3D3A0C433E2 for ; Fri, 4 Sep 2020 19:39:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F0B68208CA for ; Fri, 4 Sep 2020 19:39:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599248366; bh=RmjdF/oHJi/3WsNTWPfXAZJjc7dD4QJxqtKHWGFhaY4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=JCcAfGAPjiHXNEUMc4iL8atqPhHecP8yr7Nkt8orhOFoVMdi6Q423/6OoGXDpGbxP arb3VL1v0TeXkcHX2TBHg7xw0fYJ8FH58EWw/fpWlT/3RncNmBSQyxh42Jm3cKr1M+ AwOulXrl3S+LwNOvO4j1occpfh+x01JB2TZyQOFU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726441AbgIDTjZ (ORCPT ); Fri, 4 Sep 2020 15:39:25 -0400 Received: from mail.kernel.org ([198.145.29.99]:53414 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726221AbgIDTjY (ORCPT ); Fri, 4 Sep 2020 15:39:24 -0400 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 38FE4208FE for ; Fri, 4 Sep 2020 19:39:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599248364; bh=RmjdF/oHJi/3WsNTWPfXAZJjc7dD4QJxqtKHWGFhaY4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Y1o6AU6wnE4cKa2sVTMvvF98GBPa3kf10zb2k9OyNzsTlvAeCnLsXrxLX5Yl5+PsV DNWxaKPe/hkRRTQHxA1IrPwYyXRbq5uBF69CbAz5jm0qhHf4Wlp59wTni/lzhEHCW1 /4dky9yz5LnF7ZO2jDJt/om5NUG2Li4Xvq7Q+c1c= Received: by mail-wm1-f54.google.com with SMTP id z9so7429795wmk.1 for ; Fri, 04 Sep 2020 12:39:24 -0700 (PDT) X-Gm-Message-State: AOAM532gU76snXDbSwvIcJZWQ+gZUANPJBMrsUmpBCHnvPrVkFrzoq8c 2pSdZ6q0er0wBPrBSvtlUR2ClslzcM0D4Ho0Q6LZtw== X-Google-Smtp-Source: ABdhPJy6MrVLj8wN3xqE2lrca40RAAU/O1tF0PzE0euj/LnWCHYniQ59ghbEpr8F38RNHijEoqwiOEfzuzwZPhNNQmg= X-Received: by 2002:a05:600c:4104:: with SMTP id j4mr8778079wmi.36.1599248362720; Fri, 04 Sep 2020 12:39:22 -0700 (PDT) MIME-Version: 1.0 References: <20200904113116.20648-1-alazar@bitdefender.com> In-Reply-To: <20200904113116.20648-1-alazar@bitdefender.com> From: Andy Lutomirski Date: Fri, 4 Sep 2020 12:39:10 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RESEND RFC PATCH 0/5] Remote mapping To: =?UTF-8?Q?Adalbert_Laz=C4=83r?= Cc: Linux-MM , Linux API , Andrew Morton , Alexander Graf , Stefan Hajnoczi , Jerome Glisse , Paolo Bonzini , =?UTF-8?B?TWloYWkgRG9uyJt1?= , Mircea Cirjaliu , Andy Lutomirski , Arnd Bergmann , Sargun Dhillon , Aleksa Sarai , Oleg Nesterov , Jann Horn , Kees Cook , Matthew Wilcox , Christian Brauner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-api-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Fri, Sep 4, 2020 at 4:41 AM Adalbert Laz=C4=83r = wrote: > > This patchset adds support for the remote mapping feature. > Remote mapping, as its name suggests, is a means for transparent and > zero-copy access of a remote process' address space. > access of a remote process' address space. > I think this is very clever, but I find myself wondering what happens if people start trying to abuse this by, for example, setting up a remote mapping pointing to fun regions like userfaultfd or another remote mapping. I'm a little concerned that it's actually too clever and that maybe a more straightforward solution should be investigated. I personally rather dislike the KVM model in which the guest address space mirrors the host (QEMU) address space rather than being its own thing. In particular, the current model means that extra-special-strange mappings like SEV-encrypted memory are required to be present in the QEMU page tables in order for the guest to see them. (If I had noticed that last bit before it went upstream, I would have NAKked it. I would still like to see it deprecated and ideally eventually removed from the kernel. We have absolutely no business creating incoherent mappings like this.) --Andy