From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 431E676926 for ; Fri, 16 Jul 2021 11:48:28 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 409E9EF52 for ; Fri, 16 Jul 2021 11:48:28 +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 69C7BEF44 for ; Fri, 16 Jul 2021 11:48:27 +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 4100941F9E for ; Fri, 16 Jul 2021 11:48:27 +0200 (CEST) Message-ID: Date: Fri, 16 Jul 2021 11:48:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.0 Content-Language: en-US To: Proxmox VE development discussion , Stefan Reiter References: <20210715142319.1457131-1-s.reiter@proxmox.com> From: Thomas Lamprecht In-Reply-To: <20210715142319.1457131-1-s.reiter@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.438 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 NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [RFC 0/2] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 09:48:28 -0000 On 15.07.21 16:23, Stefan Reiter wrote: > Design decision: 'swtpm' requires a *directory* per VM to store data, the files > themselves are rather small (8.5kB for an initialized TPM 2.0 w/ BitLocker > enabled). To allow for easier HA I went with a path in '/etc/pve/priv' for now, > but that comes with it's own drawbacks. For example, a guest may write TPM state > as often as they like, and Windows seems to do so every few seconds at random. > (note: swtpm writes a temporary file and then uses atomic replace) > > Other ideas for this: > * store in regular path, e.g. '/var/lib' - how to do HA? (note that > live-migration works regardless, since the state is transferred via QEMU) > * treat like efidisk and allow any storage - would be my favourite, but as said, > swtpm requires a directory, not a single file... > > Missing feature/known issues: > * backups and offline-snapshots don't include TPM data > * migration may hickup, since destination and target are effectively "the same" > * needs improved clearing logic, or potentially none at all (would be a benefit > for the "efidisk-like" variant) For the record, I talked about this with Stefan yesterday before he left for vacation, and while the size seems pretty much OK for a file on pmxcfs the frequent updates are just a no go, so that approach is NAK'd (not only be me, Dietmar voiced his objections too). I recommended asking swtpm upstream if they'd accept options for passing a explicit TPM state-file and a separate run-state dir for the swtpm locks and state (we wouldn't even need the swtmp locks as access synchronization of the state-file would be already by the pve-storage stack locks, but I do not care much for those as there'd be no contention anyway). Then we can put the actual state on a volume similar to EFI disks and the ephemeral run-state somewhere in "/run/qemu-server/$vmid.swtpm/", with that we got snapshots, migrations (when local storage is used) and backups covered to rather easily. If upstream is reluctant then an idea would be to either patch it ourself or use the libtpms to write a replacement tool in rust, but as said, I'd always try to discuss our needs with upstream first - IMO other (clustered) hyper-visor systems won't be to happy as is either.