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

311–318 of 318 posts

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

#311

Post by nix23 »

marcan_42 wrote: post #302
nix23 wrote: post #294

Earlier quoted context omitted.

>>since you cannot check the silicon... READ. The microcode is opensource..

The silicon - the rest of the logic that makes the CPU - isn't. There's more to CPUs than microcode. Besides, how can you audit that the open source microcode is what the manufacturer actually put into the CPU? Microcode is usually ROM-based with only runtime patches. Open source microcode does not change the fact that you need to trust the CPU manufacturer not to backdoor your CPU. There is literally no way around t…

I understand that you have problems reading so i repeat it for you the third time:

>>>since you cannot check the silicon...

And since you have problems using google too:

https://www.sbir.gov/node/1620879

>>A small business has already shown that a completely open source solution (to include CPU firmware, CPU Microcode, Baseboard Management Controller (BMC), BIOS boot code, power management, etc.) based on a high performance CPU is possible.

Imagine who that "small business" is?

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

#312

Post by r283492 »

marcan_42 wrote: post #309
r283492 wrote: post #307

Earlier quoted context omitted.

> only they can theoretically (though as I said, in practice detectably) backdoor your laptop No, no no. This is wrong. You don't need a nested hypervisor to make an undetectable backdoor. If you you audit all network traffic from a separate device, most backdoors are detectable, because a backdoor wants to have some effect that goes outside your system and that is the obvious route. But there are a hundred ways to c…

> No, no no. This is wrong Look, I'm not a fan of pulling on credentials, but I've literally spent the past year reverse engineering these devices. If you're going to tell me I'm wrong about my security analysis, I hope you've done your own. > But there are a hundred ways to create a backdoor which is very hard to detect and of course the proprietary bootloader Mac bootloader is a perfectly good vector for them. Not…

> Not when you can literally flash these devices from scratch (DFU mode) using a public OS image from Apple. That guarantees any preinstalled backdoors go away, since it's a complete wipe (you can do this from a Linux machine, by the way - I just added support for the latest M1 devices and OS to idevicerestore a few days ago). All the runtime components that remain booted while the OS runs are not encrypted, and thus Apple can't hide a secret backdoor in them.

You're saying that a backdoor can't be secret if it is in an unencrypted binary. That sounds wrong to me. Are you going to decompile and audit the entire OS to find a backdoor, I don't think so.

> I have a perfectly working installer that pulls the firmware updates from Apple's CDN and builds an OS container without installing macOS. You do need macOS for self-hosted system-level firmware updates, but only because we haven't built a process for Linux to invoke that updater yet.

Well, that is nice.

> You could just not apply the updates, and you'd be no worse off than with the non-updatable chip. The updatability gives you choice. It doesn't take anything away, certainly not any more of your freedom.

You "could". In practice, software vendors relies on the updates to abuse their users. For example intel microcode updates have a license that says: you agree not to reverse engineer it. Security updates for printers come with functionality to stop working with third party ink. Oh, you are a sophisticated user and handle it all. Fine. And of course, FSF certainly encourages reverse engineering: if you want to buy something for the purpose of reverse engineering, FSF does endorse that. For everyone else, think it's a perfectly fine position to simply say, we don't endorse opening yourself up to an abusive relationship.

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

#313

Post by r283492 »

marcan_42 wrote: post #297
medo-bear wrote: post #296

Earlier quoted context omitted.

>Every single die-hard FSF fanboy needs to learn about the 27 blobs running in little ROMs inside their computer, so they stop believing they live in a fake freedom utopia and come to terms with the reality we live in. Maybe then we'll have even more people pushing for firmware freedom who believes this? why are you constantly being insulting? a lot of linux fanboys think that if you run linux you can't get hacked. d…

https://ryf.fsf.org/products/TET-BT4 No mention of the half megabyte of proprietary Bluetooth stack firmware (with significant security and privacy implications) that's in that dongle which supposedly "Respects Your Freedom". https://ryf.fsf.org/products/VikingsX200 No mention of: * Proprietary CPU microcode ROM (full access to CPU/memory, security critical) * Proprietary embedded controller firmware (H8S, connected…

And if free software existed for any of those chips, FSF would require it. If there is any room for consistency in the criteria, it would be to deal with the fact that some of the computers have less nonfree firmware than others. Eg: the raptor computer has far less than the x200.

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

#314

Post by marcan_42 »

nix23 wrote: post #311
marcan_42 wrote: post #302

Earlier quoted context omitted.

The silicon - the rest of the logic that makes the CPU - isn't. There's more to CPUs than microcode. Besides, how can you audit that the open source microcode is what the manufacturer actually put into the CPU? Microcode is usually ROM-based with only runtime patches. Open source microcode does not change the fact that you need to trust the CPU manufacturer not to backdoor your CPU. There is literally no way around t…

I understand that you have problems reading so i repeat it for you the third time: >>>since you cannot check the silicon... And since you have problems using google too: https://www.sbir.gov/node/1620879 >>A small business has already shown that a completely open source solution (to include CPU firmware, CPU Microcode, Baseboard Management Controller (BMC), BIOS boot code, power management, etc.) based on a high perf…

Where's the link to the source?

FYI, IBM loves to use the term "microcode" to include side CPU firmware and such. This is different from Intel "microcode" which strictly refers to the instruction dispatch part. Is the instruction dispatch microcode in POWER9 open source or not?

None of these are it: https://wiki.raptorcs.com/wiki/OpenPOWER_Firmware

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

#315

Post by nix23 »

marcan_42 wrote: post #314
nix23 wrote: post #311

Earlier quoted context omitted.

I understand that you have problems reading so i repeat it for you the third time: >>>since you cannot check the silicon... And since you have problems using google too: https://www.sbir.gov/node/1620879 >>A small business has already shown that a completely open source solution (to include CPU firmware, CPU Microcode, Baseboard Management Controller (BMC), BIOS boot code, power management, etc.) based on a high perf…

Where's the link to the source? FYI, IBM loves to use the term "microcode" to include side CPU firmware and such. This is different from Intel "microcode" which strictly refers to the instruction dispatch part. Is the instruction dispatch microcode in POWER9 open source or not? None of these are it: https://wiki.raptorcs.com/wiki/OpenPOWER_Firmware

https://git.raptorcs.com/git/

>>CPU Internal Firmware

>>CPU External Firmware

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

#316

Post by marcan_42 »

nix23 wrote: post #315
marcan_42 wrote: post #314

Earlier quoted context omitted.

Where's the link to the source? FYI, IBM loves to use the term "microcode" to include side CPU firmware and such. This is different from Intel "microcode" which strictly refers to the instruction dispatch part. Is the instruction dispatch microcode in POWER9 open source or not? None of these are it: https://wiki.raptorcs.com/wiki/OpenPOWER_Firmware

https://git.raptorcs.com/git/ >>CPU Internal Firmware >>CPU External Firmware

SBE, OCC, HCODE. Those are from the list I linked. None of them are the instruction dispatch microcode.

Maybe it's time for you to have the realization that POWER9 has proprietary microcode just like Intel. At least it seems they probably have less of it, and they do vaguely document it in the CPU manual (they have micro-op classes and counts) but it's there, and I don't see any real source code anywhere. They also have patch registers, so you can't even say it's not updatable. The POWER9 manual mentions six Instruction Mask Registers per core, but these registers are documented nowhere (I just spent a good 30 minutes digging through the giant register documentation PDFs and HCODE source, but I couldn't find anything).

Is this better than Intel? Yes. Is it "fully free"? No. Nothing's fully free. Which is why we need nuanced analysis, not the nonsense arbitrary lines the FSF draws in the sand.

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

#317

Post by geokon »

Gentil wrote: post #33
geokon wrote: post #20

Is there a reason neither Guix nor Nix have made an LTS-type repo? A rolling release seems at odds with the stability granted by reproducible builds. Maybe I have a miopic view, but what's nice with Ubuntu LTS is you know everyone and their mothers has built and tested their packages/libraries/executable against the lib versions provided by Ubuntu 18.04 or 20.04 or whatever. You also know those libs, at their given v…

Good points made by others. But another thing is you don't have to? Nix(OS)/Guix installs packages and dependencies separately instead of replacing packages like other OS/package managers do. This means you have multiple versions of a package installed in your system and that you can use them simultaneously for different applications if I understand it right. You can move back and forth between versions if one breaks…

Right, you can fix your versions if you care, but you don't have a million keyboards "tuning" a fixed version set to be play well with each other - so you don't get the same robustness

I know I can get any software to run on Ubuntu 18.04. Everyone supports those packages as their specific versions

Having multiple versions or the same package sounds like a disaster. That's the diamond problem. LibA depends on LibB and LibC. Those both depend on LibD at different versions... What then?

These rolling distros generally target one arch and one kernel bc the whole thing is fragile. Things like OpenSSL have bugs even between minor versions numbers once you start looking bigger

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

#318

Post by alexvoda »

medo-bear wrote: post #292
marcan_42 wrote: post #290

Earlier quoted context omitted.

They are literally endorsing Bluetooth dongles with half a megabyte of proprietary ROM as "respecting your freedom". That goes a little beyond "tolerating", don't you think?

'Respects Your Freedom' is a (trademarked?) label that comes with clear and readily available certification rules. according to FSF, these are products that are simply the best options available as far as FSF's free-software ethics are concerned. in this sense it is simmilar to 'fair trade' labels you find on products. since you guys love extreme examples, i could ask you if when you use an Apple computer do you expe…

I will answer your last question. Apple absolutely does not respect your freedom. They infringe on your freedom. Depending on the definition of ethical, they are vastly less ethical than the FSF.

But they also never claimed to be ethical. They never claimed to guard a moral ideal. They have claimed many things (protect privacy of users, guarantee security of users) which they did not act upon, and they have received flack for that. But they didn't claim to be ethical. Not even in a aspirational way like Googles "Don't be evil" moto.

The FSF, however, claims that ethics is it's prime driver. And by endorsing hardware with proprietary blobs (placed on chip flash instead of system storage) they display hypocrisy. They choose the very pragmatism they criticise others for choosing.

And that is something religions do aswell.

I have asked you why is the line there and you have not answered.

Post reply on HN