LWN: Comments on "Debian to vote on its firmware path"

Debian to vote on its firmware path

brunowolff — Tue, 13 Sep 2022 21:12:12 +0000

There was, but IMO the best explanation I saw for this was to allow for Windows to trust some software signed by the NSA to make it easier for them to use Windows in house, rather than an attack on general Windows users.

Debian to vote on its firmware path

LtWorf — Tue, 13 Sep 2022 06:49:55 +0000

The thing is that the non-free image that everyone uses already exists.

This is just to make it discoverable by everyone rather than just the insiders.

The thinking is that it is better for people to use debian with non-free firmware rather than use osx or windows. Maybe those people will contribute to freedom, if they are allowed to have a taste of it.

Debian to vote on its firmware path

ayay — Tue, 13 Sep 2022 00:15:47 +0000

It's not great, but it is what it is.

The nonfree ISO may be a little out of of the way, but if you're walking your friends through it, you can point it to them.

Ubuntu is there for the folks who want it easy. And Debian is fine with that too!

I fail to comprehend why a distro that is famous for its steadfast stance on things *must* change *right now* all of a sudden.

Many of the things we take for granted today are a direct result of all the "basement dwellers" that were "screaming about software freedom, but wouldn't ever shave their necks". I was young, but I was there, and that corporate drivel was *almost* effective in convincing me that, well, maybe proprietary is where it is at after all. I owe those neckbeards a beer or two, proprietary software is bad, unreliable, annoying, and expensive. Myself, I would rather deal with Debian's hidden non-free ISO any time of the day.

Thanks to these stubborn individuals, here we are. Nowhere near perfection, but the "freedom" aspect certainly materialized to a point where former dinosaurs now try to exploit for their gain.

We don't really care, we want to tinker. But we shall never fold.

Debian to vote on its firmware path

ayay — Tue, 13 Sep 2022 00:01:25 +0000

As someone who very often goes for the nonfree ISO on bare metal, I agree.

Of course, I want things to "just work". But Debian being Debian forces me to pay attention: next time I am out buying hardware, I want it to work without nonfree firmware if feasible. I'll install it to squeeze that extra oomph if needed be, stuff is expensive. I have to, but I don't like it.

I tend to run my gear to the ground. Manufacturers abandon things too early. The community doesn't, provided they can carry on.

Case in point: OpenWRT... I flat out refuse to buy anything OpenWRT does not support, because vendor support for consumer - and even prosumer/business, if you ask me - tends to be trash if you're an individual/small business.

OpenWRT is reliable, saved a *LOT* of my gear from the landfill along the years, and just goes on and on and on. It respects me as an user, and in turn I respect its developers. I trust them to not take this stance just out of spite.

Same goes for Debian.

My ath9k devices from 2014 are rocking solid and show no signs of giving up. That's how it should be, and it's all thanks to OpenWRT. I know D-Link and TP-Link could not care less, even if I paid them to do just that!

The landscape for Debian is different than OpenWRT's (thanks to ath9k I assume?), but they still fight the good fight. It may look like a sucker punch - far from it. It raises awareness. And, as things start to gain steam on that direction, with a bunch of new players looking to disrupt the market, RISC-V on the horizon, and so on, it is the worst time possible to abandon this stubborn, yet absolutely necessary stance.

I'll keep using the nonfree iso when I must, and I hope that, one day, I won't have to. Keep fighting the good fight, Debian.

Debian to vote on its firmware path

flussence — Fri, 09 Sep 2022 20:48:34 +0000

Yes that sounds more plausible, thanks for clearing that up. Those ncurses things have a bit of a "chicken chicken chicken" problem.

(OTOH you've now reminded me of how Debian has a bizarre inversion of control regarding where it asks for user input and where it does things completely automatically - like starting listening services)

Debian to vote on its firmware path

paulj — Fri, 09 Sep 2022 09:41:05 +0000

"albeit that Intel current manufacture their own chips"

Not sure if that will be true for much longer, least universally. E.g., the information on the new Ponte Vecchio HPC chips is that some of the tiles in the package will be produced by TSMC. The same sources that broke this (now confirmed) also say Intel has plans to have TSMC produce some CPUs.

Debian to vote on its firmware path

farnz — Fri, 09 Sep 2022 08:44:42 +0000

No - I'm making a much more subtle argument than that, relating to the size of my trust base.

I have to trust AMD's designs, and AMD's manufacturing partner for silicon, when using AMD CPUs. That's just a fact of life as it is at the moment; if I used Intel CPUs, I'd just change the word AMD for Intel in that sentence, and it'd still hold true (albeit that Intel current manufacture their own chips). Same applies for any CPU vendor - I trust that vendor's designs, and I trust that their manufacturing will implement the design as created by the vendor, not a modified version to target me.

That is the core trust base I have when using any CPU - I can't avoid trusting the designer and the manufacturer of the silicon. Beyond that, my trust base can be extended by design decisions - for example, in a traditional cloud system (without AMD-SEV), I must also trust the motherboard manufacturer, the BIOS vendor, the DIMM manufacturer, the DRAM chip maker, the hypervisor vendor, the hypervisor operator, and the datacenter owner.

The promise of AMD-SEV is that I no longer need to trust as large a trust base, because AMD-SEV uses cryptography to remove all but AMD from the trust base. I still have to trust AMD and whoever made the CPU, but I no longer have to trust all the other parties involved, since they can only see encrypted data, and cannot get the key. The value of this promise is, however, weakened by the fact that we can't see into the memory controller startup blob - because it is entirely opaque, there is a reasonable possibility that AMD used the startup blob to disable AMD-SEV debug features that break the promises of AMD-SEV (and I would consider having these features that can be disabled in a one-way operation to be entirely reasonable on AMD's part - they need to be able to debug things if their chips misbehave in their labs). And because there is one combined blob that contains both AMD-supplied code and motherboard vendor code, the effect of this is to widen my trust base for AMD-SEV from "just AMD" to "AMD and the motherboard vendor".

There's at least two routes AMD could take to reduce the size of the trust base back down to that promised by AMD-SEV:

Split the blob. Have two blobs, one from AMD that does cache-as-RAM setup and anything needed to make AMD-SEV safe, and a second from the motherboard vendor that does the DRAM training. This would allow me to verify that the AMD blob is indeed from AMD, without needing to trust the motherboard vendor too.
Open up the AMD parts of the blob - fully describe the blob and its system accesses, so that I can validate that the blob from my motherboard vendor only touches the registers that are involved in DRAM training (and thus can be confident that I only need to trust AMD, since my motherboard vendor has done nothing that AMD say is suspicious).

Both work - you will notice that one of them doesn't even involve opening up the blob. But unless AMD do one of the two options, I have no way of telling whether or not the blob expands my trust domain to include the motherboard vendor, or whether it in fact limits me to just trusting AMD because the motherboard vendor modifications aren't able to affect AMD-SEV.

Debian to vote on its firmware path

ras — Fri, 09 Sep 2022 05:41:17 +0000

> While a fully open end-to-end verified system would definitely be nicer, it's still not possible to be 100% confident that AMD-SEV only requires you to trust AMD

You are saying because there may be bugs / mistakes in AMD's implementation, it's not possible to be 100% confident AMD-SEV works as advertised. That is totally correct. In fact if someone offered me a bet that someone will find a way past it in the next decade years, I'd take it. (If it was Intel SGX, I'd be happy to reduce the period to months.)

But it's an impossible standard. Flip the argument. Lets say it was all open source. Would it be possible to be 100% confident and say there are no bugs and thus 100% trustworthy? Of course not. I'd be happy to take the same bet.

I'll let you ruminate on where that leaves us, but clearly it isn't: Security is complex. All complex technology has bugs. Ergo we can't 100% trust the security of our systems. (I hold those statements as self-evident.) Therefore we should give up on security.

And no, open source does not solve that problem.

Debian to vote on its firmware path

farnz — Thu, 08 Sep 2022 12:57:45 +0000

You are, however, taking it on trust that the version of the blob supplied to AMD's partners only lets them change link training parameters, and can't be modified to run before AMD's part of the blob locks out low-level debug registers (or that AMD's registers for debugging AMD-SEV cannot be misused to compromise AMD-SEV).

While a fully open end-to-end verified system would definitely be nicer, it's still not possible to be 100% confident that AMD-SEV only requires you to trust AMD, and not your motherboard manufacturer with the current setup; in theory, AMD could separate out the part of the blob that does cache-as-RAM setup and also takes responsibility for locking out debug registers from the part that does DRAM link training, and allow you to confirm that the AMD blob is signed separately to the motherboard vendor blob, but that's not how it works today - instead, the early boot code is a single blob, and you can't tell if it's AMD's blob or not.

As it is, though, it's not implausible that AMD has debug registers that can be locked out with a single MSR write, and that cause AMD-SEV to make the encryption key visible to a debugging system (either via software, or to external hardware attached to the CPU under test). In normal operation, those registers would be locked out before DRAM training happens (hence before AMD-SEV is relevant), but a modified blob would be able to leave those registers exposed.

And this is the deep-seated trouble with completely closed firmware like the DRAM training firmware for Intel + AMD CPUs; we don't know what it actually does, and therefore whether there's a trust boundary between AMD/Intel and the motherboard vendor, or whether the actual design merges them together for the purposes of trust.

Debian to vote on its firmware path

ras — Thu, 08 Sep 2022 05:52:07 +0000

> The binary blob that sets up the memory channel is supplied to you by the motherboard manufacturer - and at least the last time I had this level of access, the motherboard manufacturer has the ability to rebuild that blob with changes, because you do want to be able to do things like rule out specific settings that, while legitimate for the CPU, will cause EMC issues because of the specific length of motherboard traces, and to rearrange the order in which different options are tested to increase the chances of finding the right training settings first attempt.

Yes, of course. But none of that will allow the firmware blob to see what is in memory. If it did, AMD-SEV would be a lost cause.

The point I was trying to make is this statement by khim is too broad:

> If you want to ensure that your CPU wouldn't be under control of NSA then you first need to design something which doesn't depend on binary blobs to, you know, access the RAM.

Untrusted binary blobs running in any card with DMA may well have access to the RAM. Hell, the untrusted drivers in the host OS will probably have access to all of RAM. But we don't need to "first design something" to fix that. AMD-SEV fixes it, and it's available now.

The point khim is making about it being easier to run Windows than it is to run Linux on consumer hardware still stands, of course. I wasn't try to argue against it - it's always been true. And yes that means most people, even college IT students, if forced to use Linux will take the easiest path and just run it under Windows. It's a new(ish) phenomenon. It sounds ominous but it's actually a huge win, because being forced to become familiar with Linux is new. I doubt it was altruistic motives that caused Microsoft to release WSL - it was fear of losing those users, users who will be making corporate IT decisions in the future. And in the meantime the true believers will continue fight tooth and nail to run only open source on bare metal just as they've been doing for the last 25 years. I suspect khim loses sight of the fact that while as a proportion of the "IT industry" the number of true believers is being diluted, I strongly suspect in absolute terms their numbers they have always been growing, and are consequently a much larger force to be reckoned with than 25 years ago. They may never win their fight completely, but I doubt they will ever lose it either.

Debian to vote on its firmware path

pabs — Thu, 08 Sep 2022 02:35:31 +0000

There has been research into modifying CPU microcode that might eventually allow free microcode:

https://www.usenix.org/conference/usenixsecurity17/techni...
https://github.com/RUB-SysSec/Microcode

It is very likely that the CPUs don't have enough storage to update *all* of the non-free microcode in ROM, but patching a small part of it might be doable. This is definitely the case for other "free" firmware too, some of the WiFi/GSM firmware is like that.

Debian to vote on its firmware path

farnz — Wed, 07 Sep 2022 12:23:02 +0000

The binary blob that sets up the memory channel is supplied to you by the motherboard manufacturer - and at least the last time I had this level of access, the motherboard manufacturer has the ability to rebuild that blob with changes, because you do want to be able to do things like rule out specific settings that, while legitimate for the CPU, will cause EMC issues because of the specific length of motherboard traces, and to rearrange the order in which different options are tested to increase the chances of finding the right training settings first attempt. That includes the ability for the motherboard manufacturer to sign the blob that goes onto their motherboards, so that the CPU will run it.

And debug modes that are controlled by a one-way disable are not uncommon in hardware design - once the debug mode has been disabled (and the AMD-supplied code will do this for you), it can never be re-enabled at runtime, which makes it useless for researchers (since the normal AMD blob will turn off debug modes before training DRAM, so you have no ability to turn them back on). As there's no visibility into this process, you can't tell if this is going on - you're taking it on trust that AMD either has no ability to debug AMD-SEV silicon bugs (sounds unlikely to me) or has correctly written the binary blob such that it disables debug options before training DRAM, and that no-one who is in a position to tamper with the blob has done so.

With open-source firmware, you would not have to trust that the blob you are running is unmodified from AMD's version and could look for mistakes in the very early bring-up code. It seems unlikely given the research into breaking AMD-SEV that they have badly implemented debug options (it's trivial in ASIC design to design a write-only register that starts up in the "enabled" state, and switches to a hard disabled state on any write, and I would expect AMD to be competent enough to not have debug features turned on when the debug control register is set to a hard disabled state), but that doesn't protect you if the motherboard manufacturer can change the code you run.

Debian to vote on its firmware path

ras — Wed, 07 Sep 2022 10:28:00 +0000

> The challenging part is that the binary blob is what brings up the memory channel,

The encryption is done on the CPU die, so I presume the binary blob comes from AMD. As I said, trusting AMD is assumed - and that includes trusting all binary blobs that come from them.

> Further, you have to take updates to this code from your motherboard vendor on trust - you have no easy way to tell whether a given update is direct from AMD, or has been altered by the motherboard vendor on the request of a dodgy agency.

I haven't checked, but surely AMD digital signs their CPU firmware, and the chip only accepts something signed appropriately?

> It's entirely plausible that there's debug modes in the memory channel that break your assumptions,

It doesn't sound too plausible to me. There has been some research into attacks against AMD-SEV already, which have found weaknesses. (I don't know whether they were fatal.) IIRC, they involve modifying the encrypted memory (which of course then yields junk when de-encrypted), and observing what happens when it is used. Repeat that until you see a pattern. It just doesn't sound reasonable they would miss something as obvious as using debug mode to spy on a memory channel.

> This is why open-source firmware is interesting

It is why a totally open source solution is interesting. If the chip is RISC-V, and the VHDL is open source, and you have a "reproducible build" (I have no idea what that would look like for hardware), then there is no need to trust AMD. You can verify it yourself. Of course the firmware must be open source too, because you have to trust the entire stack, just as you say.

But if you don't trust he hardware, all bets are off. It doesn't matter if the firmware is open source or not. There will be non upgradeable ROM firmware on the CPU - even if it's just to load the uploadable RAM replacement. It could be doing anything, including loading your open source firmware then throwing it away. This is why open source firmware alone is not so interesting if you are looking at it from just a security standpoint. It has to be turtles all the way down.

Debian to vote on its firmware path

farnz — Wed, 07 Sep 2022 09:11:16 +0000

The challenging part is that the binary blob is what brings up the memory channel, which is in the trust path. It's entirely plausible that there's debug modes in the memory channel that break your assumptions, and that the binary blob is responsible for locking out into the "production" config. That makes the binary blob running on the CPU during early boot (before UEFI starts up in a traditional firmware) a part of the trusted base for AMD-SEV, and yet it's software-modifiable (stored in the machine's reflashable firmware store).

Further, you have to take updates to this code from your motherboard vendor on trust - you have no easy way to tell whether a given update is direct from AMD, or has been altered by the motherboard vendor on the request of a dodgy agency. This means that your trusted base is not just AMD, but also your motherboard vendor (since they are in a position to install a signing key into the system as a whole that results in the early firmware being trusted) - and potentially everyone who had access to the motherboard before it arrives in your datacentre.

This is why open-source firmware is interesting: you can confirm that the firmware you're running is the firmware you expect and not backdoored by the motherboard vendor (or in transit) since you can replace the flash storage (wiping out old on-CPU TPM keys in the process, since those live in the flash) on arrival, and you know what the firmware you're putting on there does. Your trust base is thus reduced from "is the binary blob the motherboard vendor supplied actually AMD's blob, and does it do what AMD promise" to "does the hardware AMD sold me contain hidden storage, and does it work as promised".

Debian to vote on its firmware path

IanKelling — Wed, 07 Sep 2022 06:37:09 +0000

Free microcode updates would be good. Yes, most people are probably better off from a software freedom perspective with cpus that have no microcode at all. Afaik, those have historically had less security flaws too. But there are some freedom related reasons a person could be an exception. I started to write them down, but it got a bit long and I need to stop. I'll try to finish in the next week and post.

Debian to vote on its firmware path

ras — Wed, 07 Sep 2022 01:03:53 +0000

> IIUC, AMD-SEV is later in the process; the "binary blob" khim refers to is the firmware blob that runs on a CPU that's just booted up, and first enables "cache-as-RAM" then sets up the DRAM controllers. Without running this firmware blob on your CPU, you have no DRAM, and no cache either.

That probably doesn't matter. This "trust relationship" really means setting up a set of keys the the host doesn't know about. It's the same in principle as the DRM running in the browser. Provided no one can crack the DRM module, the content being sent is safe - despite it being handled by a huge pile of untrusted code. The browser DRM is just software of course, so anyone believing it can't be cracked is in a state of sin. And the "analogue hole" still remains wide open, although it's no so analogue because it's passing through the kernel.

Since the AES keys are in principle a secret tightly held between on CPU TPM, the owner of the VM, and the memory channel doing the encrypting they should be safe from anything that can't see into those things. But this is all provided by AMD. If you don't trust AMD to do it right then it's all over, as they could sabotage the whole thing in a zillion different ways you have no hope of discovering. So 100% trust is a given. The point is you can get away with just trusting AMD, but not the Russian's, despite the Russian's having physical custody of the CPU, and total control of the host OS running the VM - and total access to the memory.

That also applies in reverse. If the Russian's trust AMD 100%, they should be able to run a VM on a AMD-SEV machine controlled by the NSA. But the Russian's trusting a US company who is presumably subservient to the NSA would be quite a stretch, as you say.

Debian to vote on its firmware path

mjg59 — Tue, 06 Sep 2022 22:54:54 +0000

But if a CPU allows (even proprietary) microcode updates that provide mechanisms to mitigate the security flaws, your argument is that it's still preferable from a freedom perspective to use one that doesn't?

Debian to vote on its firmware path

IanKelling — Tue, 06 Sep 2022 22:41:03 +0000

The bugs don't make using the cpu insecure, they change the security assumptions, you can operate within those assumptions, migrate certain certain use cases to a different cpu, there are various solutions. Of course those bugs existed the whole time and security is not a binary.

Debian to vote on its firmware path

IanKelling — Tue, 06 Sep 2022 21:29:12 +0000

> Obviously, A is preferable over B or C, but doesn't B give more freedom than C

It is fine to prefer C over and A and B. I would for my toaster which is simple and has no networking ability, and I wouldn't really characterize the difference as losing an important freedom compared to B. Beyond that I don't have time to give a comprehensive answer. I would also mention that there is some widespread firmware which can only be updated with encrypted & cryptographically signed version where only the manufacturer has the key so it is almost impossible to reverse engineer, so doesn't fit into your categories.

Debian to vote on its firmware path

IanKelling — Tue, 06 Sep 2022 21:17:04 +0000

Valuing "functional purpose" above all, you can say it is a waste of time for me to vote, it won't ever change an election. Not voting in one circumstance does not make it hypocritical to vote in another.

About who ships what, of course it matters: "What they do on their own is their responsibility; what we do for them, and what we direct them towards, is ours" https://www.gnu.org/philosophy/compromise.en.html , and that article talks more about this general issue.

Debian to vote on its firmware path

farnz — Tue, 06 Sep 2022 14:11:12 +0000

IIUC, AMD-SEV is later in the process; the "binary blob" khim refers to is the firmware blob that runs on a CPU that's just booted up, and first enables "cache-as-RAM" then sets up the DRAM controllers. Without running this firmware blob on your CPU, you have no DRAM, and no cache either.

Now, chances are that this blob is not hugely interesting - it'll be doing the sorts of things needed to do DDR4 training, which aren't scary, but are a decent amount of code (all to handle the fact that real world devices don't stay at a perfectly fixed setting after manufacture, but rather change in behaviour when in the field) - but it's an ideal hiding place for malicious code since it runs first, and sets up the "known good" state for this CPU.

Debian to vote on its firmware path

khim — Tue, 06 Sep 2022 11:43:08 +0000

I don't think you understand what I wrote. Please read again.

The problem is not that you can not trust memory. The problem is that to even access that memory in a modern system you have to execute a binary blob (large one, megabytes-sized!) on the host cpu!

I don't fear for NSA. If they control AMD, IBM, Intel… they probably can safely run that OS in Russia.

But would Russians be able to do the opposite? I'm not so sure.

And normal Debian users have much less resources than Russia.

Pretending that this refusal to include loadable firmware helps anyone is sanctimony: you give something which can not be ever used without binary blobs (because old system which could be used without binary blobs are fast becoming history and it's not even clear how long Debian would be usable on them) to people yet refuse to support much more benign firmware in WiFi or Sound cards because it's supposed to protect someone… who would that protect and from which disease?

Debian to vote on its firmware path

ras — Tue, 06 Sep 2022 10:59:54 +0000

> If you want to ensure that your CPU wouldn't be under control of NSA then you first need to design something which doesn't depend on binary blobs to, you know, access the RAM.

Accessing the RAM securely isn't an insurmountable problem. To wit: AMD-SEV. Used in the right way your VM is then secure from the host OS. Or at least I think so - I haven't looked closely enough to be 100% positive. Currently my mental model of what it does is if you have a host running on AMD-SEV in Russia, the NSA should be able to able to run a VM this totally Russian controlled OS safely (bugs, side channels, and god knows what else notwithstanding). It works because the NSA should be able to secure a rock solid trust relationship with TPM in the AMD CPU that bypasses the host. All the host sees is an encrypted blob of data, and presumably secure network comms flowing in and out.

So no, even if you are swimming in an ocean of non-free firmware you don't trust, in principle it doesn't have to be allowed access and total control of the space you live in. I'll grant you it does right now. But that's at loggerheads with security concerns. Just as I can't see NSA or the military being happy with WiFi controller with DMA access to RAM and getting it's firmware from China, I imagine China feels the same way about Windows. So there are forces pushing towards isolation of the components. Whether it happens is an interesting question, but a commoditized WiFi controller you don't have to trust even though it receives non-free firmware updates is probably attractive to the people AMD-SEV is being sold to.

Debian to vote on its firmware path

geert — Tue, 06 Sep 2022 08:34:14 +0000

Based on my anecdotical evidence, there are more WINE and MONO deployments than bare-metal Windows deployments ;-)

Debian to vote on its firmware path

mpr22 — Mon, 05 Sep 2022 18:17:58 +0000

> Any linux installation takes much less time than installing windows. Have you ever installed windows?

Why would someone who wants WSL install windows? Their computer probably came with it pre-installed.

Debian to vote on its firmware path

LtWorf — Mon, 05 Sep 2022 17:23:45 +0000

> Yes, but no. That's something which existing GNU/Linux often can not understand.

GNU/Linux is a collection of software. It is expected that software does not understand. Same goes for rocks and buckets of water. Why are we discussing this?

> The majority of people are not looking for a ways to tune stuff they use. They just need to solve task which they need or want to solve.

Do you think the only people purchasing hergonomic hardware are GNU/Linux users? Why would that be? Do you have a source? Empirically, GNU/Linux users do not look any different than other people, so I guess anyone spending enough time on a device or having some health issues might want some ergonomics. The shape of the human body is not correlated to the kernel of the computer.

If you have any academic source that goes against this intuitive idea, I'd be very interested in reading it.

> If their keyboard comes with Control below Shift then that's what they would use. Period.

There is a whole market online for keyboard stickers for people who do not use the layout that is printed on their keyboard. Also people travel and might not want to use the local layout. People can travel regardless of the kernel they mostly use.

> That's why one of the biggest changes in [rustup] 1.25.0 is the new offer on Windows installs to auto-install the Visual Studio 2022 compilers.

Installing anything on windows is certainly not easier than on any distribution. Unless you claim that selecting a software and clicking install is somehow harder than finding a setup online and then click your way trough (avoiding browser bars and whatnot), then having it spawn sub-setups to install c++ redist and so on.

> And if WSL gives working WiFi in 5 minutes while native Linux installation takes days… WSL would be used. And that's it.

Any linux installation takes much less time than installing windows. Have you ever installed windows? It takes several hours against a few minutes for a linux install. And when you're done you must figure out the magic shell commands to enable WSL.

> Yes. But the majority of users would never know that. Because for them Linux is that strange thing in a black box which they can use when they open WSL.

Do you have any data to back this claim?

I understand it is like this for you. But people other than yourself might not be identical clones.

> Once they have solved their immediate problems (the ability to develop and deploy server software or the ability to finish coursework in college)

Problem is that testing software in a VM doesn't mean the software will work when deployed. For example there is an interesting issue at the moment in ubuntu jammy that makes git crash when it runs in some VM.

> Why should they? How would they ever know it may bring them more than WSL?

I could ask you the same question. Why use windows if you are trying to use linux? Then you have 2 systems that break and need fixing instead of just 1. Seems a thing that professionals can't afford.

> It's not X11 forwarding. Wayland works, too.

Wayland isn't production ready.

> But if you want you can continue to pat yourself on the back

This comment is getting repetitive. Moreover in this context it is misused.

> Just don't expect that others would help you. They would grow up with WSL and that's the only kind of Linux they would know and support.

If everybody was using windows, what would even be the point of WSL? People could just do native software. Why make slow software for a vm that runs inside windows instead of just targeting windows, since according to you nobody targets anything else?

WSL exists precisely because windows is no longer the only important platform.

Now you can pat yourself on the back a bit :)

Debian to vote on its firmware path

Wol — Mon, 05 Sep 2022 10:26:48 +0000

Sony PS/2 and a warranty repair?

Cheers,
Wol

Debian to vote on its firmware path

atnot — Mon, 05 Sep 2022 10:14:21 +0000

I doubt it's even true at that, most microcontrollers used in OSHW designs have proprietary bootloaders, at minimum in mask ROM.

Debian to vote on its firmware path

geert — Mon, 05 Sep 2022 08:39:52 +0000

Can you refuse the upgrade?

Option B gives the manufacturer the power to make the device unusable, which is not the case with option A.

Debian to vote on its firmware path

intelfx — Sun, 04 Sep 2022 23:33:41 +0000

> That is far from true for keyboards. I'm typing on a keyboard with 100% free firmware

What you have is a ridiculously rare exception.

Debian to vote on its firmware path

pabs — Sun, 04 Sep 2022 11:39:10 +0000

Ideally it would be in non-free too for backwards compatibility, but as I understand it, that won't happen.

Debian to vote on its firmware path

khim — Sun, 04 Sep 2022 11:22:19 +0000

> Ergonomicity seems like it should be important for such a supposedly perfect for users solution.

Yes, but no. That's something which existing GNU/Linux often can not understand.

The majority of people are not looking for a ways to tune stuff they use. They just need to solve task which they need or want to solve.

If their keyboard comes with Control below Shift then that's what they would use. Period.

> Both work fine on linux.

Nope. That's why we have an article we are discussing. Layman is not taught to look on forums to find solution. S/he is taught to click “Install”, “Ok”, “Agree” and that's it. That's why one of the biggest changes in [rustup] 1.25.0 is the new offer on Windows installs to auto-install the Visual Studio 2022 compilers.

Before newbie would be ready to read forums and fight for working sound, wifi or CapsLock-an-Control s/he would try all simple options. And if WSL gives working WiFi in 5 minutes while native Linux installation takes days… WSL would be used. And that's it.

> You can just use linux and have both sound AND ergonomic input method.

Yes. But the majority of users would never know that. Because for them Linux is that strange thing in a black box which they can use when they open WSL.

Once they have solved their immediate problems (the ability to develop and deploy server software or the ability to finish coursework in college) they may try to play with other settings, but they wouldn't go back to try to install Linux again. Why should they? How would they ever know it may bring them more than WSL?

> X11 forwarding has existed since forever. But many extension won't run this way.

It's not X11 forwarding. Wayland works, too. But if you want you can continue to pat yourself on the back, it's your choice, ultimately.

Just don't expect that others would help you. They would grow up with WSL and that's the only kind of Linux they would know and support.

Debian to vote on its firmware path

LtWorf — Sun, 04 Sep 2022 07:33:39 +0000

> Yes, you can.

X11 forwarding has existed since forever. But many extension won't run this way.

> Sure, but why is that a problem?

Try it, the joint of your pinky will thank you. Ergonomicity seems like it should be important for such a supposedly perfect for users solution.

> Most users want working WiFi and sound

Both work fine on linux

> much more then they want the ability to swap Ctrl and CapsLock.

You can just use linux and have both sound AND ergonomic input method. The swap thing is done in system settings on plasma, nothing magic.

Debian to vote on its firmware path

pabs — Sun, 04 Sep 2022 00:13:57 +0000

Woops, didn't mean to imply the firmware was freed, just that making the firmware available in a way that nouveau can use it too is welcome.

Debian to vote on its firmware path

pabs — Sun, 04 Sep 2022 00:12:28 +0000

The freeing of the Linux kernel driver (and the common firmware) was welcome indeed, but there is still the matter of the userspace portion of the driver, I haven't seen any indication nvidia plan to open that up. Hopefully nouveau folks can do reverse engineering but they will likely always be playing catch-up as nvidia release new GPUs and drivers.

Debian to vote on its firmware path

pabs — Sun, 04 Sep 2022 00:08:48 +0000

The only way Linux distros are involved is that if they package fwupd, then their users can easily install ME updates provided by their hardware vendor on the Linux Vendor Firmware Service.

https://fwupd.org/

Debian to vote on its firmware path

bluca — Sat, 03 Sep 2022 19:32:46 +0000

Talking about drivers here, not firmware

Debian to vote on its firmware path

cortana — Sat, 03 Sep 2022 16:22:05 +0000

Maybe they mean when ca-certificates is upgraded--ISTR being asked which newly-added authorities I wanted to enable one by one, as if I have any idea!

Debian to vote on its firmware path

cortana — Sat, 03 Sep 2022 16:12:05 +0000

Is that the Linux distribution's concern? They aren't shipping it are they?

(Don't tell me it's small enough to be included in the intel-microcode package!?!?)

Debian to vote on its firmware path

mpr22 — Sat, 03 Sep 2022 11:35:22 +0000

It does, under a general-purpose worldview.

However, the FSF's particular stance is, as I understand it:

1. If the firmware cannot be replaced without making physical changes to the hardware (e.g. pulling the mask ROM and fitting a new one, or soldering patch wires to the board to reconnect the programming voltage connection for the EEPROM), then it is part of the hardware, and thus outside their wheelhouse.

2. If the firmware can be replaced by software means (e.g. it's in an EEPROM and the programming voltage is permanently available or software-controlled), then it is software, and thus inside their wheelhouse.