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 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 7ACEAC433E1 for ; Fri, 14 Aug 2020 17:47:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 386FD20774 for ; Fri, 14 Aug 2020 17:47:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="M1BVD6Sn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 386FD20774 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D88B58D000C; Fri, 14 Aug 2020 13:47:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CEB268D0003; Fri, 14 Aug 2020 13:47:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB3048D000C; Fri, 14 Aug 2020 13:47:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0001.hostedemail.com [216.40.44.1]) by kanga.kvack.org (Postfix) with ESMTP id 9ED718D0003 for ; Fri, 14 Aug 2020 13:47:10 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 68369824805A for ; Fri, 14 Aug 2020 17:47:10 +0000 (UTC) X-FDA: 77149905420.22.drug96_231321826ffe Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 25B8518038E60 for ; Fri, 14 Aug 2020 17:47:10 +0000 (UTC) X-HE-Tag: drug96_231321826ffe X-Filterd-Recvd-Size: 5591 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Fri, 14 Aug 2020 17:47:09 +0000 (UTC) Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (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 59C8D20774 for ; Fri, 14 Aug 2020 17:47:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597427228; bh=akv/UmJpcxiw7tC5PwlDZdR2KC9Vs7eUyK1bJfdTthU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=M1BVD6SnLlAB2txByxPfGzUWpVOp3wq3n7nM5a54Y2PQJRoJlEXq4f0QbkFagm6pg 9dBY7bMOODEevE6mAvxFYo35Mi9HPTiws8gRQ5R225rEKUaODsFf8AGNqWHm7C1l6j PV+URg/mt57tVczx/6gYBnLYKuLv/hYkJ1cGVOd8= Received: by mail-wr1-f46.google.com with SMTP id f1so9074153wro.2 for ; Fri, 14 Aug 2020 10:47:08 -0700 (PDT) X-Gm-Message-State: AOAM532bLQRYvt37e3EhJTocCK2Jx2xnqxjK0D4mAX6JggNj4bIPqyKt h9oaqHy8YVh7l5Ky3yba2RJTfAMLTd5tYEqK0dJwTQ== X-Google-Smtp-Source: ABdhPJyUWIngePPeonF9Qb5pi4t0BlSXHz3udbBaINEYqUbzO/kdzoB39Yt/n/fFkRBlsagQA4nriALJiUYA+FrSZsE= X-Received: by 2002:adf:e90f:: with SMTP id f15mr3752426wrm.18.1597427226974; Fri, 14 Aug 2020 10:47:06 -0700 (PDT) MIME-Version: 1.0 References: <20200130162340.GA14232@rapoport-lnx> In-Reply-To: <20200130162340.GA14232@rapoport-lnx> From: Andy Lutomirski Date: Fri, 14 Aug 2020 10:46:55 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH] mm: extend memfd with ability to create "secret" memory areas To: Mike Rapoport Cc: LKML , Alan Cox , Andrew Morton , Andy Lutomirski , Christopher Lameter , Dave Hansen , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Peter Zijlstra , "Reshetova, Elena" , Thomas Gleixner , Tycho Andersen , Linux API , Linux-MM Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 25B8518038E60 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 Thu, Jan 30, 2020 at 8:23 AM Mike Rapoport wrote: > > Hi, > > This is essentially a resend of my attempt to implement "secret" mappings > using a file descriptor [1]. > > I've done a couple of experiments with secret/exclusive/whatever > memory backed by a file-descriptor using a chardev and memfd_create > syscall. There is indeed no need for VM_ flag, but there are still places > that would require special care, e.g vm_normal_page(), madvise(DO_FORK), so > it won't be completely free of core mm modifications. > > Below is a POC that implements extension to memfd_create() that allows > mapping of a "secret" memory. The "secrecy" mode should be explicitly set > using ioctl(), for now I've implemented exclusive and uncached mappings. Hi- Sorry for the extremely delayed response. I like the general concept, and I like the exclusive concept. While it is certainly annoying for the kernel to manage non-direct-mapped pages, I think it's the future. But I have serious concerns about the uncached part. Here are some concerns. If it's done at all, I think it should be MFD_SECRET_X86_UNCACHED. I think that uncached memory is outside the scope of things that can reasonably be considered to be architecture-neutral. (For example, on x86, UC and WC have very different semantics, and UC has quite different properties than WB for things like atomics. Also, the performance of UC is interesting at best, and the ways to even moderately efficiently read from UC memory or write to UC memory are highly x86-specific.) I'm a little unconvinced about the security benefits. As far as I know, UC memory will not end up in cache by any means (unless aliased), but it's going to be tough to do much with UC data with anything resembling reasonable performance without derived values getting cached. It's likely entirely impossible to do it reliably without asm. But even with plain WB memory, getting it into L1 really should not be that bad unless major new vulnerabilities are discovered. And there are other approaches that could be more arch-neutral and more performant. For example, there could be an option to flush a few cache lines on schedule out. This way a task could work on some (exclusive but WB) secret memory and have the cache lines flushed if anything interrupts it. Combined with turning SMT off, this could offer comparable protection with much less overhead. UC also doesn't seem reliable on x86, sadly. From asking around, there are at least a handful of scenarios under which the kernel can ask the CPU for UC but get WB anyway. Apparently Xen hypervisors will do this unless the domain has privileged MMIO access, and ESXi will do it under some set of common circumstances. So unless we probe somehow or have fancy enumeration or administrative configuration, I'm not sure we can even get predictable behavior if we hand userspace a supposedly UC mapping. Giving user code WB when it thinks it has UC could end badly. --Andy