Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No way to continue without a test suite #270

Open
NikolajSchlej opened this issue Aug 24, 2022 · 14 comments
Open

No way to continue without a test suite #270

NikolajSchlej opened this issue Aug 24, 2022 · 14 comments

Comments

@NikolajSchlej
Copy link
Collaborator

Long ago, when trees were big and bits were played live, I've developed those parsers in Qt-flavored C++, using lots and lots of different EFI and UEFI images as possible input, and adding a lot of really strange code to make most of them parsing into something resembling a valid tree structure.

Sadly, today in 2022 almost none of those original images are available to re-test that old code, so refactoring it got unnecessary complex, enough to discourage any new people to ever touch anything here. I myself was discouraged enough for many years.

To make this pain a lot easier, we seriously need to:

  • write a simple test program that can be executed before and after any code change to confirm that the change did not break anything that already has a test for
  • write a ton of tests for this program
  • (re)collect some wacky EFI/UEFI images to test the corner cases and document those corner cases in the code (i.e. // This is to parse test image X, Y and Z)
  • once all of the above is done, add testing in CI/CD pipeline so robots can do it for us
  • then require tests to be written for any new PRs to be merged
@NikolajSchlej
Copy link
Collaborator Author

This image has a treasure trove of Phoenix NVRAM things, can be used to test that part of NVRAM parser later.
DA0V07MBAD1 REV D.BIN.zip

@platomav
Copy link

(re)collect some wacky EFI/UEFI images to test the corner cases and document those corner cases in the code (i.e. // This is to parse test image X, Y and Z)

Would it be possible to have a list of these edge cases that are historically supported so that anyone who has or knows how to re-find such samples can do so?

@NikolajSchlej
Copy link
Collaborator Author

NikolajSchlej commented Aug 28, 2022

Let's make such a list by reading parser sources:

  • Capsules:

    • UEFI Capsule
    • AMI Aptio Capsule
    • Toshiba Capsule (Capsule GUID 3BE07062-1D51-45D2-4583-2BF093257ED461)
  • Intel descriptor-based images:

    • Descriptor v2 (default, Skylake+)
    • Descriptor v1 (detected using componentSection->FlashParameters.ReadClockFrequency == FLASH_FREQUENCY_20MHZ check)
    • Descriptor with Gigabyte quirk (biosRegion.size == intelImage.size)

@NikolajSchlej
Copy link
Collaborator Author

NikolajSchlej commented Aug 28, 2022

Intel regions:

  • Intel image with PDR region having FFS volumes/files (Apple x86 boards of 2015-2016)
  • Intel image with DevExp1 region having ME FPT stuff (Recent Atom-based boards)
  • Intel image with the last volume in Bios region intersecting with DevExp1 region (Also some recent Atom-based boards)

@NikolajSchlej
Copy link
Collaborator Author

NikolajSchlej commented Aug 28, 2022

Raw Areas:

  • Intel image with a microcode in Raw Area
  • Intel image with BPDT structures (IFWI 1.6, IFWI 1.7, IFWI 2.x)

@NikolajSchlej
Copy link
Collaborator Author

NikolajSchlej commented Aug 28, 2022

Volumes:

  • Image with FSSv2 Volume Rev1 (Intel stuff before UEFI, older than P67 chipset, early Phoenix faux-EFI images)
  • Image with FFSv2 Volume Rev2 (default)
  • Image with FFSv3 Volume Rev2 (some newer stuff requiring more than 16 Mb of files in the volume)
  • Image with FFSv2/v3 Volume Rev2 with extended header
  • Image with Microcode Volume (Apple x86 before T2 2011-2015)
  • Image with VSS NVRAM Volume (Phoenix, Apple)
  • Image with AppleCrc32 and UsedSpace in Volume ZeroVector (Apple x86 before T2 2011-2016)
  • Image with Weak-aligned Volume (haven't seen one yet, AFAIR)

@NikolajSchlej
Copy link
Collaborator Author

NikolajSchlej commented Aug 28, 2022

FFS Files:

  • Image with files having non-empty tail (FFSv2 Rev1 volumes only, Intel stuff before UEFI)
  • Image with large files (FFSv3 Rev2)
  • Image with files having NVAR variable stores (AMI Aptio)
  • Image with files having Phoenix hashes (Phoenix with BootGuard enabled)
  • Image with files having AMI hashes (old and new, AMI Aptio with BootGuard enabled)

@NikolajSchlej
Copy link
Collaborator Author

NikolajSchlej commented Aug 28, 2022

FFS Sections:

  • Image with padded compressed sections (Detect out-of-spec size requirement for some FFS sections #178)
  • Image with Phoenix or Insyde postcode sections
  • Image with EFI1.1/Tiano/LZMA/LZMAF86/GZip-compressed sections (EFI1.1 - early Intel before UEFI, GZip - Qualcomm arm64)
  • Image with signed sections (EFI_CERT_TYPE_RSA2048_SHA256_GUID and EFI_FIRMWARE_CONTENTS_SIGNED_GUID)

@NikolajSchlej
Copy link
Collaborator Author

Still a ton of stuff remain for variations of NVRAM, ME, BPDT, BootGuard and other smaller parsers, but let's collect the above first and see how it goes.

@NikolajSchlej NikolajSchlej pinned this issue Dec 24, 2022
@NikolajSchlej
Copy link
Collaborator Author

Yet another breakage that could have been caught by a test: 19ab607

@NikolajSchlej
Copy link
Collaborator Author

Mentioning #219 here, have some images attached there.

@platomav
Copy link

Mentioning #234, which has a false positive "Intel" Flash Descriptor detection sample.

@NikolajSchlej
Copy link
Collaborator Author

Mentioning #368, regression in A66 and A67 that could be caught by adding Apple SCAP files to a test suite.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants