From: Laszlo Ersek <lersek@redhat.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>, edk2-devel@lists.01.org
Cc: Yonghong Zhu <yonghong.zhu@intel.com>,
Liming Gao <liming.gao@intel.com>,
Bob Feng <bob.c.feng@intel.com>,
Jaben Carsey <jaben.carsey@intel.com>
Subject: Re: [PATCH v2 4/6] BaseTools/DevicePath: use MAX_UINT16 as default device path max size
Date: Mon, 3 Dec 2018 14:05:38 +0100 [thread overview]
Message-ID: <bc87f687-7c93-bb65-af46-103abc491d07@redhat.com> (raw)
In-Reply-To: <20181130224537.18936-5-ard.biesheuvel@linaro.org>
On 11/30/18 23:45, Ard Biesheuvel wrote:
> Replace the default size limit of IsDevicePathValid() with a value
> that does not depend on the native word size of the build host.
>
> 64 KB seems sufficient as the upper bound of a device path handled
> by UEFI.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
> ---
> BaseTools/Source/C/DevicePath/DevicePathUtilities.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/BaseTools/Source/C/DevicePath/DevicePathUtilities.c b/BaseTools/Source/C/DevicePath/DevicePathUtilities.c
> index d4ec2742b7c8..ba7f83e53070 100644
> --- a/BaseTools/Source/C/DevicePath/DevicePathUtilities.c
> +++ b/BaseTools/Source/C/DevicePath/DevicePathUtilities.c
> @@ -62,7 +62,7 @@ IsDevicePathValid (
> ASSERT (DevicePath != NULL);
>
> if (MaxSize == 0) {
> - MaxSize = MAX_UINTN;
> + MaxSize = MAX_UINT16;
> }
>
> //
> @@ -78,7 +78,7 @@ IsDevicePathValid (
> return FALSE;
> }
>
> - if (NodeLength > MAX_UINTN - Size) {
> + if (NodeLength > MAX_UINT16 - Size) {
> return FALSE;
> }
> Size += NodeLength;
>
I'm somewhat undecided about this patch.
(1) IsDevicePathValid() also exists in:
- MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c
- MdePkg/Library/UefiDevicePathLibDevicePathProtocol/UefiDevicePathLib.c
Both have:
if (MaxSize == 0) {
MaxSize = MAX_UINTN;
}
Relative to those, this change departs quite strongly.
(2) In addition, a single device path node may extend up to 64KB. That
would be pathologic, yes, but the option is there.
... Of course, we are discussing theoretical limits. Still I'd feel more
comfortable with MAX_UINT32. Lifting the limit from 64K to 4G wouldn't
cost us anything (in development effort), it would be a no-op on 32-bit
build hosts, it would be a theoretical-only change on 64-bit build
hosts, and it would leave us with a larger "safety margin".
I won't insist, but I thought I should raise this. (Sorry if this has
been discussed under v1 already.) If you agree, no need to repost (from
my side anyway) just for this.
With or without the update:
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Thanks
Laszlo
next prev parent reply other threads:[~2018-12-03 13:05 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-30 22:45 [PATCH v2 0/6] BaseTools: get rid of MAX_UINTN Ard Biesheuvel
2018-11-30 22:45 ` [PATCH v2 1/6] BaseTools/CommonLib: avoid using 'native' word size in IP address handling Ard Biesheuvel
2018-12-03 10:25 ` Philippe Mathieu-Daudé
2018-12-03 12:50 ` Laszlo Ersek
2018-11-30 22:45 ` [PATCH v2 2/6] BaseTools/CommonLib: use explicit 64-bit type in Strtoi() Ard Biesheuvel
2018-12-03 10:25 ` Philippe Mathieu-Daudé
2018-12-03 12:52 ` Laszlo Ersek
2018-11-30 22:45 ` [PATCH v2 3/6] BaseTools/DevicePath: use explicit 64-bit number parsing routines Ard Biesheuvel
2018-12-03 10:25 ` Philippe Mathieu-Daudé
2018-12-03 12:55 ` Laszlo Ersek
2018-11-30 22:45 ` [PATCH v2 4/6] BaseTools/DevicePath: use MAX_UINT16 as default device path max size Ard Biesheuvel
2018-12-03 13:05 ` Laszlo Ersek [this message]
2018-12-05 0:04 ` Gao, Liming
2018-12-05 7:42 ` Ard Biesheuvel
2018-12-05 7:53 ` Gao, Liming
2018-11-30 22:45 ` [PATCH v2 5/6] BaseTools/CommonLib: get rid of 'native' type string parsing routines Ard Biesheuvel
2018-12-03 10:27 ` Philippe Mathieu-Daudé
2018-12-03 13:08 ` Laszlo Ersek
2018-11-30 22:45 ` [PATCH v2 6/6] BaseTools/CommonLib: drop definition of MAX_UINTN Ard Biesheuvel
2018-12-03 10:28 ` Philippe Mathieu-Daudé
2018-12-03 13:08 ` Laszlo Ersek
2018-12-11 7:11 ` David F.
2018-12-11 15:45 ` Laszlo Ersek
2018-12-11 22:53 ` David F.
2018-12-11 22:55 ` Ard Biesheuvel
2018-12-11 23:03 ` David F.
2018-12-05 0:04 ` [PATCH v2 0/6] BaseTools: get rid " Gao, Liming
2018-12-05 8:12 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bc87f687-7c93-bb65-af46-103abc491d07@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox