Source code for Alder Lake BIOS was posted to GitHub

mongeese

Posts: 643   +123
Staff
In a nutshell: Apparent source code for Alder Lake BIOS has been shared online. It seems to have been leaked in its entirety at 5.9 GB uncompressed, possibly by someone working at a motherboard vendor, or accidentally by a Lenovo manufacturing partner.

Some Twitter users seem to think that the code originated from 4chan. It made its way onto GitHub yesterday and before it was taken down earlier this morning, someone peered into its source logs and found that the initial commit was dated September 30 and authored by an employee of LC Future Center, a Chinese company that possibly manufactures Lenovo laptops. The code is now available from several mirrors and is being shared and talked about all over the Internet.

It could take days before someone analyzes all 5.9 GB but some interesting sections have already been discovered. There are apparently multiple references to a "Lenovo Feature Tag Test" that further link the leak to the OEM. Other sections allegedly name AMD CPUs, suggesting the code has been altered since leaving Intel. Most alarmingly, a researcher has found explicit references to undocumented MSRs, which could pose a significant security risk.

MSRs (model specific registers) are special registers that only privileged code like the BIOS or operating system can access. Vendors use them for toggling options within the CPU, like enabling special modes for debugging or performance monitoring, or features such as certain types of instructions.

CPUs can have hundreds of MSRs, and Intel and AMD only publish the documentation for half to two-thirds of them. The undocumented MSRs are often linked to options that CPU manufacturer wants to keep secret. For example, an undocumented MSR inside the AMD K8 CPU was discovered by researchers to enable a privileged debugging mode. MSRs also play an important part in security. Intel and AMD both used MSR options to patch the Spectre vulnerabilities in their CPUs that predated hardware mitigation.

Security researchers have shown that it's possible to create new attack vectors in modern CPUs by manipulating undocumented MSRs. The scenario in which that would be possible is very complex and not necessarily what is unfolding right now, but it remains a possibility. It's up to Intel to clarify the situation and the risks posed to their customers.

Permalink to story.

 
Only a ***** would either accidentally leak or knowingly give this info away. It would've been worth a king's ransom.
 
Making things closed source is, IMO, just a lazy security measure. "they can't find vulnerabilities in the code if they can't see it" which we already know people DO find vulnerabilities. Release the bios open source months before the official release, I know more people than I care to admit who search through code for bugs just for fun. Almost as bad as my accounting buddy who likes to search corporate tax fillings for fraud. Thrill of the search, I guess.

Seriously, release the code and you will 100x the people searching through your source code for bugs for free. they could 'out source' their code for free ;)
 
Making things closed source is, IMO, just a lazy security measure. "they can't find vulnerabilities in the code if they can't see it" which we already know people DO find vulnerabilities. Release the bios open source months before the official release, I know more people than I care to admit who search through code for bugs just for fun. Almost as bad as my accounting buddy who likes to search corporate tax fillings for fraud. Thrill of the search, I guess.

Seriously, release the code and you will 100x the people searching through your source code for bugs for free. they could 'out source' their code for free ;)

Again not my expertise - but isn't the lasting problem hardware faults that can not be fixed in BIOS - or if there is an addon system to overcome hardware faults ( eg software "hardware") - if so you could trigger a hardware bypass - so such solutions need to be removed completely to stop exploitation . So BIOS shows most if not all hooks into hardware - ( some made be held in reserve )
The chip details are often hidden - between fab and designers .
So AMD get a leg up - for ways Intel sped up their chips .
Plus wouldn't BIOS show range of inputs , overflow - break encryption/keys from 10 Million years to 1 hour .

I think your argument may make sense for software only - but that's also assuming people don't save images/states to be hacked in future - ie those States will have the vulnerabilities of when made .
Lots of encrypted messages held by nation States are waiting to be broken a future date
 
Again not my expertise - but isn't the lasting problem hardware faults that can not be fixed in BIOS - or if there is an addon system to overcome hardware faults ( eg software "hardware") - if so you could trigger a hardware bypass - so such solutions need to be removed completely to stop exploitation . So BIOS shows most if not all hooks into hardware - ( some made be held in reserve )
The chip details are often hidden - between fab and designers .
So AMD get a leg up - for ways Intel sped up their chips .
Plus wouldn't BIOS show range of inputs , overflow - break encryption/keys from 10 Million years to 1 hour .

I think your argument may make sense for software only - but that's also assuming people don't save images/states to be hacked in future - ie those States will have the vulnerabilities of when made .
Lots of encrypted messages held by nation States are waiting to be broken a future date
I actually hadn't even considered that in the slightest. That's really interesting
 
Last edited:
Again not my expertise - but isn't the lasting problem hardware faults that can not be fixed in BIOS - or if there is an addon system to overcome hardware faults ( eg software "hardware") - if so you could trigger a hardware bypass - so such solutions need to be removed completely to stop exploitation . So BIOS shows most if not all hooks into hardware - ( some made be held in reserve )
The chip details are often hidden - between fab and designers .
So AMD get a leg up - for ways Intel sped up their chips .
Plus wouldn't BIOS show range of inputs , overflow - break encryption/keys from 10 Million years to 1 hour .

I think your argument may make sense for software only - but that's also assuming people don't save images/states to be hacked in future - ie those States will have the vulnerabilities of when made .
Lots of encrypted messages held by nation States are waiting to be broken a future date
Quantum computing will make current encryption technology meaningless anyway.
 
Quantum computing will make current encryption technology meaningless anyway.
China is already send quantum encrypted ,messages - however I believe the data rate is very slow , also distance is a factor - need quantum repeaters I believe
 
I'm no Intel fan, but it's really horrible that someone would do that.

On the other hand..... 5.9 GB of BIOS / UEFI code? Wow. It clearly shows how non-optimized it must be. Tons and tons of libraries just included, which certainly must have overlapping functionality, and incompatibilities. Imagine the number of bugs in that maintenance hell. And that's before the OS gets loaded.
 
"It could've exposed some security vulnerabilities"

That would have been a good thing because it's better to know about them beforehand than to find out about them when it's already too late.
 
Back