From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web10.703.1616610433713738771 for ; Wed, 24 Mar 2021 11:27:13 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gCwMMzmO; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616610432; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JSFY7iYcmMmi3JleM20PL73jXlDgYOoTUGNH/rEG+3w=; b=gCwMMzmOSn7B1z9N6//YQe9q0K7AQvEkHM8yu50i5cJem1/CxKxLgzafsiUHV9uEiKIj9n zeUJPQtyeih2QSxn+0+2L/cq/f1MOx/S+DMelbGnoxid7a1emllBANcma/hztLI+d7933Z QiYobYvUNcDK7z+XlzKIrEn+vQ5NHcI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-525-6W18z_CVNZCUlRypCrqgzQ-1; Wed, 24 Mar 2021 14:26:53 -0400 X-MC-Unique: 6W18z_CVNZCUlRypCrqgzQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EEF7A801FCE; Wed, 24 Mar 2021 18:26:51 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-138.ams2.redhat.com [10.36.115.138]) by smtp.corp.redhat.com (Postfix) with ESMTP id BF5305C257; Wed, 24 Mar 2021 18:26:50 +0000 (UTC) Subject: Re: [EXTERNAL] [edk2-devel] [PATCH 1/1] MdeModulePkg/BmpSupportLib: Allow BMP with extra data To: Jeff Brasen , "devel@edk2.groups.io" , "bret.barkelew@microsoft.com" Cc: "jian.j.wang@intel.com" , "ao.a.wu@intel.com" References: <70c26f78d461d1b8021462d3c3fe6eb717b19193.1616520420.git.jbrasen@nvidia.com> From: "Laszlo Ersek" Message-ID: <7d5c8dd7-680c-98e6-b8a0-084704ca3021@redhat.com> Date: Wed, 24 Mar 2021 19:26:49 +0100 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit On 03/24/21 16:25, Jeff Brasen wrote: > Some of the logo files we received for the group that makes our assets like this (not sure what tool they were created with) look like they pad the BMP size to 8 bytes. > > TranslateBmpToGopBlt: invalid BmpImage... > BmpHeader->Size: 0xE1038 > BmpHeader->ImageOffset: 0x36 > BmpImageSize: 0xE1038 > DataSize: 0xE1000 > TranslateBmpToGopBlt: invalid BmpImage... > BmpHeader->Size: 0x2A3038 > BmpHeader->ImageOffset: 0x36 > BmpImageSize: 0x2A3038 > DataSize: 0x2A3000 > TranslateBmpToGopBlt: invalid BmpImage... > BmpHeader->Size: 0x5EEC38 > BmpHeader->ImageOffset: 0x36 > BmpImageSize: 0x5EEC38 > DataSize: 0x5EEC00 > > So, each of these has 2 bytes of padding at the end of the file. We could write a tool that would do the same size recalculation in order to update the size in the header and remove the two bytes but it seems that this is a valid BMP file and it doesn't seem correct that UEFI is rejecting it. I can update the commit message with more context if needed as well. If there's a spec describing the BMP format, and edk2 is needlessly strict, and the check can be relaxed without security risks, then I think a patch would be fair. Thanks Laszlo