[edk2-devel] [GSoC proposal] Secure Image Loader

[Michael Brown]

On 08/04/2021 10:04, Marvin Häuser wrote:
> Thank you a lot. One thing I noticed is that part of the quote I did not 
> see on the list before, so I marked it below.
> 
> On 08.04.21 00:10, Andrew Fish wrote:
>>> The general UEFI (and UEFI PI) is we mostly add new things, and don’t 
>>> depreciated things to maintain compatibility. So for example you can 
>>> add a new Protocol to a handle so you have V1 and V2 of a protocol on 
>>> the same handle. An example of this is SimpleTextIn and 
>>> SimpleTextInEx. SimpleTextIn was modeled on the LCD of a serial 
>>> terminal (our server roots) so it did not expose modifier keys, or 
>>> have an easy way to implement snag keys so that is why SimpleTextInEx 
>>> got added for the new functional.
> 
> ^ Here; +1

The addition of EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL was really not a good 
example of how to handle this issue gracefully.

Here is the kind of workaround that external code has to implement: it's 
a perfect example of how this "add a V2 protocol" approach ends up 
imposing a permanent maintenance burden on external code:

   https://github.com/ipxe/ipxe/commit/a08244ecc

Note that there was absolutely no reason for the specification to 
require a V2 protocol in order to support Ctrl-<key>, and the EDK2 
codebase will indeed do the sensible thing and return the ASCII values 
for Ctrl-<key> via the original EFI_SIMPLE_TEXT_INPUT_PROTOCOL.  It 
would be amazing if, as you suggested, everyone uses the EDK2 codebase 
and so all public implementations of EFI_SIMPLE_TEXT_INPUT_PROTOCOL 
would do this sensible thing.

Unfortunately, this is not the case.  Very large numbers of vendors use 
some other non-EDK2 implementation that does not do the sensible thing. 
  I have no idea why.

It's also worth noting that the addition of 
EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL opened up a gaping potential security 
hole related to pointer lifetimes, as documented in the above-linked 
commit message.


TL;DR: please assume that creating a V2 protocol has a very significant 
cost, and needs to come with benefits that outweigh that very 
significant cost.  If you can achieve what you need without breaking 
backwards compatibility, then that represents a massive increase in value.

Thanks,

Michael


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