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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5E24C61DA2 for ; Thu, 26 Jan 2023 14:25:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232118AbjAZOZM (ORCPT ); Thu, 26 Jan 2023 09:25:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58752 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232190AbjAZOYg (ORCPT ); Thu, 26 Jan 2023 09:24:36 -0500 Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A7A707167E for ; Thu, 26 Jan 2023 06:23:54 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id t12so2004978lji.13 for ; Thu, 26 Jan 2023 06:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=EM8B7vfyD5Py/MB3Opt1I4SCriH6T8vAGD94Cbdc8VI=; b=HtAcpybS0NIBL3fotWhYtfxr09jYWtTCVGDxlVw3etdAwsOY2pjTKteiChBYWFp25c M5xTsH5caJThm3LbLj7yew7ap5AZqvT6L6DxpUnQolNHQS8N9o82kynnDVByw+X+xHK0 ZZBNOcSFhzoDKJvyACDcf1mBUrzQ2g3JjXPOtcQaWmmBl7/8obn8xFaSUKleGLMM0tFz v3zq82JC5Z76pJsk2JqaJu9LlYqdxUuY8h7ek8A35prxW2OiOkytY7H7lLytjXKmV9R6 BGePHVznHtAfIvsawcG4By8wGYMpD7WVd65SaxJqX3GTfShCzwyOsRmEF8gzP2Wfq3NH i0Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=EM8B7vfyD5Py/MB3Opt1I4SCriH6T8vAGD94Cbdc8VI=; b=QNF+ZQfc8UJ7KZ7L64raTXmG5yoHenQGtHkjsDGq/e8uJjgQfwdtss7tqkG71SLsR8 +FN5yv6Y7tlRio31y7blh+S1D7vJgo0UUhJOuCKP7AbePh0v+9MIKNfDcY0xdFdoyTyb 3sG0k9yE1BibXJgWxHJDui6XD+7v5oaYMGrxJGmKT7f7HipZgY2FYXOA01Rq1tOZNVzt v1GRSMvumyBum9w2zgsYFGo42zOWCXIswKwoR00yo9eXDeIwaTlerLe07U3Uwjdmll8J z2dLgnpZKqls2rd6dMroyJzkuFfKF2Thf3RG42Jvr2zb5OUCVvtx/3OfP/wyLfx3Uj8v rOKg== X-Gm-Message-State: AFqh2kpWO51KGgX2wkFFE7F3HKKmXyVaCY/hXrmIAMzb3gandtWBYU8t RbPR+Q8/1n++GDbatJFHt/tw3yzCVKB8dMr5J9I= X-Google-Smtp-Source: AMrXdXvbWzE9Hn4V0NJC8nCCHk4bKSwM/JdIdOkQ/rCSUe75fkT5Wt2Z/1pvBXsidgROqLCy1NgC8HERP5GUCepO1X4= X-Received: by 2002:a2e:9b56:0:b0:279:7164:a0aa with SMTP id o22-20020a2e9b56000000b002797164a0aamr3380935ljj.318.1674743028156; Thu, 26 Jan 2023 06:23:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Weinberger Date: Thu, 26 Jan 2023 15:23:34 +0100 Message-ID: Subject: Re: Linux guest kernel threat model for Confidential Computing To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= Cc: "Dr. David Alan Gilbert" , Greg Kroah-Hartman , "Reshetova, Elena" , "Shishkin, Alexander" , "Shutemov, Kirill" , "Kuppuswamy, Sathyanarayanan" , "Kleen, Andi" , "Hansen, Dave" , Thomas Gleixner , Peter Zijlstra , "Wunner, Lukas" , Mika Westerberg , "Michael S. Tsirkin" , Jason Wang , "Poimboe, Josh" , "aarcange@redhat.com" , Cfir Cohen , Marc Orr , "jbachmann@google.com" , "pgonda@google.com" , "keescook@chromium.org" , James Morris , Michael Kelley , "Lange, Jon" , "linux-coco@lists.linux.dev" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 25, 2023 at 3:22 PM Daniel P. Berrang=C3=A9 wrote: > Any virtual device exposed to the guest that can transfer potentially > sensitive data needs to have some form of guest controlled encryption > applied. For disks this is easy with FDE like LUKS, for NICs this is > already best practice for services by using TLS. Other devices may not > have good existing options for applying encryption. I disagree wrt. LUKS. The cryptography behind LUKS protects persistent data but not transport. If an attacker can observe all IO you better consult a cryptographer. LUKS has no concept of session keys or such, so the same disk sector will always get encrypted with the very same key/iv. --=20 Thanks, //richard