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 AC8FE656EC for ; Thu, 23 Jul 2020 12:43:40 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 9EF8D28315 for ; Thu, 23 Jul 2020 12:43:10 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (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 89F352830B for ; Thu, 23 Jul 2020 12:43:09 +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 4668142F22 for ; Thu, 23 Jul 2020 12:43:09 +0200 (CEST) To: =?UTF-8?Q?Fabian_Gr=c3=bcnbichler?= , Proxmox VE development discussion References: <20200723092136.2527542-1-f.gruenbichler@proxmox.com> <4e2552b4-8ea8-6252-f58e-f22e08d55ec4@proxmox.com> <1595499980.xeb6wkgs4y.astroid@nora.none> From: Stefan Reiter Message-ID: <2141b2d4-df90-1235-7755-83c1440911c2@proxmox.com> Date: Thu, 23 Jul 2020 12:43:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <1595499980.xeb6wkgs4y.astroid@nora.none> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.836 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -1.703 Looks like a legit reply (A) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust 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] [PATCH proxmox-backup-qemu] fix #2866: invalidate bitmap on crypt_mode change 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: Thu, 23 Jul 2020 10:43:40 -0000 On 7/23/20 12:34 PM, Fabian Grünbichler wrote: > On July 23, 2020 12:07 pm, Stefan Reiter wrote: >> idea looks ok, comments inline >> >> On 7/23/20 11:21 AM, Fabian Grünbichler wrote: >>> signed and plain backups share chunks, so bitmap reusal is okay for >>> those combinations. switching from encrypted to not encrypted or >>> vice-versa could have pretty fatal consequences - either referencing >>> plain-text chunks in 'encrypted' backups, or referencing encrypted >>> chunks in 'unencrypted' backups without still having the corresponding >>> keys.. >>> >>> Signed-off-by: Fabian Grünbichler >>> --- >>> >>> Notes: >>> requires recent proxmox-backup with public lookup_file_info >>> >>> src/backup.rs | 3 ++- >>> src/commands.rs | 35 +++++++++++++++++++++++++++++++++-- >>> 2 files changed, 35 insertions(+), 3 deletions(-) >>> >>> diff --git a/src/backup.rs b/src/backup.rs >>> index 717e099..b8108ef 100644 >>> --- a/src/backup.rs >>> +++ b/src/backup.rs >>> @@ -202,7 +202,8 @@ impl BackupTask { >>> device_name: String, >>> size: u64, >>> ) -> bool { >>> - check_last_incremental_csum(self.last_manifest(), device_name, size) >>> + check_last_incremental_csum(self.last_manifest(), &device_name, size) >>> + && check_last_encryption_mode(self.last_manifest(), &device_name, self.crypt_mode) >>> } >>> >>> pub async fn register_image( >>> diff --git a/src/commands.rs b/src/commands.rs >>> index 6f26324..8d8f2a7 100644 >>> --- a/src/commands.rs >>> +++ b/src/commands.rs >>> @@ -80,7 +80,7 @@ pub(crate) async fn add_config( >>> >>> pub(crate) fn check_last_incremental_csum( >>> manifest: Option>, >>> - device_name: String, >>> + device_name: &str, >>> device_size: u64, >>> ) -> bool { >>> >>> @@ -91,12 +91,43 @@ pub(crate) fn check_last_incremental_csum( >>> >>> let archive_name = format!("{}.img.fidx", device_name); >>> >>> - match PREVIOUS_CSUMS.lock().unwrap().get(&device_name) { >>> + match PREVIOUS_CSUMS.lock().unwrap().get(device_name) { >>> Some(csum) => manifest.verify_file(&archive_name, &csum, device_size).is_ok(), >>> None => false, >>> } >>> } >>> >>> +pub(crate) fn check_last_encryption_mode( >>> + manifest: Option>, >>> + device_name: &str, >>> + crypt_mode: CryptMode, >>> +) -> bool { >>> + >>> + let manifest = match manifest { >>> + Some(ref manifest) => manifest, >>> + None => return false, >>> + }; >> >> this... >> >>> + >>> + let archive_name = format!("{}.img.fidx", device_name); >> >> ...and this could probably be moved to check_incremental to avoid >> duplication. > > probably device to archive name could also be refactored into a helper? > with this patch we have three identical format! calls.. > would make sense, or at least encode the .img.fidx in a constant somewhere >> >>> + match manifest.lookup_file_info(&archive_name) { >>> + Ok(file) => { >>> + eprintln!("device {} last mode: {:?} current mode {:?}", device_name, file.crypt_mode, crypt_mode); >> >> left over debug print or intentional? this would be hidden atm, as we >> don't track QEMU output anywhere. > > both :-P I figured with all the issues we had with encrypted backups, > telling users to start in the foreground and watch the output might be > helpful. but I'm fine with dropping it. > I suppose this would be a good point to ping this patch of mine: https://lists.proxmox.com/pipermail/pve-devel/2020-June/044143.html Though in case we want to actually use it this way, maybe even a bit more logging would be good? >> >>> + match file.crypt_mode { >>> + CryptMode::Encrypt => match crypt_mode { >>> + CryptMode::Encrypt => true, >>> + _ => false, >>> + }, >>> + CryptMode::SignOnly | CryptMode::None => match crypt_mode { >> >> you can use the _ match here too, same as in the inner match call. > > intentional, if we add a new CryptMode in proxmox-backup this forces us > to match it here unless I misunderstood how match on enums works in > Rust. > makes sense, though should probably be mentioned somewhere so no one "optimizes" it away in the future. >> >>> + CryptMode::Encrypt => false, >>> + _ => true, >>> + }, >>> + } >>> + }, >>> + _ => false, >>> + } >>> +} >>> + >>> + >>> pub(crate) async fn register_image( >>> client: Arc, >>> crypt_config: Option>, >>> >>