Conversation

Notices

1. Embed this notice
   Sergey Bugaev (bugaevc@floss.social)'s status on Thursday, 28-Mar-2024 14:54:18 JST Sergey Bugaev

   Is Linux secure?

   Let me rephrase, is a huge pile of C code, running in privileged mode in a shared address space, highly concurrent, using its own homegrown memory model based on volatile instead of the one the language spec defines and the compilers implement, dealing with untrusted data, implementing many complex protocols, data formats, & functionality, managing a bunch of "objects" with complex ownership and lifetime semantics, embedding its own JIT — secure?

   • Embed this notice
     Sergey Bugaev (bugaevc@floss.social)'s status on Thursday, 28-Mar-2024 14:54:17 JST Sergey Bugaev

     in reply to

     Clarification: I'm not advocating for alternative kernels (certainly not for Mach / Hurd, which are a lot more insecure — I would know 🙂)

     I'm saying, Linux is here to stay for decades and centuries. Look at what corner we've painted ourselves into.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Thursday, 28-Mar-2024 15:52:29 JST 翠星石

     in reply to
     @bugaevc >Is Linux secure?
     No, as it contains proprietary malware and has drivers that automatically load up malware cleverly disguised as peripheral software.
     
     GNU Linux-libre is decently secure mind you.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Saturday, 30-Mar-2024 12:52:29 JST 翠星石

     in reply to

     • wizzwizz4
     @wizzwizz4 >proprietary software >your CPU (with its proprietary firmware and proprietary logic circuitry) is malicious
     My CPU is all hardware, as circuitry is hardware and the microcode in ROM is hardware.
     
     Malicious circuits are rare due to the physical evidence created.
     
     As far as I can tell, the proprietary software intel previously provided for my CPU and motherboard is malicious, but I don't run that.
     
     Firmware is microprocessor instructions in an external ROM chip that can be trivially cut out and replaced - if it can be updated with software, it's software, otherwise it's hardware, aside from one corner firm case, where replacing the instructions consists of trivial soldering.
   • Embed this notice
     wizzwizz4 (wizzwizz4@fosstodon.org)'s status on Saturday, 30-Mar-2024 12:52:30 JST wizzwizz4

     in reply to

     • 翠星石

     @Suiseiseki Depends on your threat model. You're talking about the operating system, but @bugaevc's points all apply to Linux-libre's kernel.

     Proprietary userland tends to be malware, but proprietary OEM software tends to just be buggy and unauditable. If you consider proprietary software to be inherently malicious, then your CPU (with its proprietary firmware and proprietary logic circuitry) is malicious and GNU Linux-libre is insecure.

   • Embed this notice
     wizzwizz4 (wizzwizz4@fosstodon.org)'s status on Saturday, 30-Mar-2024 13:46:28 JST wizzwizz4

     in reply to

     • 翠星石

     @Suiseiseki Oh, hey, someone's already written the rest of this rant. https://libreboot.org/news/policy.html

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Saturday, 30-Mar-2024 13:46:28 JST 翠星石

     in reply to

     • wizzwizz4
     @wizzwizz4 >all unencrypted software gives you freedom 1 because you can look at the binaries
     Merely because you can reverse engineer the binaries doesn't give you freedom 1, as studying how the program works is much harder without the source code and changing it in nontrivial ways (to do your computing as you wish) is impractical without the source code.
     
     As a result, you don't have any of the 4 essential freedom.
     
     >Indeed, it's much easier to look at the binaries of most proprietary software than to read the ROM from a CPU's die
     I would argue that it's usually easier to send the CPU off to a decapping enjoyer and then to read out the unencrypted microcode, than to work out how to decrypt software that you don't have the encryption key for.
     
     >Goldmont / Goldmont Plus chips, it's easier to decrypt and disassemble the microcode updates than to get at the actual ROM microcode.
     Yes, for those specific processors, microcode updates are easier to analyze than the ROM version, but that's a
     
     >RYF's secondary embedded processor exception should apply to a GPCPU's microcode as well.
     GCPU's don't run microcode - they run proprietary peripheral software and they're a primary processor.
     
     The exception is designed to be temporary and it being expanded and made effectively permanent would be a ruinous compromise.
     
     >someone's already written the rest of this rant
     I'm not very impressed by that rant, as it calls for the increased installing and running of proprietary software, even when the device is functional without it (writing this now on a thinkpad without any of those proprietary microcode updates).
   • Embed this notice
     wizzwizz4 (wizzwizz4@fosstodon.org)'s status on Saturday, 30-Mar-2024 13:46:29 JST wizzwizz4

     in reply to

     • 翠星石

     @Suiseiseki By "you can look at the circuitry" logic, all unencrypted software gives you freedom 1 because you can look at the binaries. Indeed, it's much easier to look at the binaries of most proprietary software than to read the ROM from a CPU's die – and for Goldmont / Goldmont Plus chips, it's easier to decrypt and disassemble the microcode updates than to get at the actual ROM microcode.

     RYF's secondary embedded processor exception should apply to a GPCPU's microcode as well.

   • Embed this notice
     wizzwizz4 (wizzwizz4@fosstodon.org)'s status on Saturday, 30-Mar-2024 13:46:30 JST wizzwizz4

     in reply to

     • 翠星石

     @Suiseiseki Yeah, that's Richard Stallman's version of the software / not-software distinction, and while it's the only way to be a free software zealot while still using commodity hardware, it's not useful.

     Nobody has reverse-engineered a modern x86 chip from looking at the circuitry. All the high-level behaviour of an x86 chip is controlled by microcode: the CPU comes with microcode written by Intel, and there are precious few threat models where it makes sense not to use microcode updates.

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Saturday, 30-Mar-2024 13:56:43 JST 翠星石

     in reply to

     • wizzwizz4
     @wizzwizz4 Modern chips are AMD64, although they implement an x86 mode.
     >there are precious few threat models where it makes sense not to use microcode updates.
     - You don't need microcode updates if you don't run proprietary malware on your computer; https://www.fsfla.org/ikiwiki/blogs/lxo/pub/who-is-afraid-of-spectre-and-meltdown.en.html
     - Microcode updates so far don't actually fix all of the discovered exploits (intel hasn't released updates to fix speculative execution issues for core 2, just stability improvements (+ something else) years ago) - meaning you're still potentially screwed if you run proprietary software on your computer, unless you run out and buy new hardware every 6 months.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Monday, 01-Apr-2024 10:23:45 JST 翠星石

     in reply to

     • Dushman
     @dushman Please take meds.
     
     Just because you say hardware in ROM (that CANNOT be changed) is software over and over again doesn't make it the truth.
     
     I don't use modern x86 machines, I use AMD64 ones.
   • Embed this notice
     Dushman (dushman@den.raccoon.quest)'s status on Monday, 01-Apr-2024 10:23:46 JST Dushman

     in reply to

     • 翠星石
     • wizzwizz4

     @wizzwizz4@fosstodon.org @Suiseiseki@freesoftwareextremist.com
     It's just a weird cope created by GNU so people can say they run 100% free software, even when they in fact do not. Whether or not you update your microcode you will be running fully proprietary software. This changes nothing in regards to your freedom. If you think all proprietary software is bad and shouldn't be used at all then do not use any modern x86 machine lol.

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Monday, 01-Apr-2024 11:11:20 JST 翠星石

     in reply to

     • Dushman
     @dushman >Does the same thing as updated microcode
     It doesn't, but if I was intel, I would shy away from putting malicious circuits in ROM, as some decapping enjoyer would find out in 10-20 years and instead put the malware in the microcode updates, as those are in an undocumented instruction set that's heavily obfuscated and encrypted too and chances are no-one will ever find out or even if they do, good luck to them putting the evidence in a form admissible in court.
     
     >If you burned windows into ROM would that make it cool and freedom respecting
     That would make it no longer software but it wouldn't be freedom respecting as that would be a malicious circuit, due to all the malware in windows.
   • Embed this notice
     Dushman (dushman@den.raccoon.quest)'s status on Monday, 01-Apr-2024 11:11:21 JST Dushman

     in reply to

     • 翠星石

     @Suiseiseki@freesoftwareextremist.com
     If you burned windows into ROM would that make it cool and freedom respecting?

   • Embed this notice
     Dushman (dushman@den.raccoon.quest)'s status on Monday, 01-Apr-2024 11:11:22 JST Dushman

     in reply to

     • 翠星石

     @Suiseiseki@freesoftwareextremist.com
     Does the same thing as updated microcode. No one has reverse engineered the rom chips on modern CPUs, so no one knows exactly what the burned in instructions do.