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 X-Spam-Level: X-Spam-Status: No, score=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4FB6DC433E0 for ; Tue, 23 Feb 2021 08:47:44 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id C289164E3F for ; Tue, 23 Feb 2021 08:47:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C289164E3F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:33108 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lETM6-0006D8-Oz for qemu-devel@archiver.kernel.org; Tue, 23 Feb 2021 03:47:42 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38334) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lETJj-0004xZ-6w for qemu-devel@nongnu.org; Tue, 23 Feb 2021 03:45:15 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:58057) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1lETJh-0008Ep-1x for qemu-devel@nongnu.org; Tue, 23 Feb 2021 03:45:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614069912; 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=B4zr+ibQKMvt3BQjvIVWipfgOo9oivRQ+wLnFjTwYM0=; b=e19YRPH73vrTH3SounCdD7XgN4n4ev+pGzxpuX9DM105C6fl6nA2qiF3lY+jEZqxJq+HIR b6XiONe7u10QuyV5xiIOBn3Uuvij1m+ubWVziao1zwoUo5MMPsQKi0y1KFV+QR4Rrj84Ol DP/K6bXiQdZsjOSVTZAx8+t9XUxhHzI= 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-518-rFLz-YwwNVCx7Y0ugZPuRg-1; Tue, 23 Feb 2021 03:45:07 -0500 X-MC-Unique: rFLz-YwwNVCx7Y0ugZPuRg-1 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 ED52A107ACED; Tue, 23 Feb 2021 08:45:05 +0000 (UTC) Received: from dresden.str.redhat.com (ovpn-114-44.ams2.redhat.com [10.36.114.44]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B4B5570476; Tue, 23 Feb 2021 08:44:53 +0000 (UTC) Subject: Re: [PATCH v2 0/2] block: Use 'read-zeroes=true' mode by default with 'null-co' driver To: =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= References: <20210211142656.3818078-1-philmd@redhat.com> <20210213215448.GA67780@ip-172-44-255-31> <3da6a2aa-472e-d9e1-b803-303891513274@redhat.com> <38dd38eb-af59-8baf-b908-fb6c4e842cd1@redhat.com> From: Max Reitz Message-ID: Date: Tue, 23 Feb 2021 09:44:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mreitz@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=63.128.21.124; envelope-from=mreitz@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Fam Zheng , Laurent Vivier , Thomas Huth , qemu-block@nongnu.org, qemu-devel@nongnu.org, Wainer dos Santos Moschetta , Markus Armbruster , Alexander Bulekov , Bandan Das , Paolo Bonzini , Stefan Hajnoczi , Cleber Rosa , Kevin Wolf Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 22.02.21 19:15, Daniel P. Berrangé wrote: > On Fri, Feb 19, 2021 at 03:09:43PM +0100, Philippe Mathieu-Daudé wrote: >> On 2/19/21 12:07 PM, Max Reitz wrote: >>> On 13.02.21 22:54, Fam Zheng wrote: >>>> On 2021-02-11 15:26, Philippe Mathieu-Daudé wrote: >>>>> The null-co driver doesn't zeroize buffer in its default config, >>>>> because it is designed for testing and tests want to run fast. >>>>> However this confuses security researchers (access to uninit >>>>> buffers). >>>> >>>> I'm a little surprised. >>>> >>>> Is changing default the only way to fix this? I'm not opposed to >>>> changing the default but I'm not convinced this is the easiest way. >>>> block/nvme.c also doesn't touch the memory, but defers to the device >>>> DMA, why doesn't that confuse the security checker? >> >> Generally speaking, there is a balance between security and performance. >> We try to provide both, but when we can't, my understanding is security >> is more important. >> >> Customers expect a secure product. If they prefer performance and >> at the price of security, it is also possible by enabling an option >> that is not the default. >> >> I'm not sure why you mention block/nvme here. I have the understanding >> the null-co driver is only useful for testing. Are there production >> cases where null-co is used? > > Do we have any real world figures for the performance of null-co > with & without zero'ing ? Before worrying about a tradeoff of > security vs performance, it'd be good to know if there is actually > a real world performance problem in the first place. Personally I'd > go for zero'ing by defualt unless the performance hit was really > bad. AFAIU, null-co is only used for testing, be it to just create some block nodes in the iotests, or perhaps for performance testing where you want to get the minimal roundtrip time through the block layer. So there is no "real world performance problem", because there is no real world use of null-co or null-aio. At least there shouldn’t be. That begs the question of whether read-zeroes=off even makes sense, and I think it absolutely does. In cases where we have a test that just wants a simple block node that doesn’t use disk space, the memset() can’t be noticeable. But it’s just a test, so do we even need the memset()? Strictly speaking, perhaps not, but if someone is to run it via Valgrind or something, they may get false positives, so just doing the memset() is the right thing to do. For performance tests, it must be possible to set read-zeroes=off, because even though “that memset() isn’t noticeable in a functional test”, in a hard-core performance test, it will be. So we need a switch. It should default to memset(), because (1) making tools like Valgrind happy seems like a reasonable objective to me, and (2) in the majority of cases, the memset() cannot have a noticeable impact. Max