From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 41650D811A4 for ; Tue, 9 Jan 2024 09:04:59 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=u75ajauhkZVnn8/thdm/Tg8Ot2wCzoQUSMnwEq2jJmg=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1704791097; v=1; b=pTrGLoswSv50TI+9XuSrKHjZ+24I5FRk2D2lOWbiS1hjHbutvTxQ9awhqvyhnpl6Ute6wD21 nEKUs/Jhq8ZN/gCNCn/MG2D28pAXUnfXDB96N7qqOM4XaeFpiD7LVjRG7BwKua7/cVU9KOAx66d OH2jGbNMbfRiI93OQqdWD54Q= X-Received: by 127.0.0.2 with SMTP id OdXGYY7687511xbqtDeWJpUw; Tue, 09 Jan 2024 01:04:57 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web10.12867.1704791097154414428 for ; Tue, 09 Jan 2024 01:04:57 -0800 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-447-NSrqZutiN2KRTdPyQjHGHw-1; Tue, 09 Jan 2024 04:04:54 -0500 X-MC-Unique: NSrqZutiN2KRTdPyQjHGHw-1 X-Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 012CE811E9C; Tue, 9 Jan 2024 09:04:54 +0000 (UTC) X-Received: from [10.39.193.97] (unknown [10.39.193.97]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C4963492BC7; Tue, 9 Jan 2024 09:04:52 +0000 (UTC) Message-ID: <58031d49-3ab0-8df7-ebfd-251aeb92eca0@redhat.com> Date: Tue, 9 Jan 2024 10:04:51 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH v4 3/3] OvmfPkg/VirtNorFlashDxe: sanity-check variables To: Gerd Hoffmann , devel@edk2.groups.io Cc: oliver@redhat.com, Jiewen Yao , Ard Biesheuvel , Sunil V L , Andrei Warkentin References: <20240108192123.42359-1-kraxel@redhat.com> <20240108192123.42359-4-kraxel@redhat.com> From: "Laszlo Ersek" In-Reply-To: <20240108192123.42359-4-kraxel@redhat.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: NJN47PuQPUAgALPBAbZt1Esxx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=pTrGLosw; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none) On 1/8/24 20:21, Gerd Hoffmann wrote: > Extend the ValidateFvHeader function, additionally to the header checks > walk over the list of variables and sanity check them. >=20 > In case we find inconsistencies indicating variable store corruption > return EFI_NOT_FOUND so the variable store will be re-initialized. >=20 > Signed-off-by: Gerd Hoffmann > --- > OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf | 1 + > OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c | 139 +++++++++++++++++++- > 2 files changed, 135 insertions(+), 5 deletions(-) >=20 > diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf b/OvmfPkg/VirtNo= rFlashDxe/VirtNorFlashDxe.inf > index 2a3d4a218e61..f549400280a1 100644 > --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf > +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf > @@ -34,6 +34,7 @@ [LibraryClasses] > DxeServicesTableLib > HobLib > IoLib > + SafeIntLib > UefiBootServicesTableLib > UefiDriverEntryPoint > UefiLib > diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c b/OvmfPkg/VirtNorF= lashDxe/VirtNorFlashFvb.c > index 9a614ae4b24d..56148e9f1f95 100644 > --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c > +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c > @@ -12,6 +12,7 @@ > #include > #include > #include > +#include > #include > =20 > #include > @@ -185,11 +186,13 @@ ValidateFvHeader ( > IN NOR_FLASH_INSTANCE *Instance > ) > { > - UINT16 Checksum; > - EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader; > - VARIABLE_STORE_HEADER *VariableStoreHeader; > - UINTN VariableStoreLength; > - UINTN FvLength; > + UINT16 Checksum; > + CONST EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader; > + CONST VARIABLE_STORE_HEADER *VariableStoreHeader; > + UINTN VarOffset; > + UINTN VariableStoreLength; > + UINTN FvLength; > + RETURN_STATUS Status; (1) Status could have been moved in the "for" loop, AFAICT -- also mentioned in my previous review --, but it's not a sticking point. > =20 > FwVolHeader =3D (EFI_FIRMWARE_VOLUME_HEADER *)Instance->RegionBaseAddr= ess; > =20 > @@ -258,6 +261,132 @@ ValidateFvHeader ( > return EFI_NOT_FOUND; > } > =20 > + // > + // check variables > + // > + DEBUG ((DEBUG_INFO, "%a: checking variables\n", __func__)); > + VarOffset =3D sizeof (*VariableStoreHeader); > + for ( ; ;) { > + UINTN VarHeaderEnd; > + UINTN VarNameEnd; > + UINTN VarEnd; > + UINTN VarPadding; > + CONST AUTHENTICATED_VARIABLE_HEADER *VarHeader; > + CHAR16 *VarName; (2) Should have noticed in my previous review: VarName could be CONST-ified as well. Totally minor. > + CONST CHAR8 *VarState; > + > + Status =3D SafeUintnAdd (VarOffset, sizeof (*VarHeader), &VarHeaderE= nd); > + if (RETURN_ERROR (Status)) { > + DEBUG ((DEBUG_ERROR, "%a: integer overflow\n", __func__)); > + return EFI_NOT_FOUND; > + } > + > + if (VarHeaderEnd >=3D VariableStoreHeader->Size) { > + DEBUG ((DEBUG_INFO, "%a: end of var list (no space left)\n", __fun= c__)); > + break; > + } (3) I *still* don't understand this. In the v3 discussion: - we agreed that the ">" case was clearly unacceptable, - and you convinced me that the "=3D" case was also unacceptable (because that could only potentially accommodate a VAR_HEADER_VALID_ONLY state header without subsequent space for name & data, and we agreed that a var header like that, residing *permanently* in the varstore, was not acceptable). Fine: that's reason for keeping the unified ">=3D" condition. But my point in turn (which you didn't reflect upon, and seem not to have addressed in this patch) was that this condition means that the varstore is *bogus*, and should be reformatted. In my previous review I recommended that we replace the "break" here -- which leads to the function returning EFI_SUCCESS -- with "return EFI_NOT_FOUND" -- which causes the varstore to be reformatted. And then, as I wrote, the only successful exit from the loop would be the subsequent "break" below: > + > + VarHeader =3D (VOID *)((UINTN)VariableStoreHeader + VarOffset); > + if (VarHeader->StartId !=3D 0x55aa) { > + DEBUG ((DEBUG_INFO, "%a: end of var list (no startid)\n", __func__= )); > + break; > + } So: what's wrong with returning EFI_NOT_FOUND if VarHeaderEnd >=3D VariableStoreHeader->Size evaluates to true? > + > + VarName =3D NULL; > + switch (VarHeader->State) { > + // usage: State =3D VAR_HEADER_VALID_ONLY > + case VAR_HEADER_VALID_ONLY: > + VarState =3D "header-ok"; > + VarName =3D L""; > + break; > + > + // usage: State =3D VAR_ADDED > + case VAR_ADDED: > + VarState =3D "ok"; > + break; > + > + // usage: State &=3D VAR_IN_DELETED_TRANSITION > + case VAR_ADDED &VAR_IN_DELETED_TRANSITION: > + VarState =3D "del-in-transition"; > + break; > + > + // usage: State &=3D VAR_DELETED > + case VAR_ADDED &VAR_DELETED: > + case VAR_ADDED &VAR_DELETED &VAR_IN_DELETED_TRANSITION: > + VarState =3D "deleted"; > + break; > + > + default: > + DEBUG (( > + DEBUG_ERROR, > + "%a: invalid variable state: 0x%x\n", > + __func__, > + VarHeader->State > + )); > + return EFI_NOT_FOUND; > + } > + > + Status =3D SafeUintnAdd (VarHeaderEnd, VarHeader->NameSize, &VarName= End); > + if (RETURN_ERROR (Status)) { > + DEBUG ((DEBUG_ERROR, "%a: integer overflow\n", __func__)); > + return EFI_NOT_FOUND; > + } > + > + Status =3D SafeUintnAdd (VarNameEnd, VarHeader->DataSize, &VarEnd); > + if (RETURN_ERROR (Status)) { > + DEBUG ((DEBUG_ERROR, "%a: integer overflow\n", __func__)); > + return EFI_NOT_FOUND; > + } > + > + if (VarEnd > VariableStoreHeader->Size) { > + DEBUG (( > + DEBUG_ERROR, > + "%a: invalid variable size: 0x%Lx + 0x%Lx + 0x%x + 0x%x > 0x%x\n= ", > + __func__, > + (UINT64)VarOffset, > + (UINT64)(sizeof (*VarHeader)), > + VarHeader->NameSize, > + VarHeader->DataSize, > + VariableStoreHeader->Size > + )); > + return EFI_NOT_FOUND; > + } > + > + if ((VarHeader->NameSize & 1) || (4) Minor: I don't understand why uncrustify does not catch this, but the edk2 coding style requires us to spell this as (VarHeader->NameSize & 1) !=3D 0 to my understanding. Apologies for not noticing it in my previous review. > + (VarHeader->NameSize < 4)) > + { > + DEBUG ((DEBUG_ERROR, "%a: invalid name size\n", __func__)); > + return EFI_NOT_FOUND; > + } > + > + if (VarName =3D=3D NULL) { > + VarName =3D (VOID *)((UINTN)VariableStoreHeader + VarHeaderEnd); > + if (VarName[VarHeader->NameSize / 2 - 1] !=3D L'\0') { > + DEBUG ((DEBUG_ERROR, "%a: name is not null terminated\n", __func= __)); > + return EFI_NOT_FOUND; > + } > + } > + > + DEBUG (( > + DEBUG_VERBOSE, > + "%a: +0x%04Lx: name=3D0x%x data=3D0x%x guid=3D%g '%s' (%a)\n", > + __func__, > + (UINT64)VarOffset, > + VarHeader->NameSize, > + VarHeader->DataSize, > + &VarHeader->VendorGuid, > + VarName, > + VarState > + )); > + > + VarPadding =3D (4 - (VarEnd & 3)) & 3; > + Status =3D SafeUintnAdd (VarEnd, VarPadding, &VarOffset); > + if (RETURN_ERROR (Status)) { > + DEBUG ((DEBUG_ERROR, "%a: integer overflow\n", __func__)); > + return EFI_NOT_FOUND; > + } > + } > + > return EFI_SUCCESS; > } > =20 - If you can explain the "break" under (3), I'm happy to R-b this patch (and to merge this v4 series). The rest of my comments ((1), (2), (4)) doesn't justify a respin, in itself. - If you decide to replace the "break" with "return EFI_NOT_FOUND" under (3), then addressing the rest ((1), (2), (4)) would be nice, in v5. Thanks! Laszlo -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#113435): https://edk2.groups.io/g/devel/message/113435 Mute This Topic: https://groups.io/mt/103605077/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-