From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <s.reiter@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 600CD6C856 for <pve-devel@lists.proxmox.com>; Thu, 23 Sep 2021 16:55:14 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 1EE4A28047 for <pve-devel@lists.proxmox.com>; Thu, 23 Sep 2021 16:55:14 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 99B992802A for <pve-devel@lists.proxmox.com>; Thu, 23 Sep 2021 16:55:12 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 705B444A5A for <pve-devel@lists.proxmox.com>; Thu, 23 Sep 2021 16:55:12 +0200 (CEST) From: Stefan Reiter <s.reiter@proxmox.com> To: pve-devel@lists.proxmox.com Date: Thu, 23 Sep 2021 16:54:55 +0200 Message-Id: <20210923145459.1508558-1-s.reiter@proxmox.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.553 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: [pve-devel] [RFC v2 0/4] Initial TPM support for VMs X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Thu, 23 Sep 2021 14:55:14 -0000 Makes Windows 11 (test build) happy: https://i.imgur.com/kZ0Mpnr.jpeg Tested under Linux as well, works with (updated) OVMF and SeaBIOS, though SeaBIOS requires clearing via the BIOS setup screen and may not support all features it seems (e.g. Windows shows the TPM, but doesn't allow BitLocker, presumably because it requires UEFI). Requires patched swtpm with my PR applied: https://github.com/stefanberger/swtpm/pull/513 = Known Issues = Backups currently don't work. This is due to the fact that we use QEMU to write out all data - but QEMU doesn't know about the backing store of swtpm. This is quite an issue, and I'm not yet sure how to best handle it. We could include the TPM as a "blob" like the config (as it's fairly small), but I need to think through the timing so consistency is not affected. swtpm_setup doesn't support the backing-uri parameter correctly yet (see also the PR for a bit more info), which means we can't generate the initial TPM state to our liking yet. This doesn't seem to affect operation much, but is not the recommended and documented way of using swtpm. TPM state cannot be stored on non-krbd Ceph, as RBD user-space support is not implemented in swtpm (yet). Workaround would be to always enable krbd for TPM state volumes. This is an issue in general, as swtpm currently only works with files/devices that have an entry in the file system hierarchy. An interesting way around some of these issues would be NDB support in swtpm and accessing the backing store via QEMU's driver stack. RFC v1 -> RFC v2: * with the above PR, we can store state in a single file/block device, thus we can treat it similar to an efidisk - this eliminates any concerns about storing on pmxcfs * always allocate the state as 4 MiB (on directory storage it might auto-shrink) * fixes migration, since source and destination are now different * add GUI patch edk2-firmware: Stefan Reiter (1): enable TPM and TPM2 support debian/rules | 4 ++++ 1 file changed, 4 insertions(+) storage: Stefan Reiter (1): import: don't check for 1K aligned size PVE/Storage/Plugin.pm | 1 - 1 file changed, 1 deletion(-) qemu-server: Stefan Reiter (1): fix #3075: add TPM v1.2 and v2.0 support via swtpm PVE/API2/Qemu.pm | 5 ++ PVE/QemuMigrate.pm | 14 ++++- PVE/QemuServer.pm | 135 +++++++++++++++++++++++++++++++++++++--- PVE/QemuServer/Drive.pm | 63 +++++++++++++++---- 4 files changed, 198 insertions(+), 19 deletions(-) manager: Stefan Reiter (1): ui: add support for adding TPM devices www/manager6/Makefile | 1 + www/manager6/Utils.js | 2 +- www/manager6/form/DiskStorageSelector.js | 5 +- www/manager6/qemu/HDMove.js | 1 + www/manager6/qemu/HDTPM.js | 88 ++++++++++++++++++++++++ www/manager6/qemu/HardwareView.js | 25 ++++++- 6 files changed, 119 insertions(+), 3 deletions(-) create mode 100644 www/manager6/qemu/HDTPM.js -- 2.30.2