From nobody Sun Oct 5 21:17:17 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1580492807487760.0987498323008; Fri, 31 Jan 2020 09:46:47 -0800 (PST) Received: from localhost ([::1]:57208 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ixaNS-0005UK-Bd for importer@patchew.org; Fri, 31 Jan 2020 12:46:46 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41315) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ixaLa-0002gO-AP for qemu-devel@nongnu.org; Fri, 31 Jan 2020 12:44:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ixaLY-0004OM-VX for qemu-devel@nongnu.org; Fri, 31 Jan 2020 12:44:50 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:20904 helo=us-smtp-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ixaLY-0004Nf-Pi for qemu-devel@nongnu.org; Fri, 31 Jan 2020 12:44:48 -0500 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-415-5TsUAxCrOmeiVtF9B3E9pA-1; Fri, 31 Jan 2020 12:44:43 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6BEE01937FC5; Fri, 31 Jan 2020 17:44:42 +0000 (UTC) Received: from blue.redhat.com (ovpn-116-181.phx2.redhat.com [10.3.116.181]) by smtp.corp.redhat.com (Postfix) with ESMTP id EEF1584BCE; Fri, 31 Jan 2020 17:44:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580492688; h=from:from: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=bKI/xOJyK4CEKumsYglI3UK/B8/0BuSux4WShyruRtU=; b=gMrWUDp21dmatYcclw3QRCEJ6vRQoGH+iaXED1ALKH8t/XmQgcw5cxvUCYZpiFII9E5L1i 3Xsvfzrn+bZpL/N7wm8GBPaOpka2h5kqgVSb1I291+mLQpeVqEg9+MtWUBUjyPR1xrXUCc UU2/b/qElbpfa6iSuf7tcrMpV9vyKqc= From: Eric Blake To: qemu-devel@nongnu.org Subject: [PATCH 05/17] block: Don't advertise zero_init_truncate with encryption Date: Fri, 31 Jan 2020 11:44:24 -0600 Message-Id: <20200131174436.2961874-6-eblake@redhat.com> In-Reply-To: <20200131174436.2961874-1-eblake@redhat.com> References: <20200131174436.2961874-1-eblake@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: 5TsUAxCrOmeiVtF9B3E9pA-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 207.211.31.120 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: david.edmondson@oracle.com, Kevin Wolf , qemu-block@nongnu.org, mreitz@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) Content-Type: text/plain; charset="utf-8" Commit 38841dcd correctly argued that having qcow2 blindly return 1 for .bdrv_has_zero_init() is wrong for preallocated images built on block devices, while .bdrv_has_zero_init_truncate() can still return 1 because it is only relied on when changing size with PREALLOC_MODE_OFF (and this is true even for v2 images which lack the notion of an explicit zero cluster, since the block layer already filters out the case of a larger backing file leaking through). However, it missed the fact that encrypted images do not default to reading as zero in any case. However, instead of changing qcow2's .bdrv_has_zero_init_truncate() to point to a one-off function that special-cases bs->encryption, it is smarter to just move the logic about encryption directly to the block layer (that is, the driver callbacks will never be invoked for encrypted images, just like they are already not called when a backing file is present). This solution fixes the qcow2 issue, has no effect on the crypto driver (which already lacks .bdrv_has_zero_init* callbacks), and no other driver currently uses bs->encrypted. One other reason to fix this at the block layer: any information we expose about an encrypted image that in turn may alter timing of algorithms run on that image can be considered a (slight) information leak; refusing to optimize zero handling of encrypted images thus avoids the possibility of that being a security concern. Signed-off-by: Eric Blake Reviewed-by: Alberto Garcia --- block.c | 19 ++++++++++++++++--- block/qcow2.c | 2 -- 2 files changed, 16 insertions(+), 5 deletions(-) diff --git a/block.c b/block.c index 6c2b2bd2e292..296845040e59 100644 --- a/block.c +++ b/block.c @@ -5077,9 +5077,12 @@ int bdrv_has_zero_init(BlockDriverState *bs) return 0; } - /* If BS is a copy on write image, it is initialized to - the contents of the base image, which may not be zeroes. */ - if (bs->backing) { + /* + * If BS is a copy on write image, it is initialized to the + * contents of the base image, which may not be zeroes. Likewise, + * encrypted images do not read as zero. + */ + if (bs->backing || bs->encrypted) { return 0; } if (bs->drv->bdrv_has_zero_init) { @@ -5099,6 +5102,16 @@ int bdrv_has_zero_init_truncate(BlockDriverState *bs) return 0; } + /* + * Encrypted images never default to reading all zero; and even if + * they did, advertising that fact might lead to an information + * leak based on timing comparisons of algorithms that change if + * our result were dynamic. + */ + if (bs->encrypted) { + return 0; + } + if (bs->backing) { /* Depends on the backing image length, but better safe than sorry= */ return 0; diff --git a/block/qcow2.c b/block/qcow2.c index 6ea06dbdf48a..40aa751d1de7 100644 --- a/block/qcow2.c +++ b/block/qcow2.c @@ -4934,8 +4934,6 @@ static int qcow2_has_zero_init(BlockDriverState *bs) if (!preallocated) { return 1; - } else if (bs->encrypted) { - return 0; } else { return bdrv_has_zero_init(s->data_file->bs); } --=20 2.24.1