From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Tue, 13 Jan 2015 07:05:09 +0100 Subject: [U-Boot] [PATCH] cmd_sf: Fix problem with "sf update" and unaligned length In-Reply-To: <20150112211034.AC27C384DF9@gemini.denx.de> References: <1420810762-10712-1-git-send-email-sr@denx.de> <20150112071719.055CB38005C@gemini.denx.de> <54B37759.7040801@denx.de> <20150112211034.AC27C384DF9@gemini.denx.de> Message-ID: <54B4B595.5000703@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Wolfgang, On 12.01.2015 22:10, Wolfgang Denk wrote: >>> Should we add a memset(buf, 0, sizeof(buf)) before the memcpy() to >>> prevent information from earlier activities to leak? >> >> "buf" points to the new data to be written into the flash. We're >> overwriting the first "len" bytes of "cmp_buf" with this data. > > Oh, sorry for the mixup. Then cmp_buf should be cleared (or at elast > the remaining, unused part). No. cmp_buf contains the original data from the flash. And only the beginning of this buffer is overwritten with the new data from "buf". So, the result of the memcpy() is that "cmp_buf" contains the data that should be written into the flash. Its a combination of the "original data" and the "new data". >> I don't see why we should erase anything there. Perhaps I'm missing >> something though. > > You are leaking data. This could contain "interesting" information; > see the OpenSSL ?Heartbleed? vulnerability for a (nasty) example what > information leakage can do. There is nothing leaking here. When anything would be zeroed out, the resulting buffer would not be the one that should be used. Viele Gr??e, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de