121–130 of 205 posts
Attending an RMS talk at a university ~8 years ago, some (increasingly irritated) lecturers questioned him on the use of proprietary graphics drivers in image processing for use in medical equipment and research. While RMS argued his absolute stance that proprietary drivers are never permissible, the lecturers argued that the drivers were literally saving lives and people would die without them. "They should die for…
I'm well out of my realm of expertise here, but I had a gut reaction to: > Libreboot, being FSF-recommended, also has this policy of disallowing firmware blobs in the source tree, despite it being a source of nothing but problems. Later the author points out how there isn't any contemporary libre hardware that would satisfy users (vaguely but reasonably described), and so "free" solutions utilize loopholes in the leg…
There is a very short list of hardware they do endorse here. I’m not sure if it uses those loopholes or not https://ryf.fsf.org/
Earlier quoted context omitted.
There is a very short list of hardware they do endorse here. I’m not sure if it uses those loopholes or not https://ryf.fsf.org/
What's funny about this list is how much of it amounts to a few companies -- ThinkPenguin, Libiquity, and Technoethical -- rebranding commodity hardware like Atheros wireless cards. There's nothing unique about this hardware which makes it more "free" than any other off-the-shelf Atheros cards, and the drivers were open-source long before any of these companies got involved.
https://www.reddit.com/r/libreboot/comments/pqs0g0/technoeth...
https://www.reddit.com/r/linux/comments/4hy9hf/ordered_a_lib...
Attending an RMS talk at a university ~8 years ago, some (increasingly irritated) lecturers questioned him on the use of proprietary graphics drivers in image processing for use in medical equipment and research. While RMS argued his absolute stance that proprietary drivers are never permissible, the lecturers argued that the drivers were literally saving lives and people would die without them. "They should die for…
I get what you’re saying, but this form of argument sort of talks past the stance of the RMS’s of the world. The fact that the software being used is proprietary is a historical accident and not an attribute of the software that makes it function a certain way—it’s entirely possible to write non-proprietary life saving software. RMS is arguing for principles and ideals. Sure when it comes down to it, it’s absurd to s…
He has no idea how to be persuasive, no idea how to adjust his arguments or present his ideas effectively, no idea how he comes off to others, no idea how to read a room, no idea how to see other people's perspectives on issues, and doesn't care to try. He hasn't demonstrated the slightest intellectual or emotional self-improvement in thirty years.
Attending an RMS talk at a university ~8 years ago, some (increasingly irritated) lecturers questioned him on the use of proprietary graphics drivers in image processing for use in medical equipment and research. While RMS argued his absolute stance that proprietary drivers are never permissible, the lecturers argued that the drivers were literally saving lives and people would die without them. "They should die for…
Earlier quoted context omitted.
... but you can modify the base version. That's how microcode updates work, they patch it (via a patch register CAM). Are you trying to argue that the physical mechanism used for patching matters? That's an implementation detail, it has nothing to do with freedom. Your CPU comes with patchable proprietary software. Period.
> ... but you can modify the base version. There is some read-only memory that contains the base version. It is executed on boot. You can tell the cpu to run a different version by pointing it to a different version during the boot process (or later). You can't change the version in the read-only memory.
The way it works is that the microcode update gets loaded into some (smaller) RAM next to the ROM, and then patch registers are loaded which virtually rewrite some ROM locations to jump to the RAM (at least for the duration of this boot), in order to update the broken bits.
You are literally hot-patching the ROM with an overlay. You are not replacing it wholesale.
And either way, as I said, the underlying technical mechanism is completely irrelevant for the purposes of assessing user freedom. You're running proprietary code. You could be running a less buggy version of the same proprietary code. Choosing not to is silly and only hurts you. Trying to take that option away from users of your software is anti-freedom.
Earlier quoted context omitted.
... but you can modify the base version. That's how microcode updates work, they patch it (via a patch register CAM). Are you trying to argue that the physical mechanism used for patching matters? That's an implementation detail, it has nothing to do with freedom. Your CPU comes with patchable proprietary software. Period.
> ... but you can modify the base version. There is some read-only memory that contains the base version. It is executed on boot. You can tell the cpu to run a different version by pointing it to a different version during the boot process (or later). You can't change the version in the read-only memory.
If the answer is "because then nothing could be certified or recommended" (which I expect it would be) then you need to stop marketing the certification as a recommendation for actual people to buy hardware and instead market it as a certification of whether the product is in line with their ideals.
Earlier quoted context omitted.
If you try to pin down someone on the fly who is publicly advocating for something on what exceptions are ok, expect them to be stubborn. But there is a lot of pragmatism at work. It's why we have the LGPL, GPL, and AGPL. https://www.gnu.org/philosophy/pragmatic.en.html
Ah yes, the AGPL. The license that wants to be an EULA (because that's the only way you can actually close the SaaS loophole), but can't, because being an EULA would be against the FSF's core values (Freeedom Zero), so instead it's a cute hack that is trivial to work around if you want to, while simultaneously being almost impossible to comply with for regular developers. And then the FSF plays it like it has EULA po…
Attending an RMS talk at a university ~8 years ago, some (increasingly irritated) lecturers questioned him on the use of proprietary graphics drivers in image processing for use in medical equipment and research. While RMS argued his absolute stance that proprietary drivers are never permissible, the lecturers argued that the drivers were literally saving lives and people would die without them. "They should die for…
Earlier quoted context omitted.
That "libre" gives you auditability is a common myth believed by those pushing for libre hardware. The reality is you can't audit silicon, because it's a destructive process requiring extremely expensive analysis equipment. You always have to trust the chip manufacturer; doesn't matter how documented the chip design is, even if the masks are outright public. You can never know that your CPU is not backdoored. That's…
> There is one exception: FPGAs, under the premise that "generically" backdooring an FPGA is computationally infeasible. IMO, this isn't a reasonable premise. - The entire boundary scan chain is a backdoor. You could have an embedded processor poking around looking for things that look like RISC-V code and adding implants or observe state. - You could make SERDESes do various kinds of naughty things when certain patt…
The point is that is not feasible when the design layout is randomized. Reverse engineering FPGA bitstreams is a notoriously hard problem. You might detect your synthesis of RISC-V but there is no algorithm that can detect any RISC-V, and definitely no algorithm that can do that in a tiny low power embedded processor that can pass by unnoticed.
> You could make SERDESes do various kinds of naughty things when certain patterns go by-- dump some scan chain info, so you can kick some special packets and read out state remotely.
Yes, backdooring I/O is still possible. But it significantly raises the bar for the backdoor, since now you're relying on significant back and forth to probe deeper into the system. This isn't an absolute defense, it's just better than hard silicon because you can make backdooring the core logic impractical, especially self-contained.
> You could make naughty patterns of bits crossing places do bad stuff. Think of dynamic effects like rowhammer being deliberately included, so if you know the design you can figure out what outside data will trigger bits to flip and state to leak. (Yes, I know that block rams are SRAMs, but that doesn't mean you can't deliberately add capacitive coupling or screw up synchronizers in various ways. And it looks like we may have block NVRAMs soon, so that opens the possibility for various evil even more).
With design randomization, you can make it hard to detect patterns like that. Think things like randomizing the polarity of each bit line going in/out of RAM. Again, the point is the backdoor has to work with any design, and this opens up a wide range of mitigations that you can implement at that stage, that make it a lot less practical.
Keep in mind I'm bringing this up in the context of people believing that some ThinkPad the FSF rubber-stamped respects your freedom (and security) when it contains microcontrollers hooked up to LPC running secret blobs. Yes, if we want to go deeper down the rabbit hole of hardware trustability, there is definitely more to be done after Precursor, but it's a particularly clever example of how to at least attempt to begin to solve the silicon trust problem.