[edk2-devel] [RFC] Expose HII package list via C variables

[Ni, Ray]

Marvin,
If we can keep the secure parsing code inside the PeCoff library, all the backward combability issues because of removing the HII section support don't exist.
The PeCoff library might be very complex but the complexity[1] is hidden inside and abstracted by the PeCoff library API.
The complexity[2] of resolving combability issues after dropping HII section support disappears.

The complexity[1] is a fixed value but [2] is hard to calculate because there are so many platforms that might use this feature.

> -----Original Message-----
> From: Marvin Häuser <mhaeuser at posteo.de>
> Sent: Friday, August 27, 2021 2:33 AM
> To: devel at edk2.groups.io; Ni, Ray <ray.ni at intel.com>
> Cc: Andrew Fish <afish at apple.com>; leif at nuviainc.com; Kinney, Michael D <michael.d.kinney at intel.com>; Gao, Zhichao
> <zhichao.gao at intel.com>; Wang, Jian J <jian.j.wang at intel.com>; Wu, Hao A <hao.a.wu at intel.com>; Bi, Dandan
> <dandan.bi at intel.com>; Dong, Eric <eric.dong at intel.com>; Bret Barkelew <Bret.Barkelew at microsoft.com>; Vitaly Cheptsov
> <vit9696 at protonmail.com>
> Subject: Re: [edk2-devel] [RFC] Expose HII package list via C variables
> 
> On 26/08/2021 20:19, Ni, Ray wrote:
> >> 3. Saves error-prone parsing work
> > This might be the key reason? Is it theoretically possible to write a secure parsing code?
> 
> Hey Ray,
> 
> Yes it is, but the most secure parsing code is that which doesn't exist.
> I'm confident in the one I wrote for the new PE/COFF library, but if
> variables suit the need, I really would like to use them, even if it is
> only by a toggle. The new proposal (please check the chain with Mike)
> was adapted to preserve the old behaviour fully for any platform that
> wants it, permanently. Amaranth will very likely drop support for the
> PE/COFF section, either nicely with an upstream PCD, or not-so-nicely
> with maintaining patches to remove the functionality downstream.
> 
> In the same chain I outlined I'm sketching a new terse file format and
> I'd prefer to avoid any unnecessary data or parsing burden. The current
> library I am sketching privately is *much* smaller than both the current
> and the new PE/COFF library. The overall format in an UEFI context (no
> dynamic linking etc.) is at least as powerful as PE/COFF and pretty much
> always smaller than TE. I'd like to keep it that way. :)
> 
> Best regards,
> Marvin
> 
> >
> > Thanks,
> > Ray
> >
> >
> > 
> >
> >



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79862): https://edk2.groups.io/g/devel/message/79862
Mute This Topic: https://groups.io/mt/85147044/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-