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=-5.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 4CDCFC433E1 for ; Wed, 26 Aug 2020 16:55:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0B9832080C for ; Wed, 26 Aug 2020 16:55:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ALtDO/SG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B9832080C 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 978376B0005; Wed, 26 Aug 2020 12:55:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 929476B0006; Wed, 26 Aug 2020 12:55:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8179D6B0007; Wed, 26 Aug 2020 12:55:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0026.hostedemail.com [216.40.44.26]) by kanga.kvack.org (Postfix) with ESMTP id 6C9DA6B0005 for ; Wed, 26 Aug 2020 12:55:12 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3016F82499B9 for ; Wed, 26 Aug 2020 16:55:12 +0000 (UTC) X-FDA: 77193320064.09.hen00_4b151ee27066 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id F3FD9180AD802 for ; Wed, 26 Aug 2020 16:55:11 +0000 (UTC) X-HE-Tag: hen00_4b151ee27066 X-Filterd-Recvd-Size: 5254 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Wed, 26 Aug 2020 16:55:11 +0000 (UTC) Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 5FD842080C for ; Wed, 26 Aug 2020 16:55:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598460910; bh=90eG2YC7ABsnYjclAXIjb+dB+da3NK2fm+peh/LcFOk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ALtDO/SGIdIyXtJEgnSUc5+3ECVAWbJUiZmmv4zc0htOnx8GLxrv0eP+vpvcifgBr 4ercfZTjzUiKDT5N/tuG4G2vavO/VGYzZeLs6HiGnTXGWKm7MN/9B3hZhOaXf9NEbv YSjGr0Kf2NouFCLwjCP/LyibUnKlXuGq7Sbuc8Yc= Received: by mail-wm1-f49.google.com with SMTP id s13so2462508wmh.4 for ; Wed, 26 Aug 2020 09:55:10 -0700 (PDT) X-Gm-Message-State: AOAM5326beDaGO1T3kwU59C4iIYy4aObyWsbTXuxqHIHSrSYZkUtiENw U9ZuP5vW7ifKHzU7LYrhWFu8tYMP1y9YkD9YoKj/7Q== X-Google-Smtp-Source: ABdhPJzm6zw8GgmvAuLjLkF//j2YOGcbQK27MpOGIKs7o1yACCh0Pt9TsTFQE/afB1qwmSFWs+CN/ps0CGFC5GDu0TQ= X-Received: by 2002:a1c:bc45:: with SMTP id m66mr7394687wmf.36.1598460908958; Wed, 26 Aug 2020 09:55:08 -0700 (PDT) MIME-Version: 1.0 References: <20200130162340.GA14232@rapoport-lnx> <6e020a65-b516-9407-228f-2a3a32947ab9@intel.com> In-Reply-To: <6e020a65-b516-9407-228f-2a3a32947ab9@intel.com> From: Andy Lutomirski Date: Wed, 26 Aug 2020 09:54:57 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH] mm: extend memfd with ability to create "secret" memory areas To: Dave Hansen Cc: Andy Lutomirski , Mike Rapoport , LKML , Alan Cox , Andrew Morton , 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: F3FD9180AD802 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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 Fri, Aug 14, 2020 at 11:09 AM Dave Hansen wrote: > > On 8/14/20 10:46 AM, Andy Lutomirski wrote: > > 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. > > I think this is much more in the category of raising the bar than > providing any absolute security guarantees. The problem here is that we're raising the bar in a way that is weirdly architecture dependent, *extremely* nonperformant, and may not even accomplish what it's trying to accomplish. > > Let's say you have a secret and you read it into some registers and then > spill them on the stack. You've got two cached copies, one for the > primary data and another for the stack copy. Secret areas don't get rid > of the stack copy, but they do get rid of the other one. One cache copy > is better than two. Bar raised. :) If we have two bars right next to each other and we raise one of them, did we really accomplish much? I admit that having a secret in its own dedicated cache line seems like an easier target than a secret in a cache line that may be quickly overwritten by something else. But even user registers right now aren't specially protected -- pt_regs lives is cached and probably has a predictable location, especially if you execve() a setuid program. > > There are also some stronger protections, less in the bar-raising > category. On x86 at least, uncached accesses also crush speculation. > You can't, for instance, speculatively get wrong values if you're not > speculating in the first place. I was thinking of things like Load > Value Injection[1]. This seems genuinely useful, but it doesn't really address the fact that requesting UC memory via PAT apparently has a good chance of getting WB anyway. > > I _believe_ there are also things like AES-NI that can get strong > protection from stuff like this. They load encryption keys into (AVX) > registers and then can do encrypt/decrypt operations without the keys > leaving the registers. If the key was loaded from a secret memory area > right into the registers, I think the protection from cache attacks > would be pretty strong. > Except for context switches :) > > 1. > https://software.intel.com/security-software-guidance/insights/deep-dive-load-value-injection