FIT and Descriptor about uefitool

[NikolajSchlej]

Hi Lordkag, thanks again for report.

• I detect FIT table by searching for FIT signature first and then comparing all candidates' addresses to the address stored at [LastVtfEnd - 40h] to get the "real" FIT. If the image is an another OEM pack, FIT can't be found this way, but it can't also be found by CPU, so I decided to not search for such kind of tables for now. I will add a message to indicate that there are some candidates found, but now there is no UI to show them. Will think deeper about it.
• There are some ways to ignore false positives and clearly wrong images, but I don't want to implement it right now. I have much work to do with well-formed volumes, let's just mark this feature as TBD later.
• Yes, thanks to your report. I have nothing to do with Skylake now, but I read that commit and implemented Skylake descriptor support in 0.21.0, please test on the real image with EC regions if you see one.
  Speaking of old map, there are some systems with additional "non-standard" regions, but they are rarely used outside of Intel, AFAIK.

[lordkag]

There is something I forgot to explicitly mention in the first message. It was Plutomaniac who first observed this new descriptor and gave me the hint. I don't remember if I read that commit before or after his message, but I wouldn't have paid much attention without his poke. I hope he hasn't read this report, or I will be receiving an invitation to a tournament pretty soon. After reading some... newspapers, I have some observations about descriptor implementation in UEFITool:

• Shouldn't FLASH_DESCRIPTOR_OEM_SECTION_SIZE be 256 or 0x100 ?
• I believe FLMAP0 should be as bellow
  [...]
  UINT32 RegionBase : 8;
  UINT32 NumberOfRegions: 3; // Reserved in new descriptor
  UINT32 : 5;
• FLMAP2 as bellow
  [...]
  UINT32 ProcStrapsBase : 8;
  UINT32 NumberOfProcStraps : 8; // One-based number of [...]
  UINT32 : 8;
  UINT32 NumberOfRegInit : 8; // One-based number of register initialization entries.
• I see misspelled ReadClockFreqency and FastReadFreqency. I'm not that obsessed, but it might make a difference if you plan on using them later.
• FlashWriteFrequency and FlashReadStatusFrequency should switch the order.
• FLASH_DESCRIPTOR_REGION_SECTION is not entirely right. Descriptor base is 0x00 and size is 0x1000, so it would appear as 0000 + 0000 in Region section. This means that FLASH_DESCRIPTOR_REGION_SECTION begins at Desc_Base + 0x40 (Intel recommended), the region number is 0 based (Intel labelling) and it is as following: Desc + BIOS + ME + GbE + PDR + Reserved1 + Reserved2 in old descriptor, Desc + BIOS + ME + GbE + PDR + Reserved1 + Reserved2 + Reserved3 + EC + Reserved4 in new descriptor.

If you want to read the same... newspaper, you can contact Plutomaniac.

[NikolajSchlej]

Thanks to Plutomaniac too.
I've corrected FLASH_DESCRIPTOR_OEM_SECTION_SIZE to 0x100, returned NumberOfRegions to FLASH_MAP, corrected spelling and order, and corrected REGION_SECTION a bit, but not the way you propose.
I don't have any real images with EC and have to base my opensource code on that coreboot commit and your information, because I do have access to all "newspapers", but if I 'll use them for defining all data structures 100% spec-compatible - it will be a breach of my NDA. Thant's why the structures are defined this way - they are a bare minimum for UEFITool to work properly, got from another open source projects, open documents and open forum posts.

[lordkag]

I understand your situation and probably I wouldn't have mentioned this descriptor issue if it wasn't for that open commit. Although, it makes you wonder how they used the datasheet: taken from a leak or with Intel's silent approval? Coming from Chromium, it makes me think it was the latter. Not to mention that this is pure discussion until we have an image with EC region.

But if you look closely to ifdtool.c, you will see they follow the spec. They mention only 3 reserved regions before EC, they also consider Descriptor as Region 0. You probably got confused by the fact that they mention a maximum of 9 regions (including Descriptor) and EC is last, so EC must be Region8 in zero-based count. But they use Descriptor as Region0, while you use BIOS as Region0. If you already used that public available commit, I'm sure no one will mind if you align to the spec based on it. Intel would have to go over Chromium before they can get to you. And if we take into consideration that this is hardly a trade secret that will damage them, plus the fact that their security team is no strange to UEFITool, it makes a strong case in favour of accuracy. Not 100% because Intel also mentions 2 more reserved regions in old descriptor and one more in new descriptor, but 100% for real life tests.

[NikolajSchlej]

I think they either have Intel's approval or will say it was reverse-engineered from newer images (like it was for old descriptor for me, 2 days of playing with FITC and you pretty much have all the knowledge needed).
Will change the numbers to meet the spec, now I see the my are really wrong.

[lordkag]

Remember the "Say what again" scene from Pulp Fiction? One of us is going to reach that level. And I have the metal wear, so... Putting the safety on the jokes, I still have one question. Have you placed EC last because you think it should be last, or because you don't want to be 100% according to spec, in other words - a calculated error?

Because there are only 3 regions between PDR and EC. FRBA = 0x40 and PDR is at FRBA + 010h and EC is at FRBA + 020h. This leaves us with "Flash Region 5 (FRBA + 014h), Region 6 (FRBA + 018h), Region 7 (FRBA + 01Ch) and Region 9 (FRBA + 024h) are all reserved in client platform and should set to 7FFFh."

I double dare you to...

[NikolajSchlej]

Will never freaking add anything without an image to test, ever. 😠
You are right, corrected the definition again in the latest commit.
Haven't seen Region9 anywhere, and have no plans to support it for now, so no need to point me out on it again. 🔫

[lordkag]

[ What? ]

I hope you went along with my joke and you weren't disturbed by my constant picking on small things. You are right, those extra sections are irrelevant, I hardly see images that use all sections, let alone require new ones. But images with EC region are bound to come at some point (Toshiba is a strong candidate, possibly Dell too) and previous UEFITool wouldn't have known how to process it.

You want to hear another joke? I can only image what your avatar's face will look like when we will find an image with EC region, but misplaced by OEM in Region9. Should I be worried about reporting such issue? That object is used for lighting my cigars, right?

[NikolajSchlej]

Certainly not, just report it. Jokes a funny and all, but bugs aren't.
I doubt anyone will use reserved regions, because FITC doesn't allow it for now, but there are some Murphy's laws to consider. But let's just solve problems that are present, to the possible ones.

[NikolajSchlej]

Made all required changes to new_engine branch, time to close this nice issue.
@lordkag, go ahead and open another one, if needed.
I will try not to add any more features to 0.2x branch because it pushes me back every time. Let's hope new_engine will be ready earlier than we find some nasty EC-enabled images or other similar stuff.