From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 2F7F33858CDA for ; Fri, 22 Dec 2023 04:36:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2F7F33858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2F7F33858CDA Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703219775; cv=none; b=S/MbH6CAyGgd1ND9lABK7VPH1PhrvAh/ia+EAGIMo8x1IE/l9zJVVs/HwYfAggdzX1efiybP+emyNrItwfhIMSIdzF881UqsULt1uN6iQ0yNQ0PTF97FTE9bSA4BKr+OAal/ZMpcmRJt5yNzuEk9tIpwCuMpmQKA5fudgLMs4NM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703219775; c=relaxed/simple; bh=tVPp7Q904+fTZaXAamjWKM6lE/2VY7VTZ9IRY/pHcyk=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=RxNtxqpbKABpbY6aBlc+pi6KuoJYRk2YkXnC11AwrUO+8mqFaVyCcfJA2lkmNl+CtvM23JAcAz18VMb1urq+L+kyxelbSES2/NfynS5lA8XaQlEZwC8cklie2oC1A6rni/XCsqck4tJHLg+1daxzj7SqbOAcHfDdrSNsMjTG3y0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1703219773; bh=tVPp7Q904+fTZaXAamjWKM6lE/2VY7VTZ9IRY/pHcyk=; h=Date:Subject:To:References:From:In-Reply-To:From; b=bHj4eImXkJGQtaaeF/B+R8VwDsqILxjkmAUaMBBgFdEqUmINRIJp+IW0pkWmUTv1l KO2nnv4jOvr5NBHg7oQq49M2bKKiZSMFSuaIx6jOtA+va4RG6Dh2xk3PIIU3ONIYTC Mlb9/X/m+hYpy7g+m45oF1eb4z9C5DQdfasmQ9Ek= Received: from [10.0.0.11] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 9280B1E091; Thu, 21 Dec 2023 23:36:13 -0500 (EST) Message-ID: Date: Thu, 21 Dec 2023 23:36:12 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 22/26] gdbserver: zero-out register values in regcache-discard Content-Language: en-US To: Tankut Baris Aktemur , gdb-patches@sourceware.org References: <877c74ccb7fb99d36242d9246d2824f181752a5a.1677582745.git.tankut.baris.aktemur@intel.com> From: Simon Marchi In-Reply-To: <877c74ccb7fb99d36242d9246d2824f181752a5a.1677582745.git.tankut.baris.aktemur@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2023-02-28 06:28, Tankut Baris Aktemur via Gdb-patches wrote: > Zero-out register values when a regcache is discarded so that we avoid > garbage values left in the buffer. > --- > gdbserver/regcache.cc | 12 +++++++----- > 1 file changed, 7 insertions(+), 5 deletions(-) > > diff --git a/gdbserver/regcache.cc b/gdbserver/regcache.cc > index 2befb30e337..644f436c681 100644 > --- a/gdbserver/regcache.cc > +++ b/gdbserver/regcache.cc > @@ -136,6 +136,7 @@ regcache_invalidate (void) > void > regcache::discard () > { > + memset (registers, 0, tdesc->registers_size); > #ifndef IN_PROCESS_AGENT > memset ((void *) register_status, REG_UNKNOWN, tdesc->reg_defs.size ()); > #endif > @@ -149,16 +150,17 @@ regcache::initialize (const target_desc *tdesc, > if (regbuf == NULL) > { > #ifndef IN_PROCESS_AGENT > - /* Make sure to zero-initialize the register cache when it is > - created, in case there are registers the target never > - fetches. This way they'll read as zero instead of > - garbage. */ > this->tdesc = tdesc; > this->registers > - = (unsigned char *) xcalloc (1, tdesc->registers_size); > + = (unsigned char *) xmalloc (tdesc->registers_size); > this->registers_owned = true; > this->register_status > = (enum register_status *) xmalloc (tdesc->reg_defs.size ()); > + > + /* Make sure to zero-initialize the register cache when it is > + created, in case there are registers the target never > + fetches. This way they'll read as zero instead of > + garbage. */ > discard (); > #else > gdb_assert_not_reached ("can't allocate memory from the heap"); Just curious, if we read and use the contents of a register that isn't REG_VALID, it's a bug, right? If so, shouldn't we instead make sure this never happens? After all, for a register that is not REG_VALID, a value of 0 is just as much a "garbage value" as any other value. Simon