efi_veto vetoes Ip4Config on my working system

[redmercury]

I have a Dell OptiPlex 5050 that does not suffer from the Ip4Config issues mentioned in 64b4452, as verified through my own testing of the UEFI shell disconnect command. An EFI module that I've been working on requires the Ip4Config protocol and iPXE disconnecting it prevents my scenario from working correctly. After manually commenting out efi_veto everything works well.

I tried adding a setting "skip-veto" to provide a break-glass option to prevent the veto process, but the veto is applied before autoexec.ipxe is executed. The veto filter is a little coarse from what I can see. Do you have any ideas on how to improve the filtering or provide an override to prevent vetoing?

[NiKiZe]

Is there anything unique to the working Ip4Config that can be used to disable the vetoing?

[redmercury]

Perhaps - driver version numbers (if vendors ever updates them of course), machine model if I can get it, etc.

It sounds like there are two approaches, not necessarily orthogonal:

1. Add a way to disable vetoing entirely on known good systems. Ultimately the user should have a choice.

2. Be more precise about the conditions under which we veto. Use driver version numbers and model in addition to the manufacturer used today. Perhaps maintain a vetoed driver version range and once a manufacturer releases a fix for a model, cap the vetoed driver range.

We also might want to notify the user that their drivers are being vetoed instead of things silently not working, so that there are no extended debugging sessions trying to figure out what's going on. This might also place more pressure on a driver vendor to get their drivers fixed.