From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E4FF381D36 for ; Thu, 3 Nov 2016 11:10:45 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4AD76C04B31B; Thu, 3 Nov 2016 18:10:47 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-178.phx2.redhat.com [10.3.116.178]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uA3IAiuu026441; Thu, 3 Nov 2016 14:10:44 -0400 To: Ard Biesheuvel References: <1478194274-16524-1-git-send-email-ard.biesheuvel@linaro.org> <35e6e483-afcf-b735-c3ef-55236ac83423@redhat.com> Cc: "edk2-devel@lists.01.org" , "Kinney, Michael D" , "Gao, Liming" From: Laszlo Ersek Message-ID: <7b9acc46-3670-bf1b-7e11-740deb57f5fc@redhat.com> Date: Thu, 3 Nov 2016 19:10:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 03 Nov 2016 18:10:47 +0000 (UTC) Subject: Re: [PATCH] MdePkg/BaseMemoryLibOptDxe: check for zero length in ZeroMem () X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 18:10:46 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 11/03/16 19:05, Ard Biesheuvel wrote: > On 3 November 2016 at 17:38, Laszlo Ersek wrote: >> On 11/03/16 18:31, Ard Biesheuvel wrote: >>> Unlike other string functions in this library, ZeroMem () does not >>> return early when the length of the input buffer is 0. So add the >>> same to ZeroMem () as well. >>> >>> Contributed-under: TianoCore Contribution Agreement 1.0 >>> Signed-off-by: Ard Biesheuvel >>> --- >>> MdePkg/Library/BaseMemoryLibOptDxe/ZeroMemWrapper.c | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/MdePkg/Library/BaseMemoryLibOptDxe/ZeroMemWrapper.c b/MdePkg/Library/BaseMemoryLibOptDxe/ZeroMemWrapper.c >>> index 2a0a038fd6c5..fbc2f5742c8c 100644 >>> --- a/MdePkg/Library/BaseMemoryLibOptDxe/ZeroMemWrapper.c >>> +++ b/MdePkg/Library/BaseMemoryLibOptDxe/ZeroMemWrapper.c >>> @@ -46,6 +46,10 @@ ZeroMem ( >>> IN UINTN Length >>> ) >>> { >>> + if (Length == 0) { >>> + return Buffer; >>> + } >>> + >>> ASSERT (!(Buffer == NULL && Length > 0)); >>> ASSERT (Length <= (MAX_ADDRESS - (UINTN)Buffer + 1)); >>> return InternalMemZeroMem (Buffer, Length); >>> >> >> 1. Why is this necessary? >> > > The 32-bit accelerated ARM code writes at least one byte, Does that conform to the InternalMemZeroMem() contract? > and given > that the other string functions take the same shortcut, this seemed > the most appropriate way to fix that. I don't disagree, but then the commit message should explain this -- the circumstances where the missing shortcut actually caused a problem. > >> 2. After the new check, Length is guaranteed to be positive. The first >> ASSERT() should be updated (simplified), I think: >> >> ASSERT (Buffer != NULL); >> > > Good point. I will change that > Thanks! Laszlo