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 lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 23279C4332F for ; Wed, 16 Nov 2022 10:24:17 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ovFaU-0008CN-Vi; Wed, 16 Nov 2022 05:24:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ovFaQ-0008AX-G2 for qemu-devel@nongnu.org; Wed, 16 Nov 2022 05:24:09 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ovFaO-00074Q-MN for qemu-devel@nongnu.org; Wed, 16 Nov 2022 05:24:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668594243; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=c5tnaB31rzTGFJptRCFW8hafGU2XOB4ZQzH84n+GloY=; b=RLA5FapSGI4FyYbev3f1l4Bqc2bEMTRtShPlZTqhlmFVaQuTomcx2wRobTFPrsB0AUe23D WZWKjRWG+HcRQka6y6dgeulxrNnjOYgIjk9YEqkcBKNRucwKyUo6uBrkrt5HiWYnnGXldM kUO9KSoOlM04hJryPwak3zltzuA7foo= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-201-d_H73gTeMEirExYrU9EftA-1; Wed, 16 Nov 2022 05:23:58 -0500 X-MC-Unique: d_H73gTeMEirExYrU9EftA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A0BAB884361; Wed, 16 Nov 2022 10:23:57 +0000 (UTC) Received: from redhat.com (unknown [10.33.36.81]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 902202024CCA; Wed, 16 Nov 2022 10:23:56 +0000 (UTC) Date: Wed, 16 Nov 2022 10:23:52 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Or Ozeri Cc: "qemu-devel@nongnu.org" , "qemu-block@nongnu.org" , Danny Harnik , "idryomov@gmail.com" Subject: Re: [PATCH v3] block/rbd: Add support for layered encryption Message-ID: References: <20221115122527.2896476-1-oro@il.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.2.7 (2022-08-07) X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 Received-SPF: pass client-ip=170.10.129.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org On Wed, Nov 16, 2022 at 09:03:31AM +0000, Or Ozeri wrote: > > -----Original Message----- > > From: Daniel P. Berrangé > > Sent: 15 November 2022 19:47 > > To: Or Ozeri > > Cc: qemu-devel@nongnu.org; qemu-block@nongnu.org; Danny Harnik > > ; idryomov@gmail.com > > Subject: [EXTERNAL] Re: [PATCH v3] block/rbd: Add support for layered > > encryption > > > > AFAICT, supporting layered encryption shouldn't require anything other than > > the 'parent' addition. > > > > Since the layered encryption API is new in librbd, we don't have to > support "luks" and "luks2" at all. > In librbd we are actually deprecating the use of "luks" and "luks2", > and instead ask users to use "luks-any". Deprecating that is a bad idea. The security characteristics and feature set of LUKSv1 and LUKSv2 can be quite different. If a mgmt app is expecting the volume to be protected with LUKSv2, it should be stating that explicitly and not permit a silent downgrade if the volume was unexpectedly using LUKSv1. > If we don't add "luks-any" here, we will need to implement > explicit cases for "luks" and "luks2" in the qemu_rbd_encryption_load2. > This looks like a kind of wasteful coding that won't be actually used > by users of the rbd driver in qemu. It isn't wasteful - supporting the formats explicitly is desirable to prevent format downgrades. > Anyhow, we need the "luks-any" option for our use-case, so if you > insist, I will first submit a patch to add "luks-any", before this > patch. I'm pretty wary of any kind of automatic encryption format detection in QEMU. The automatic block driver format probing has been a long standing source of CVEs in QEMU and every single mgmt app above QEMU. What is the problem with specifying the desired LUKS format explicitly. The mgmt app should know what formats it wants to be using. It should be possible to query format for existing volumes too. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|