Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Love Arch, but GNU Guix Is My New Distro

boilingsteam.com

Post reply on HN
Print view View original

251–260 of 318 posts

Re: I Love Arch, but GNU Guix Is My New Distro

#251

Post by marcan_42 »

mindslight wrote: post #155
marcan_42 wrote: post #27

> Guix System is an advanced distribution of the GNU operating system. It uses the Linux-libre kernel It's worth pointing out that the linux-libre kernel is developed under the FSF doctrine that "binary blobs are bad unless you can't see them". This has been taken to its logical extreme here, where this Linux fork actively removes security warnings informing users that they need to update their CPU microcode , becaus…

It's not productive to call it "arbitrary religious dogma". The FSF chose a criteria for what binary blobs are acceptable. Your and my opinions are that they set this criteria wrong, but if we hope to change their policy, then we have to discuss it rationally. I personally think the correct criteria is that of security boundaries and change control. If I've got a graphics card with proprietary code (regardless of whe…

The problem is that they have long given up on rationality; they and their devoted followers are an echo chamber of "blobs bad", "my software freedom", etc. They've stopped listening to rational discussion :(

Re: I Love Arch, but GNU Guix Is My New Distro

#252

Post by marcan_42 »

medo-bear wrote: post #217
marcan_42 wrote: post #204

Earlier quoted context omitted.

Nobody is looking at Intel's microcode mask ROM. It's in ROM. You can't even look at it. Microcode is a bad example because the updates are encrypted too, but for the vast majority of the blobs that the FSF hates so much, at least you can look at them and audit them with a disassembler. Meanwhile, the devices with giant firmware ROMs that they openly endorse are not auditable, as you can't see the blob. This policy i…

so after so many posts this is the only one that expresses your point clearly. notice how it does not contain any FUD to the said point, this is definitely a VALID security concern. FSF needs to make these concerns clear. you seem to be very invested in this matter. have you raised these concerns with them? EDIT: having thought about it some more. doesnt isolating blobs to ROMs restrict the problems to ROMs? i mean n…

Lots of people have tried to raise concerns such as this one with them. They've stopped listening.

Re: I Love Arch, but GNU Guix Is My New Distro

#253

Post by marcan_42 »

marcodiego wrote: post #140
fsflover wrote: post #133

Earlier quoted context omitted.

I do not trust my CPU provider. Where do I find an alternative based exclusively on free software?

https://ryf.fsf.org/

Every single laptop in the RYF list includes proprietary unauditable microcode. So do many of the other products there, e.g. that Bluetooth dongle which probably has about half a megabyte of proprietary firmware.

Re: I Love Arch, but GNU Guix Is My New Distro

#254

Post by marcan_42 »

fsflover wrote: post #133
WastingMyTime89 wrote: post #126

Earlier quoted context omitted.

Non sense. I trust my CPU provider or I wouldn’t have bought this CPU. I would much rather use an updated microcode than one known to be insecure. I wouldn’t check the microcode anyway and I don’t really trust the people who might more than the company providing my CPU. Sure it might contain code making me vulnerable to a state actor but that’s not a threat profile I care about.

I do not trust my CPU provider. Where do I find an alternative based exclusively on free software?

If you do not trust your CPU provider, your only option is a design that assumes an adversarial manufacturer. The only credible design I've seen for this scenario is Precursor, which works because generic backdoors for FPGAs (i.e. those that work with arbitrary randomized designs) are arguably impractical, since you'd need a huge amount of compute power to attempt to analyze the design and figure out how to backdoor it. It's likely even an unsolvable problem in the general case.

https://www.crowdsupply.com/sutajio-kosagi/precursor

Of course, then you get a RISC-V running at 100MHz. If you want something faster, you need to trust your CPU provider. There's no way around that; silicon is not end-user introspectable.

Re: I Love Arch, but GNU Guix Is My New Distro

#255

Post by marcan_42 »

nix23 wrote: post #139
fsflover wrote: post #133

Earlier quoted context omitted.

I do not trust my CPU provider. Where do I find an alternative based exclusively on free software?

https://www.raptorcs.com/TALOSII/

There is no reason to trust IBM not to include a silicon backdoor in POWER9 more than Intel not to include a silicon or microcode backdoor in their x86 chips. TALOS is a lot freer than most designs, but you still need to trust every manufacturer whose silicon went into that motherboard.

Re: I Love Arch, but GNU Guix Is My New Distro

#256

Post by marcan_42 »

medo-bear wrote: post #136
WastingMyTime89 wrote: post #126

Earlier quoted context omitted.

Non sense. I trust my CPU provider or I wouldn’t have bought this CPU. I would much rather use an updated microcode than one known to be insecure. I wouldn’t check the microcode anyway and I don’t really trust the people who might more than the company providing my CPU. Sure it might contain code making me vulnerable to a state actor but that’s not a threat profile I care about.

why is it nonsense? i think not trusting vendors that dont let you verify their product is quite sensible. note this is not paranoia to think that they are doing something malicious. its just as simple as dont trust strangers

There is no way to verify silicon. This applies to every single chip. If you are using off the shelf hard cores in silicon, you need to trust the vendor. That's just how it is. It's not practical for end users to take silicon chips into a SEM, delayer them, and verify that the design is what they expect. Verifiability aside, there aren't even any high performance CPUs with fully open RTL/netlists available.

Re: I Love Arch, but GNU Guix Is My New Distro

#257

Post by LargoLasskhyfv »

marcan_42 wrote: post #79
medo-bear wrote: post #75

Earlier quoted context omitted.

i just looked through this website and found a link to their certification process at https://ryf.fsf.org/about/criteria it states: > However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, mic…

The existence of that exception, the way it is implemented, the way they work with vendors to help them fit into it, and the way they do not require informing users of such secondary processors are all deceptive. Just look at the Librem 5. That CPU needs a blob to even boot (to train the RAM). Normally that would just be embedded into the bootloader. But that would make it evident in the build process for their boot…

Or have a proprietary RTOS running on a GPU, working hypervisor-like for the tacked on ARM-multicore, like some very popular fruity berry SBCs.

(giggle)

Re: I Love Arch, but GNU Guix Is My New Distro

#258

Post by marcan_42 »

kdtsh wrote: post #243
marcan_42 wrote: post #27

> Guix System is an advanced distribution of the GNU operating system. It uses the Linux-libre kernel It's worth pointing out that the linux-libre kernel is developed under the FSF doctrine that "binary blobs are bad unless you can't see them". This has been taken to its logical extreme here, where this Linux fork actively removes security warnings informing users that they need to update their CPU microcode , becaus…

This is an enormous thread now - in case it hasn’t already been mentioned, Guix neither helps nor hinders users from using any kernel they like. There is a repository called nonguix, made available by community members, which includes the upstream, non-free kernel, as well as microcode updates for Intel processors. The Guix project states clearly that it does not support these uses of the software, but that users are…

The problem is the endorsement of linux-libre, which goes beyond deblobbing into actively censoring messages.

I'm sure Guix allows users to choose (it has to, thanks to Freedom 0, as you say), but by choosing a kernel by default that chooses to withhold information from its users, it is encouraging decreasing user knowledge. That is something that people should be aware of, and honestly, something that should be considered a bug to fix. We can't allow the proliferation of schools of thought that promote not educating users about their options, justified by ideology.

For what it's worth, disabling microcode updates in other distros is just uninstalling a package (or not installing it in the first place; my distro of choice, Gentoo, does not install it by default).

Re: I Love Arch, but GNU Guix Is My New Distro

#259

Post by marcan_42 »

anthk wrote: post #135
raverbashing wrote: post #103

Earlier quoted context omitted.

Yeah. Then these geniuses get bitten by Spectre/Meltdown because they were too scared of running the microcode update. For real. I agree, if that's the position of Guix, I don't want it in my machine.

Sorry, but you are wrong. GNU people won't run nonfree JS at all. LibreJS is a good example in order to kill any potential Spectre/Meltdown attack. There is no attack when no code is being run.

> There is no attack when no code is being run.

https://9to5mac.com/2021/03/11/browser-based-attack-affects-...

Turns out you don't need Turing completeness to perform microarchitectural side channel attacks. This is yet another way in which the "all my software is free, therefore I am safe from attacks" fallacy breaks down.

Nevermind that, as pointed out by other replies, LibreJS provides zero security. It relies on scripts voluntarily declaring that they're freely licensed, and if they do, they're allowed to run. The extension doesn't care whether the script is malicious or not.

Re: I Love Arch, but GNU Guix Is My New Distro

#260

Post by marcan_42 »

pxc wrote: post #218
seoaeu wrote: post #198

Earlier quoted context omitted.

I'm sorry, but this (and a bunch of other similar blocks) seem pretty intentional... # Do no recommend non-Free microcode update. announce X86_LOCAL_APIC - Undocumented clean_blob arch/x86/kernel/apic/apic.c clean_kconfig arch/x86/Kconfig X86_LOCAL_APIC clean_mk CONFIG_X86_LOCAL_APIC arch/x86/kernel/apic/Makefile

If the kernel can't load it without code changes and recompilation, due to the de-blobbing process, it doesn't make much sense to recommend to users that they load it.

You can often also update your microcode by updating your BIOS/firmware.
Post reply on HN