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=-2.2 required=3.0 tests=FROM_EXCESS_BASE64, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,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 5B2AAC3A5A3 for ; Tue, 27 Aug 2019 10:53:42 +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 2F66B20656 for ; Tue, 27 Aug 2019 10:53:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2F66B20656 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]:49536 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2Z6b-0007Xf-DB for qemu-devel@archiver.kernel.org; Tue, 27 Aug 2019 06:53:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35522) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2Z5d-0006ht-H4 for qemu-devel@nongnu.org; Tue, 27 Aug 2019 06:52:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i2Z5b-0005Fn-Kr for qemu-devel@nongnu.org; Tue, 27 Aug 2019 06:52:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46900) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i2Z5Z-0005Ed-52; Tue, 27 Aug 2019 06:52:37 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 67FFF46; Tue, 27 Aug 2019 10:52:36 +0000 (UTC) Received: from redhat.com (ovpn-112-56.ams2.redhat.com [10.36.112.56]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4045C60C05; Tue, 27 Aug 2019 10:52:29 +0000 (UTC) Date: Tue, 27 Aug 2019 11:52:26 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Maxim Levitsky Message-ID: <20190827105226.GI16500@redhat.com> References: <20190826135103.22410-1-mlevitsk@redhat.com> <20190826135103.22410-2-mlevitsk@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190826135103.22410-2-mlevitsk@redhat.com> User-Agent: Mutt/1.12.1 (2019-06-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.71]); Tue, 27 Aug 2019 10:52:36 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [PATCH v2 01/13] introduce g_autowipe 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: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: Kevin Wolf , Fam Zheng , qemu-block@nongnu.org, Markus Armbruster , qemu-devel@nongnu.org, Max Reitz , Stefan Hajnoczi Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Mon, Aug 26, 2019 at 04:50:51PM +0300, Maxim Levitsky wrote: > Marking a pointer with g_autowipe, will > not only free it at the scope exit, but also > erase the data it points to just prior to freeing it. > > This is first attempt to implement this feature, > as suggested by Daniel and Nir. > > The things that need to be verified prior to merging this is > > 1. Can we just always use memset_s (defined in C++) > or some alternative. > > 2. is it portable enought for us to use malloc_usable_size > to get the size of malloced pointer in the autofree callback? > This function is aviable in glibc (but no wrapper in glib). Urgh, no, we can't rely on that. I completely forgot that we would need to know the size during the deallocate function. The portable way to deal with this will be to change all our code that handles passwords to use GString instead, since that is a struct carrying around the allocated size. As mentioned in v1, I'm fine if you just let this series use memset as this is a pre-existing problem & we can fix it in separate yseries. 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 :|