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=unavailable 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 01F67C31E5C for ; Mon, 17 Jun 2019 15:07:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CF7172086A 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=gkyZYfyDil1UyHn0aJ6BudtZ7sbdPPIlgXpM3WnK767FQ0cOroPyBWnwNKHPGM/5p mcI4pNVp88m6tHzH4Bz+StV03FKs4TAmImKtL2ozpoVaRq1WJhcA5JlyfZtbcE4O0G 6N7pkLgnWfya8g5twREbhmeafpQ2E/811e37+lj0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728438AbfFQPHn (ORCPT ); Mon, 17 Jun 2019 11:07:43 -0400 Received: from mail.kernel.org ([198.145.29.99]:43024 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727999AbfFQPHm (ORCPT ); Mon, 17 Jun 2019 11:07:42 -0400 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (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 D4C5421855 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-f43.google.com with SMTP id p11so10369207wre.7 for ; Mon, 17 Jun 2019 08:07:41 -0700 (PDT) X-Gm-Message-State: APjAAAUSswx6hyQjPmiwFkRENdweNUiBHK1o4qjDg0DkzhbYtBjnBrgK Qam+eGtbEJKTHCBNe/74/Q4/A+KSsF8bXHtmdNd6Mw== 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: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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