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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham 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 CAC3CC31E5D for ; Mon, 17 Jun 2019 15:07:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A4392208E4 for ; Mon, 17 Jun 2019 15:07:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1560784064; bh=Gxoxo21Lfkn/K7A7njUdmGutlMuh89H9AmOUNy6D3vQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=A9oCYpPT8sbfDqQSgV+pUCg5b+WCxat8m2//+b4wyZeoenLoCHfj5U4JPhDptOuS7 cmNIYj1vQyj5TKwzBbdnKnOJucXTY2vhC0kMmz7PdBfxeg/UyDF9bJxitjEI6QYZkw 9t3l5KVcNJXkIYWDzRzSYaL/oQ8bNHso/pUR+0qQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728454AbfFQPHn (ORCPT ); Mon, 17 Jun 2019 11:07:43 -0400 Received: from mail.kernel.org ([198.145.29.99]:42984 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726731AbfFQPHn (ORCPT ); Mon, 17 Jun 2019 11:07:43 -0400 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (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 B2757208CB for ; Mon, 17 Jun 2019 15:07:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1560784062; bh=Gxoxo21Lfkn/K7A7njUdmGutlMuh89H9AmOUNy6D3vQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=kijmrsYEnMsus0trgL5AcnNyXRdSURSsYmJ/F2iZvEm/37ek4Kg+AF9JdVMI9bh9W JCFvsRZC0mD8yQbWZY9v8HJWBAPk96z9+JoD4uRu7MAO4S0KFeAtbR+55mQnDUe/5Z nWYb6rdWQnZWVQMEPmADVTmw4jGsElcvfYdVki2M= Received: by mail-wr1-f52.google.com with SMTP id k11so10383793wrl.1 for ; Mon, 17 Jun 2019 08:07:41 -0700 (PDT) X-Gm-Message-State: APjAAAV7wPhpBXXyCUU2jAVPut7Oi8W+y3E16jV/5jsnJ870HEAQ9Sk9 5I+gHE7fwhs+X4/hbJUBch/D9yB9HQGnABtFluXTsA== X-Google-Smtp-Source: APXvYqyI1b9br6hsxubRzj9P6hDCchpenelMr+cbgYq59s/ECCE0jKzqk2QGDR5wJOWg+nRr7Sj8Tlmkt7OD9xMBD9U= X-Received: by 2002:a5d:6a42:: with SMTP id t2mr12131692wrw.352.1560784060277; Mon, 17 Jun 2019 08:07:40 -0700 (PDT) MIME-Version: 1.0 References: <20190508144422.13171-1-kirill.shutemov@linux.intel.com> <20190508144422.13171-46-kirill.shutemov@linux.intel.com> In-Reply-To: <20190508144422.13171-46-kirill.shutemov@linux.intel.com> From: Andy Lutomirski Date: Mon, 17 Jun 2019 08:07:29 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH, RFC 45/62] mm: Add the encrypt_mprotect() system call for MKTME To: "Kirill A. Shutemov" Cc: Andrew Morton , X86 ML , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Borislav Petkov , Peter Zijlstra , David Howells , Kees Cook , Dave Hansen , Kai Huang , Jacob Pan , Alison Schofield , Linux-MM , kvm list , keyrings@vger.kernel.org, LKML Content-Type: text/plain; charset="UTF-8" Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, May 8, 2019 at 7:44 AM Kirill A. Shutemov wrote: > > From: Alison Schofield > > Implement memory encryption for MKTME (Multi-Key Total Memory > Encryption) with a new system call that is an extension of the > legacy mprotect() system call. > > In encrypt_mprotect the caller must pass a handle to a previously > allocated and programmed MKTME encryption key. The key can be > obtained through the kernel key service type "mktme". The caller > must have KEY_NEED_VIEW permission on the key. > > MKTME places an additional restriction on the protected data: > The length of the data must be page aligned. This is in addition > to the existing mprotect restriction that the addr must be page > aligned. I still find it bizarre that this is conflated with mprotect(). I also remain entirely unconvinced that MKTME on anonymous memory is useful in the long run. There will inevitably be all kinds of fancy new CPU features that make the underlying MKTME mechanisms much more useful. For example, some way to bind a key to a VM, or a way to *sanely* encrypt persistent memory. By making this thing a syscall that does more than just MKTME, you're adding combinatorial complexity (you forget pkey!) and you're tying other functionality (change of protection) to this likely-to-be-deprecated interface. This is part of why I much prefer the idea of making this style of MKTME a driver or some other non-intrusive interface. Then, once everyone gets tired of it, the driver can just get turned off with no side effects. --Andy