What can we learn from leaked Insyde's BIOS for Intel Alder Lake | Hacker News Reader

What can we learn from leaked Insyde's BIOS for Intel Alder Lake

hardenedvault.net

191 pointshardenedvault73 comments

Original thread announcing the leak: https://boards.4channel.org/g/thread/89060767

Internet Archive link to .zip file snapshot of files from GitHub (but no git commit history): https://web.archive.org/web/20221007235925if_/https://codelo...

Also mirrored here: https://git.tcp.direct/TheParmak/ICE_TEA_BIOS

The git bundle for that mirror is also on the Internet Archive: https://web.archive.org/web/20221008155117if_/https://git.tc... (which can be restored via the instructions at https://git-scm.com/book/en/v2/Git-Tools-Bundling)

Note that downloading the git bundle (from the link on git.tcp.direct or its mirror on Internet Archive) is the most space-efficient download, as there are many large identical files in the repo that git deduplicates but the zip file format does not.

Thanks. Funny how stuff like this always gets leaked on chans.

Their lollygagging on "moderation" is a feature.

well, each thread basically has a time limit before it gets archived and removed, so the users know to keep making threads if they want to keep their topic alive.

So if someone comes and makes a DMCA claim on a thread, the moderators can just ignore it and wait for the thread to time out or they delete it and the users just make another thread.

As long as the moderators wait a couple hours or so to respond to legal threats, and maintain a semblance of "low moderation" they pretty much have plausible deniability to void copyright. It's sort of genius.

The 4chan/4channel moderation is much quicker to respond to reports than they're given credit for. Any post flagged by users as illegal is dealt with (deleted and the user banned/reported to authorities if applicable) usually within minutes. First line of defense are janitors from the community who do the work for free, anonymously and are hated by the very community they help.

That security pledge from the insyde CTO is just the cherry on top of this. Especially since it was published back in February

It is unfortunate that this stuff is not open source in the first place.

the pcengines apu2 is currently my preferred small system. one of the things I really like about it is that the firmware is open source. I will probably never need to build my own firmware, but I like knowing that I could.

https://pcengines.github.io/

Having said that, I think there is still a big ol black box of AMD secret sauce in there, sigh, so close yet still so far. why so secretive? what are you trying to hide?

It might not even be legal to ship motherboards with fully open-source firmware, especially if it has WiFi/Bluetooth baked in. Once you add anything related to networking in your stack, the chance of running FOSS firmware goes out the window. It's all very lock-and-key stuff, according to... <squints at piece of paper> ...the United States Government.

Why? Because of FCC requirements around radio emissions?

Yeah the firmware can control the gain/broadcast power and exceed FCC limits. It can be open source still, but modifying it and running the modified version would invalidate the FCC certification and running non certified transmitters is generally frowned upon, often illegal, depending on precise circumstances.

Not even the running, but sale of. If it's too easy to modify then FCC will make it's sale illegal.

Nobody wants that risk for their product.

Actually linux distro package repo have the list and the way to compile and load into system for obvious reasons. (Otherwise how do they compile the wifi drivers for themselves?)

But no one is even going to say how to actually do it publicly because it is illegal to do (and probably also unsafe to do).

And yet I can buy an sdr 400mhz-6ghz no problem?

sigh, whatever, things are never fair.

I will say the thing that pisses me off about thinkpads is their use of a whitelist to limit radios. their justification for this was the same. "it's certified as a radio antenna pair, the fcc will not let us let you install whatever radio you want" which is bullshit.

The price of an SDR is usually much more than a basic WiFi card so that's kind of the justification for why an SDR doesn't require an FCC license since it's for experimental purposes and that you probably have a good reason to be using one. If you use one outside what you are licensed to do so, then expect the FCC to come down on you. The FCC license for consumer goods is a way for a manufacter to say that the product conforms to the applicable rules so that the FCC doesn't have to worry about every end-user fucking around with the spectrum.

And yet I can buy a Microtik router that just has dropdown boxes for selecting options that would get the FCC to bust down my door. I think it is far more likely that they just don't want to expose what would then be obvious security vulnerabilities and/or built-in backdoors.

Doesn't Mikrotik have US-specific part numbers that have hardware locks around particular RF features?

Yes, although there is probably old stock that lacks the locks, and getting hold of non-US versions of their product isn't impossible.

If that's the only problem, it shouldn't be too hard to limit either in hardware or have the HW run the user-provided firmware in some rudimentary VM that essentially passes through everything except the commands that set TX power; that way you maintain compliance without restricting people from running their own software.

I think however it's just a matter of time before these restrictions become obsolete anyway:

1) I'm not sure whether the possibility of violating FCC regulations is something that will be used in practice by enough people to be a problem (you might get the odd one out here and there, but see the point below)

2) People who intentionally want to violate FCC regulations can already do so in plenty of ways - SDRs are becoming cheaper and cheaper and there's basically no way to prevent their import, so I'm not sure why they'll even bother with a wireless card if their aim is to truly cause mischief and shit on restricted radio bands.

Tivoization features have to prevent you from running other code. Anyone relying on preventing the reading of source to avoid modifications is living on the knife's edge with regulators.

Would there be any traction with a mobo that did not have any of that stuff built-in? There's a lot of advantages to no longer needing expansion cards for networking, so I seriously doubt anyone wants to go back to that. A laptop with a bunch USB dongles connected to a hub could be a doable solve to keep that gear off the mobo.

Could you leave an empty socket for a wifi controller chip but still build in the antennas? Although that would likely lock you into whatever chip had the right pin out which seems a bit pointless.

Seems like this kind of radio chip would be standard pin out in 2022. Could you not just put one of those chips like Broadcom makes that has all the radio formats on it? Even sell it as a "kit" so that it comes with it but you have to install yourself to meet "regulations" or licensing terms. The first gen of Thunderbolt add-on came as PCIe due to some sort licensing issue instead of on the mobo directly

The pinout is already standard, you can use mini-PCIe (common in older laptops) or the more recent M2 slot (which is the same PCIe but in a different form-factor).

In fact some boards already come with 2 M2 slots, so nothing prevents you from using the second one for a wireless card if you so desire. Bluetooth on the other hand is low-enough bandwidth that a USB adapter works fine generally (USB Wi-Fi adapters also work but USB uses more CPU which is a problem for high-bandwidth networking).

Personally I just don't see the point of Wi-Fi for a stationary machine anyway - you're wasting valuable spectrum for something better served by an Ethernet cable (sourced from a powerline adapter if you're really desperate).

Every desktop motherboard on the market that has WiFi implements it by means of a M.2 2230 card inside a shield can that's screwed to the motherboard, with antenna connectors on pigtails coming out the side of the can to protrude through cutouts in the IO backplate.

The WiFi is already a self-contained module with a standard hardware interface and its own FCC ID and certification. I don't recall ever seeing a motherboard include WiFi support in its UEFI firmware. So from the perspective of the motherboard manufacturer, WiFi is just a component they stick on the board and ship, with no regulatory overhead aside from duplicating the WiFi module's identifying information on a sticker that isn't hidden beneath the VRM heatsinks. The motherboard market really couldn't tolerate any wireless solution more complicated than that.

Why not just have the wifi-controller hardware already there, but strip out the software required to make it do anything?

I.e. modularize the BIOS firmware such that you flash "the BIOS firmware" and "the wifi/bluetooth stack firmware" separately, to separate chips. Then ship the motherboard without the wifi/bluetooth stack firmware pre-flashed — with the NAND that the wifi controller initializes from, just empty, such that the wifi controller immediately halts on boot, and the CPU doesn't find it on the bus. Make sure the rest of the BIOS works without the wifi controller "up". And then have an open root key of trust for the BIOS (= you can sign your own BIOS), but a closed root key of trust for the wifi controller (= only the OEM can sign the wifi/bluetooth stack firmware.)

It doesn't seem like it would be all that hard, given that we already have this kind of hardware firmware (+ firmware storage) modularity in modern devices in other ways — e.g. most trackpads have their own isolated firmware, that the host can flash to update, but which isn't otherwise accessed by the host CPU, rather only the trackpad microcontroller itself; where the trackpad firmware flash lives inside the trackpad, not in the host.

I've never understood this because I can attach any USB adapter I want and it works.

Despite that, the Atheros WiFi vendor released source code for their WiFi firmware at least twice:

https://wiki.debian.org/Firmware/Open#Radio

It would still be significantly better if mobos ran coreboot (or some open source firmware) with some binary blobs for WiFi/Bluetooth. It's not out of the ordinary to have this arrangement; the newer Nvidia GPUs support open source kernel modules because they use encrypted binary blobs to lock down actual functionality. The WiFi/Bluetooth chips could even have open source firmware but require a signed hash of that firmware binary.

Apu2 is starting to get rather long in the tooth. Hope there is a refresh soon because it's a great little piece of hardware

Email PC Engines and ask/encourage hardware refresh. There have been shortages of Intel network chips which limited APU2 shipments.

If you want an x86 small form factor computer, you can get some from some vendors that have open source firmware on them. My home router is from Protectli which runs coreboot that is open source, instead of a standard bios.

https://protectli.com/kb/coreboot-build-guide/ - guide on how to build coreboot yourself. You can check out their homepage for the hardware they sell and that includes it.

https://www.coreboot.org/

It looks like the systems may still contain some binary blobs in Coreboot.

Interesting. I thought they were available only in the US (or UK, but end prices became definitely not appealing for us Europeans after Brexit). However, the risk of bricking the device is too high for many users to embark in the Coreboot installation, so why not offering it as a service before sale? It would be a lot easier for them as they need only one build for each model, and charging say 20 bucks for each install would easily cover the costs. A similar offer comes from NRG Systems from Germany: https://www.ipu-system.de/ They however don't mention Coreboot compatibility, although I'm sure the platforms share many similarities.

FYI, Protectli are a rebrand of Yanling hardware, which are sold on AliExpress.

https://m.aliexpress.us/item/3256802158669247.html?algo_pvid...

Protectli provide their own warranty on, plus offer coreboot. But you can get the same hardware cheaper on AliExpress maybe.

Shipping fee is $98?!?!?

It was a while back but I vaguely recall that for a very long time China had still been considered a developing country by the Universal Postal Union, and was thus charged far less for international postage than a developed nation. So shipping for things off of aliexpress or whatever would be practically free.

That was cancelled IIRC a couple of years ago (?) and they now pay closer to "true" shipping rates.

I wonder why it seems to be mostly the new stuff that's getting leaked, and not the old out-of-support platforms that are long out of production, since the latter would be of value to BIOS-modders trying to add features and the like.

I agree with the other comment here that this stuff should've been open-source in the first place, but more than that, I wish Intel would just release all the detailed documentation on their products. They used to be far better about that --- I believe you can still find reference schematics and such for Pentium II/III-era chipsets on their site, or in the Internet Archive thereof.

The latter part of the article is more "open source bad" fearmongering, sadly common these days in that part of the software industry.

In this case, possibly because it wasn't a leak, just somebody making a (possibly job-ending) mistake. LCFC appears to be a Lenovo subsidiary that is part of their laptop etc. design; the initial commit in the git repository (saw a screenshot somewhere — not going to touch that code) appears to be recent, from a user using their work account (name prefixed with "LCFC\" which may indicate Windows domain login), with their work email. The repository was in a GitHub organization called "LCFCASD", presumably a subgroup within the company.

> Individuals or organizations that are not eligible to sign CNDA with Intel, such as open source firmware maintainers.

Many of them do actually have CNDAs signed with Intel, at least those employed to work on commercial products based on Intel's chips. You'll see tons of references to NDA-only datasheet in coreboot's commit history.

You'll see tons of references to NDA-only datasheet in coreboot's commit history.

Isn't that really against the principles of open-source (and possibly the NDA itself)? It's a strange situation and why I'd rather manufacturers release datasheets instead of contributing to OSS. The source is technically "open" in the latter case, but in practice it's not much more informative than what you'd get if you just decompiled the binary.

> and possibly the NDA itself

Depends on the NDA. A lot of NDAs won't require you to never mention that there is a thing that's under NDA, just from divulging the information in question.

I suppose that gets into the area of what counts as a derivative work.

Given that "source code" which looks like decompiled binary wouldn't be of much informative value anyway, I can see how it wouldn't seem like it's leaking any NDA'd information.

It's a slightly biased analysis:

> Can open source firmware projects benefit from leaked content?

> Unfortunately, no or rarely.

> Individuals or organizations that are not eligible to sign CNDA with Intel, such as open source firmware maintainers. Please note that open source firmware projects cannot directly benefit/reuse from leaked content due to legal risks

A direct reuse of everything is unlikely, but access to the material might lead to many interesting tools.

Simple example: undervolting (to save battery and reduce heat) was taken away by intel because plundervolt allowed attacks against the SGX enclave.

SGX has now been abandoned by Intel, but undervolting remains impossible.

If I ever get an Alder Lake, would I look for a way to enable that on my laptop? Yes!

Do I fear legal risks of altering the functionality of the hardware I purchased? No, thanks to the consequences of the first sale doctrine.

> Binary blobs: It’s worth noting that in addition to the binary blobs required by various devices (Bluetooth BLE, WiFi, Ethernet, etc.), there are three different ACMs for security features: BiosGuard, BootGuard, and TXT

> In addition, one thing should be noted that the key pairs required by BootGuard during provisioning stage is also included in the leaked content

So there's everything I would need to understand, patch then flash my own alterations? Great! I'm even more interested now!!

> the data center should prepare

> Short-term plan:

> Security team and patch management team should work together to ensure critical devices are upgraded to the latest version

And IMHO the individual interested in future attempts to reclaim full ownership of their hardware should prepare in a very different way, by:

- downloading a copy of the current BIOS binary update (and the last few versions, just to be on the safe side)

- blocking BIOS updates ("capsules" etc) in the BIOS

- in the OS, uninstalling the tools that allow such updates (ex: Lenovo Vantage)

- ideally, even switching to Linux, as Microsoft can package drivers updates with the BIOS, and if it's that big one of these drivers may include code from Intel using unusual ways to forcefully apply upgrades, that would bypass the methods you can control if the binary is delivered and run on your hardware (ex: Intel ME)

I really like Windows, and "security" in general, but I like the idea of having features like Undervolt even more!

> SGX has now been abandoned by Intel, but undervolting remains impossible.

SGX only really appears to be abandoned on client chips. SGX is a critical part of TDX, which is brand new.

It's insulting enough that Intel can "take away" features... And we can't even replace their code with our own.

For someone with a passing curiosity, but limited time and skill atm. Where would we download the source code and previous updates?

You mean security, not "security". The former is securing your own hardware against others, the latter is others securing the hardware against you. Unfortunately the corporates are more interested in promoting the latter than the former.

It is, not to put a fine point on it, an absolute asshole move.

They could have merely disabled the GUI element which enables the undervolting. This would've made it so you need tools like http://ruexe.blogspot.com/ to edit the EFI variable which firmly put it outside of the reach of the average consumer but still makes it possible. But no, the EFI variable is protected and unless you manage to break the firmware it's impossible to change it. Sigh.

It's so funny to me that people seriously claim that open-source projects do not benefit from this. As hard as open-source projects try to warn their developers against looking at leaked sources, are we really supposed to believe that no one looks?

I was under the impression that this mentality is somewhat theatrical to discourage the accidental subconcious inclusion of mechanics into open source projects as it increases their legal risk exposure.

If intel sues kernel.org for using the leaked source for development, kernel.org can just go "we told everyone not to look at it, so either it's coincidental, or a specific person looked and we'll revert sorry"

This has probably occurred in certain communities but 'clean-room' documentation may have been written by third-parties from an understanding of non-public information and as long as the developer(s) nor the writers of said documentation were involved in any malice towards obtaining said information it is probably somewhat ok.

Quite a "Frist" commit!

I mostly learned that people make such intrusive ads nowadays that I won't be reading this article.

Wrong thread maybe? I'm on mobile and didn't see a single ad.

Reply on news.ycombinator.com