I’d drop the Audio Input part of it. I don’t see a lot of use recording audio when you boot the system, and it is going to be a mess dealing with built in microphones etc. vs. input jacks etc. If we w

Mike, It is likely we want async and synchronous playback. If you are playing a boot bong you don’t want to block on its completion. If you are doing a GUI UI you don’t want to block on playback and t

EFI does not have a concept of Volume names, EFI has a concept of EFI_HANDLEs that contain device paths that indentify the volume. The UEFI Shell has volume names, but that is a construct produced by

Ethin, In terms of defining the protocol stack it is good to start with the producers and consumers and think about the problem from both perspectives. It is easy enough to think about the producer pa

Sure, don’t think I’ve really used that but as long as I get pointed int he right direction I can make it work. For a device driver the general UEFI model is for the Entry point of the driver to publi

Don’t forget Thunderbolt dongles, docks, and devices. Thanks, Andrew Fish

Marvin, School of hard knocks… Bug rates have gone up around the world as the security experts show up with security fixes. Most commonly the bugs are around functionality and not security. While a br

Leif, Since I have put some brain cells around this area in the past I can be the backup and help out too. I’d also point out if you are having issues building or have general questions on how things

Bret, If I understand correctly the CI list is the recommended versions, but not the required versions. Do we have any concept of the required versions? I guess we could put a python assert to enforce

Do we have a scheme to require a min Python version? Thanks, Andrew Fish

1st thing to check is to see if your *.FDF files have a syntax error and the is just bad error processing. Thanks, Andrew Fish

Marvin, I was thinking more about tooling to introspect PE/COFF images. Trying to consolidate the BaseTools to use the common edk2 libraries would be doable, but I agree that is a separate project. Th

GenFw does the ELF to PE/COFF conversion, zeroing out Debug Directory Entries etc. so it should be correct. It is not like the PE/COFF spec is a moving target. Thanks, Andrew Fish

Marvin, The BaseTools can easily build C command line tools that are cross platform? Actually GenFw [1] already does a lot of PE/COFF magic, so it should be relatively easy to add a -I, —info, and dum

At a minimum it would be nice if we had a tool that would point out the security faults with a given PE/COFF file layout. > On Apr 8, 2021, at 4:16 AM, Laszlo Ersek <lersek@...> wrote: > > On

Some of use also sit on the UEFI standards committees so getting changes into the specification is possible with in constraints of what the spec committees find acceptable. Thanks, Andrew Fish

Well it is just software at the end of the day. We could always wrap any Industry Standard API (PPI, Protocol, etc) in a library function and let people chose backward compatibility vs better security

CPPFLAGS might be your issue. Assuming VFR is failing. It is one of the only C++ tools. See the end of:https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/Makefiles/ms.common It would be

Ethin I’m not sure what issue you are hitting with VFR? When you built the C build tools it should have built the VFR compiler that matches the code? Did you run edksetup.bat Rebuild?

You should probably just chmod the directory permissions so you can build from the git repo vs. trying to build with sudo or some such. For each terminal window there is a onetime setup of sourcing .