Libreboot Is Right About CPU Microcode 

For anyone wondering, _all_ Intel x86 CPUs, even the original 8086/8088, use microcode. The ability to update it was introduced with the P6 architecture (Pentium Pro/II/III) which is coincidentally the oldest CUPs supported by stock Debian.

To be fair, based on how often microcode gets updated, the choices aren't "broken microcode vs working microcode" it's "broken microcode vs hopefully slightly less broken microcode"

just in time for my cpu segfaults.

I have to say I'm really curious on how AMD's openSIL will affect the ability for projects like Coreboot and Libreboot to support modern technology

I was apprehensive at first when it was announced that microcode was going to be allowed in libreboot, but after I read through the newsletter I completely understood. Allowing people to not have it if they still don’t want it is the best decision. I applaud the work that’s being done on the libreboot project and i look forward to reading through each newsletter. I also look forward to updating my MacBook 2,1 with future releases because it’s kinda funny that one of the most freedom respecting computers available is an Apple product.

FSF: "you are free to do exactly what we tell you to do"

A processor has to be purchased, so microcode should be made available for the life of the processor. Period.

The first two letters of FPGA literally stand for Field Programable, meaning it's *meant* to be programed in the field after the customer already has the product. We use these extensively in telecom and their whole point in life is to be updated after sale, otherwise the manufacturer would have just put a ROM there. In my opinion the FSF's stance that FPGAs aren't meant to be upgraded after the user receives it is a denial of reality akin to the belief in a flat earth.

I used to update my microcode. I stopped doing so when I realized the most recent patch for my CPU that Intel provides was 3 years ago. It's hard to update when there are no updates.

Why has FSF put themselves into this contradictory position? Because back in the day they assumed hardware isn't really of concern to freedom - only software is. They are Free *Software* Foundation after all. Then when they noticed firmware, they had to decide something about it. A logical consequence is, if it's fixed it's indistinguishable from hardware and so also not of concern. But both firmware and hardware grew more and more complex and the boundary between that and the software got blurrier and blurrier. The right call would be to acknowledge that software freedom is just a part of a bigger issue - control. Whether it's the device owner | software user that is in charge, or is it the manufacturer | developer | vendor. Based on that, we can isolate the ideal case: the user has the ultimate say over anything in the product after obtaining it, all the knowledge about the design (hardware, firmware, software) is available to user and no legal restrictions are placed on the user. In light of that, it's pretty easy to consistently judge 'the freedom' of a piece of hardware and its software. Redistributable proprietary firmware is better than non-redistributable one. Downgradable one is better than non-downgradable one. Vendor-signed firmware is worse than user-modifiable one. Having PCB schematics is better than not having them. Likewise with hardware documentation or even Verilog sources, microscope die shots, and so on. And finally, if the proprietary firmware is isolated, cannot look at your RAM, etc. it's a significantly lessr issue than one that can invisibly steal the CPU from your OS.

You can be the device's designer and also not know what's in the firmware, you just buy IP blocks and they can each have their own encrypted initialization code that you have to upload as part of your firmware. Turtles all the way down…

I have an HP 8200 SFF with Libreboot (BTW if anyone's considering installing Libreboot on some supported device (or need help doing so), ask on the IRC channel, Leah and others are very nice and helpful)

It doesn't work for Microcode, but I understand the FSF's position, since if the firmware is embedded them it can't be denied to free operating systems... think of the WinPrinters and WinModem's of the 1990's where the device was essentially a brick without the firmware which was only provided on Windows...

I'm all for this, chances are those binary blobs, if they were to try and spy on you, would fail to do so due to all the extra missing components. It's not impossible but I've just never used libre/coreboot due to not liking any of the supported hardware. I'd much rather hardware I like be supported in some capacity rather than not at all.

Stallman defines freedom very simple, freedom is to be in control, if you cannot edit the microcode, then you are not in control

In my view less buggy proprietary code is better than broken proprietary code . Even using some freedom respecting software on things like windows is better than not doing that.

7:18 The fact that the FSF considers firmware uploaded to the device nonfree but doesn't care about firmware embedded into the device is actually completely philosophically consistent. In the example on the left the embedded firmware acts just like hardware, the entire thing is a black box to the user's point of view and they can basically treat it as circuitry. This situation is not ideal but at least it is fair because the manufacturer of the device can also not modify the firmware after the device has been sold. The user and manufacturer are equal here. In the example on the right the user has to install the firmware, but can't see what it does and can not change it. This gives the developer of the firmware power over the user, as the developer can change the update the firmware whenever they want, but the user can't. The user and manufacturer are not equal! And yes technically the situation on the right has *more potential* for freedom *if* the firmware gets reverse engineered. But until the day that the firmware has actually been successfully reverse engineered the situation on the left is superior.

With RISC-V there is a possibility of fully open source

Hmm this would hopefully make Coreboot more mainstream.

I debated this directly with Stallman once and I maintain that the FSF and Stallman are simply wrong about this.

I support coreboot/libreboot over that garbage american trends firmware. I am currently looking to buy a laptop from Tuxedo however they do not comes with core or libreboot. I am not a tech enthusiast but I am looking forward to the development of these open firmwares to go more further and for the support of more devices so that we can one day install this firmware by our own choice like the old thinkpads or even more easily. Hoever, thats just my hope

The level of "not making sense" of the FSF's stance on this makes me think it's rooted in an accidental technicality rather than intent. They probably wanted to certify products that were doing the best they could at a given point in time, so they made allowances for that to be possible, and now that there is a better way that still doesn't go all the way, it is not covered by that allowance because it is technically different. The other option is they're not calling you freedom-respecting if you COULD replace that proprietary software with free software, but you haven't, but they will call you freedom-respecting if you're replacing everything you can, but there is a little bit that you just can't. The idea maybe isn't to RYF-certify this or that wi-fi chip, but rather a larger product that uses them.

let's ask asahi devs to reverse engineer that shit lmao

BLOB = Binary Large OBject Binary BLOB = Bianary Binary Large OBject Can we just define BLOB and say that they are a method of distributing proprietary drivers (for both operating systems and firmware) inside of otherwise open source software? At the very least, call them BLOBs or BLOB drivers.

Meanwhile I don't even want to risk bricking my motherboard with an update, so I just let it be since it's still working fine for my hardware right now...

If I recall my microelectronics correctly, microcode is a lookup table inside the processor (stored in memory) that converts the opcode into the appropriate switching inside the processor in order to carry out the instruction. This can be in ROM (and always was when I was a lad), but could also be firmware (e.g. non-volatile ram) - though that seems like a bit of a security risk to me! The original idea behind RISC was to do away with this microcode.

In my view, a necessary first step before it's worth fussing over microcode blobs, would be getting a complete open specification for the interface to the hardware that the microcode works with... and that's closely tied to the design of the logic gates, and that's going to be a big ask.

I have Nvidia on my Linux computer and it appears to work fine, However sometimes it doesn’t get detected by my system

Whose decision was it to make security feature registers and microcode get cleared on sleep and reboot by the time 2017 rolled around? Its like unlocking your house and leaving the doors open when you go to sleep.

DragonflyBSD offers a fully libre speculative execution patch without binary blobs

I know there are projects to have open source motherboards, and they're very possible for moderately skilled people to produce, if they so desire. I think what we really need to develop is the technology to produce in some capacity processors at home, or in such a way as people could collectively fund a batch of chips to be fabricated. I know it seems unlikely, and it would be very difficult to fab chips, and definitely won't be something we'll see open sourced and competing with Intel or AMD, but open sourced and less capable for sure. If all these retro enthusiasts can source new-old stock 6502 chips and other such things, surely with enough support we should be able to find a fab that is willing to produce 15 year old designs that are still capable of handling all we need them to.

Just FYI, x86 DOES implement instructions that don't have a direct HW fast path via microcode. That's things like providing AVX-256/512 support on CPUs with 128/256bit FPUs, by having the work split in batches, or providing support for seldomly used functionality by breaking it down to a sequence of multiple built-in math and logic functions that span a couple dozen CPU cycles. In theory, all that's needed is an ALU that can do AND/OR, NOT and XOR and with the help of microcode, and the rest of the usual circuitry that's part of a CPU, you could construct a full instruction set out of that (De Morgan's theorem).

Good video, Im not sure whats my stance on the issue yet.

All I want is the kde connect Android app to have a full Amoled black theme.

Is there any CPU architecture that does not have some form of proprietary code ?

I install Arch Linux and I install the μ-code software because it's part of the installation process as I see it!! I'm pretty methodical when doing things!!

What you really mean is any CISC chip, generally with RISC chips, instructions are hardware encoded, CISC microencoded.

No x86_64 device should have been RYF-certified imo

Transparency, informed consent, clear (simplified) communication and recognizing /evaluating mistakes / policies are all part of a better firmware future. Exploiting hardware vulnerabilities is a real concern and not just a "state" or "state actor" thing, it provides a complete pwnige and god mode access to any system built on top of it. Whether a virtualization layer (bigger attack surface/ more complexity) is between it or not. Your own "state" and their "state actors" are probably using it against you. Popular topics: How is France requiring and getting remote access to cellphone camera in the future etc. on a technical level ??? How are other 3 letter agencies doing it, and how does Pegasus really work???? Btw, I know the topics are not X86 based, this problem is not unique to X86 but perhaps best understood on it.

I understand the idea behind this all. a few years ago, I saw a video, where somebody managed to run code on a harddrive controller. it had 3 arm cores, some ram and some flash memory and was fairly capable. of course it's rather pointless besides being a cool tech demo, but in theory, if you can replace the firmware on a harddrive, wouldn't that also mean that FOSS is entitled to have an open hard drive controller firmware? in my opinion, it's splitting hairs. but one thing is quire certainly: whereever you can run code, someone will want to run malware. it might be beneficial to have at least the possibility to replace the firmware with something open.

I don't see why they don't just include a small flash rom on motherboards like they do for bios?

The ending killed my faster than my system update killed my Arch system!

I got recommended this video after I bricked my PC by removing a microcode in the BIOS file. Nice.

FSF moved the goal posts because too few care about what the FSF has to think.

The people's reaction to arriving to the village: "Aight, Imma head out."

I've done some tests where I disable micro-code and mitigations (dangerous btw, dont do it), and my small C application for benchmarking went from 2 million iterations in 5 seconds (just adding a variable), all the way up to, and I'm not kidding, near 22 million (single core) However, thats not to say that other apps will perform better by the same margin~for some reason lol..

I feel like I just walked into the middle of a movie. You can update your microcode? How? I update my motherboards' bios, is that related? I thought the kernel updates would do that too, somehow.

Did Freescale use updatable microcode?

Somehow it makes me feel better that you don't how to deal with microcode either. It's about as obscure as it gets. And probably true of the vast majority of users. Maybe what we need is open source everything: routers, CPU's and microcode. Then those things would be designed for the users not for the benefit of Microsoft, Intel and Apple. Maybe RISC or ARM. And they would be more secure and faster.

So I am still confused about this right now, ever since they announced that x220 can be librebooted, but turns out it is just coreboot, and now libreboot and coreboot is the same or something? So no more actual libreboot anymore?

It sucks that Intel microcode is an opaque blob, but so long you control which version is loaded it is comparably bad to intel CPUs being opaque blobs

Call me pedantic, but I think it would be best to have a fork with the current way of small, required proprietary blobs included, just to be called something else, like Chadboot. And have Libreboot be.... you know... libre? Without any asterisks. Fully, 100% free, like it was before nov 2022. And to have them easy to recognize what they do like "oh, Libreboot is just Chadboot without any proprietary code". It's basically like it is now already, but under two different names, for different purposes and less confusion. Otherwise, I'm happy that both a) they added the proprietary stuff to make it usable on much more systems and b) that they still give you the option of having 100% free software.

Does that mean I'll be able to libreboot my x201 now? :3

So I understand the purist approach, but it's technically not feasible to have something comlpetely non-proprietary? You still need a manufacturer to assemble the hardware, and mining to gather the necessary minerals. This is all done via proprietary means isn't it? I may be conflating 2 ideas, but the idea of FOSS doesn't seem to be "the user does everything" but that "the user has agency over everything" in so far as the beginning of the user's relationship with the hardware/software.

I run coreboot on my PC Engines APU2, but that’s about all I know of it

Disappointed in Stallman for cucking on the firmware question.

Saw on feed

Brody I need some help with something I can't find any information about I have a laptop that is windows it's for work have to have it company bs however it's my laptop issue I had a m.2 that was 1 TB now for fact it is has been for the last several months almost a year it shows as 500 gb now even in the BIOS WTF I can't find anything other than a external or second SSD any clues I've used even gparted live uninstall the device it still comes back as a 500gb I didn't find any hidden partitions I'm no beginner to Linux I've used arch since it's birth ideas would be useful at this point

I'm all for freedom but at the end of the day the vast majority of us just need to get stuff done. If that means I have to use a small binary blob, so be it. I would much rather have the choice and information on my other options.

Mi favorite spec of Chromebooks is that they use libre/core boot. And as there are many brands, models CPUs and SoCs, I think it would be a great idea to fundraise one Intel (actual) desktop mother board (DMB) and one Amd (actual) DMB with libre/core boot, and better if there are any ARM DMB too for DIY PCs I think that at least 10k units each will sell, specially for SME concerned about security. And there is no need to design any from scratch as they already have laptop designs that can be adapted to desktop formats, so it is just to hire one of the mother board designers to adapt one or two of their designs to the desktop format

Libreboot's position would be more respectable if you believe every Linux user is a programmer and will bother to read the docs. Most people will just presume something called "LibreBoot" is Libre all the time and will not factor into their imagination that Libre'ness of Libreboot is an opt-in feature. Most people don't even know what Microcode is. I agree that firmware baked into the hardware is just as bad and should come with an asterisk. But realistically, if the firmware is baked into the hardware it cannot be modified remotely either, whereas the upgradeable firmware can. (Not sure what the FSFs position on FPGAs is though) If you take the position that any hardware that has proprietary software baked into it's hardware from the factory is non-free then realistically, nothing IS free and the FSF's recommendations would need to boil down to "run for the hills, all is lost!" so i kinda understand the compromise on that front.

I looked at coreboot...laughed...and continued on. I use the AMD microcode provided by Arch and run systemd-boot. I just added one line in the boot entry file and all set. The FSF have some good ideas, but in general their 'hardcore-ed-ness' feels a lot like religious zealotry at times. This is one of those cases. My main machine is an older beefed out FX CPU with 32gig ram and an RX580 GPU. (desktop stuff, plex server AND some Steam stuff.) Works like a charm. I use the microcode because the motherboard/cpu do not receive bios/firmware updates any longer. Gaming would be the ONLY reason for me to upgrade, but most of the games don't strain either the CPU or GPU and those that do give it a workout still achieve playable FPS. The rest works aces.

I really respect the core/libreboot projects and I hope I'll be able to use one of them during my lifetime. Sadly, support for mainstream hardware, where it really makes a difference, is abysmal at best. Hopefully OpenSIL makes an actual, meaningful, applicable headway in that direction.

If device must use bloatware, then more secure approach would be INFORM USERS that they're not secure, and would be better with hardware X... But... That would be a monopolization? ... So NO freedom for us anyway... WE ARE SCREWED!!! Libre is just a fancy name... like "security"... It's just a business...

Can the micro code on the CPU be modified using Linux?

FSF gonna be batshit crazy FSF…

Why not just provide two versions then? Hide the microcode behind a build flag and build twice. If it's all about the freedom of choice, then why not give the user the choice.

I do not believe you could use an FPGA to create a general purpose CPU that had performance on par with a new CPU manufactured the regular way.

actually it is a bad thing, as libreboot gave inspiration to develop a bios without NSA backdoor in chipsets, now much more less people will care about it anymore. And about microcode, actually updating microcode on modern systems, makes them slower by ~15%

Interesting, but not my biggest concern. It seems to me that changing microcode might be comparable to brain surgery. Microcode, despite the name, really needs to be considered more like hardware than software. While CPU manufacturers should probably have the ability to do microcode updates, it is something that even they should only do as a last resort, and nobody else should likely be dicking around with it at all. Having said this, as part of the package, CPU manufacturers include secondary hardware on the CPU chip, such as onboard GPUs and secondary microcontrollers. Notably, there is a 'feature' called Wake-on-LAN on many Intel CPUs which allows a powered down computer, to be booted remotely. Unless I'm sadly mistaken, this is implemented with a secondary microcontroller on the die (always running in the background, provided the computer is still plugged in.) Even though the computer is off, the network hardware is listening in the background. When a special packet is received, it is this microcontroller which springs to life and boots the machine. Clearly, this could be a very useful feature, but at the same time could clearly be abused. My point is, this and other 'features' are baked into the hardware on the CPU and either cannot, or are very difficult to disable, although a network card can bypass this 'feature.' As for having control over the microcode, I wonder if Risc-V might make sense. Risc-V is open, in the sense that anyone can design their own extensions to the ISA. So, if someone hasn't done it already, it might be interesting to have a Risc-V CPU with fully programmable microcode, meaning users could implement their own extensions to the ISA, without needing to fabricate their own chips.

Depends on what microcode means. I was taught that it was the code that defined the instruction set, because the software instructions that are executed from memory do not encode all the low-level information needed to carry out the instruction, so that information was wired into a diode array or ROM that may or may not be modified after manufacturing. But now when Intel or AMD issue microcode updates, the blob may include the architectural microcode or updates to the burned-in microcode, along with firmware that runs on the embedded management processor or management engine (ME). The ME is a secondary embedded processor, per the RYF definition, so that software supplied as "microcode" should fall under the exception. Whether the architectural microcode is physically located "inside a processor" before execution shouldn't matter. An exception is made for the gate pattern of an FPGA, which is generally stored in a ROM external to the FPGA package. CPU microcode can actually change functionality, and it does so in the same way as an FPGA, by being loaded into SRAM from an internal or external ROM. In modern systems the firmware is encrypted, with the public key "deeply embedded" and "part of the hardware" according the libreboot graphic, so as long as the manufacturer keeps the private keys secret there isn't any practical difference, short of decapping a chip and patching the firmware with a laser or electron beam, or voltage glitching a processor for hours until it accepts your signing key. So the binary blob is effectively "part of the hardware" even if it's on the hard drive and uploaded by a Linux driver. A peripheral can even have some flash memory to retain the latest supplied firmware, so the driver only needs to upload the firmware to update it instead of on every boot, which is similar to microcode issued as part of the motherboard firmware. I've accepted that some parts of a system are opaque and not meant to be user-modified. All I want is to be informed of any functional changes due to updates so I can determine the level of risk and to have the option to reject an update if I decide it's not worth changing

Meanwhile compositors...

okay

My perspective on this is simple: Microcode and firmware are part of the hardware. Sure, open hardware would be nice but if you're using closed hardware you don't get to complain about closed microcode and firmware.

To call this not free, I'm not sure about that. There's no other way to fix any of this without the openness of Intel and AMD of course too providing the code. Do they ask for money for it, I doubt it. lol Can the FSF or FOSS anyone within really able to back engineer some code for these CPUs. Oh wait you'll get sued..... lmao

I'd like that choice. If you want to hack your processor with undocumented instructions etc it's nice with a CPU that doesn't change behaviour on you.

I ain't updating no microcode

Oh, "libre boot" Here I thought it was "lib reboot" until I heard him say it out loud.

you are wrong all x86 cpus are an fpga because it is faster to emulate an inefficient instruction set like x86 using an fpga instead of executing instructions when they added cancer code like ring -3 and microcode they also turned the cpu into a re-programmable fpga so if you exploit the cpu to run unsigned code or self signed code you can reprogram how it works and make it much faster by removing security and instead exploiting those security holes so you can know if anyone else is using them and reset the computer if they are exploited instead of nerfing speculative execution like microcode does now

Discord notification gang

Hmm... apparently it supports haswell boards? I still have a motherboard I got in 2015 that uses a core i7 4790k. I was going to repurpose it at some point, this would definitely be a plus!

the software philosophy crowd can be annoying and hypocritical sometimes indeed

Yt notification gang

While I like they libre idea and would like open hardware with an open BIOS and so on, the level of complexity is staggering. The existing CPU and BIOS world is so closed that I don't see any solution for this ever to be solved. Hardware companies has no intention to release data because then others will just copy it. Isn't there a country... Look at the 8-Bit community as reference. You would think that's much easier but even there, creating a hardware that most like, is riddled with supply problems and delays and years pass until something new is developed. In fact most don't build something new, they repair or remake old gaming computers just to have access to already written games. We have to admit defeat. To many have magical thinking and cargo cult behavior and think it will be better in the future someone will just build it, but it gets worse. We humans are way to egoistic for it to ever work.

9:00 I disagree...currently with CPUs costing around 300 - 1k a programmable firmware isn't going to be more expensive and by the way it looks like Intel on their latest or next type of CPU is going to get sickening using the old "software upgradable hardware" tactic where they are going to license to use certain parts of their Xeon processors dedicated to ai...

10:58 plain wrong he startet requiring intel me for his stuff lol.

If it was pronounced "leeb-rey", it would be spelt libré. It's "lee-bruh".

There is being right and then there is being practical. If you want to perpetually live with ancient hardware, go ahead. I dont.

I've never updated any microcode. Actually I don't know how. But this seems to me like it's a little bit of fear-mongering. My CPU is now roughly 9 years old.. still working.

It's highly pretentious to claim binary blobs are inherently evil if you use your libre firmware on proprietary hardware. We have no idea what hides in-between the layers of a PCB and claiming you know the motherboard better than the manufacturer itself is dangerous if not outright foolish. Not to mention that the supported hardware of libre and core boot is so out of date, using it puts you at much higher risk than using a modern proprietary system. Freedom isn't always the best choice... Or how would you rate the American healthcare system?

freedom to be less free oh man americans gone too far 😂

The BLOB dilemma

Broken CPU for me thanks. Proprietary software is simply unacceptable. In fact, even hardware should be open source. Manufacturers should be forced to share full chip blueprints and everything. Just like I can build open software to test it. I should be able to dope and etch my own silicon and burn in Intel's hardware designs to test it.

I just want to use my computer, not being part of yet another cult. I'll stick with whatever works for me, free or not.

I'm all for the principle of something like libreboot - but the hardware support list reads to me like an archaeological dig site. I mean come on most of this stuff dates from pre-biblical times! If they want mass support we are going to need to see some rather more recent hardware being supported. 8th or 9th gen intel is probably the very oldest that I might possibly *think* about considering using, and realistically 10th, 11th or 12th would be a lot better.

by that logic prostitution and drugs should be legalized because banning them makes you less free

FSF 🤡

This is silly. While I don't use LibreBoot and think it was never an optimal direction to go freedom wise (because of the inevitable fact it would never support newer Intel or AMD systems which has turned out to be the case as least to the extent it did what it originally did and the intent was) and want to see more people use free software LibreBoot was created as a fork of CoreBoot without the non-free software for the purpose of giving the most determined freer options. Security and stability isn't the primary focus here. If I wanted CoreBoot I'd have just gotten CoreBoot. CoreBoot and LibreBoot are both a bit overblown and been more public relation stunts than genuinely useful. What we need are people focusing on designing hardware from the ground up built off non-x86 SoCs and people focused on resolving the issues with wifi. We are good for a few more years with wifi... but then what? We're screwed. We're already screwed at this level with Intel/AMD CPUs. Ultimately the change is the result of Lea making poor decisions early on to create LibreBoot in the first place knowing full well it would never be possible to keep going with the stated original goals. She is now going back on those original intent of the project for financial gain. Her motivation for including proprietary software is money. There is nothing wrong with money, but what she should have done was not go down the de-blob coreboot route. She should have focused her energy on something else. There are plenty of efforts she could have put her time in that would have advanced free software. This just wasn't one of them.