Would you buy/use a computer that ran 3x slower than modern machines if it were more secure (less vulnerable to side-channel attacks)?

@lxoliva had some compelling words about this at LP2019:


I don't know if your comment related at all to Spectre, but---if all the software running on your system is free software, what is there to fear? And I agree.

The biggest trouble is that people often run non-free and untrusted code all of the time in their web browsers, and don't see it as a software freedom or security issue. It's important to recognize it for what it is---untrusted, unsigned, ephemeral software---if you're going to consider security tradeoffs when it comes to certain mitigations. I personally don't run JS at all, even if it's free, with very few exceptions, because it's unsigned.

@mikegerwitz @lxoliva I'm glad you ack'ed the "not signed" aspect; regarding the nonfree vs free software: mark the metadata of javascript as librejs compatible, then perform a read or write attack against the system. (Heck, it even *could* be free software compliant; most likely the target isn't checking the licensing situation when they're under such attack, but it's also trivial to lie about it.)


@mikegerwitz @lxoliva However, we shouldn't believe that just because something is free software that it is trustworthy, or that we have the capacity to fully audit our software systems for security. The sad reality is that people run way too much code to be able to trust or audit systems, and Ka-Ping Yee's thesis showed that if an attacker wants to add vulnerabilities to (even free) software, even the best programmers won't detect it zesty.ca/pubs/yee-phd.pdf

@mikegerwitz @lxoliva At any rate, defense in depth. Free software helps, but we shouldn't be saying "well, we're not going to be bother with these other (critical) layers because we're just focusing on this one layer."

Also as someone who wants to build a decentralized, free software powered distributed game where you can safely run other peoples' game code, heck yeah I want to be sure that it doesn't open my system to attacks.

@mikegerwitz @cwebber it's not just about being free software, you have to actually know that it does what you wish, which requires auditing by a trusted party. truth is we've long known about side-channel attacks that allow information leaks. s&m aren't the first nor the last of these, and some are deemed unfixable, so if you wish to run untrusted code on your system, you'd better not have information you wish to keep private on it
@cwebber @lxoliva Certainly we need to trust it as well. But if you're installing software on your system, there are generally other, more effective ways to compromise the user than resorting to side-channels.

But ensuring your software is signed and reproducible also helps to mitigate targeted attacks---if you're running the same software that everyone else is running, then the risk is very high for someone to do something malicious and tarnish their reputation.

Many users just `curl foo | sudo sh` the latest hot thing as they're instructed.

@mikegerwitz @lxoliva I don't think we're disagreeing there. I'm just arguing for a *multi-pronged approach*, and from there I don't understand where the objections are coming from. I have a hard time believing that if we had a community-oriented libre-hardware-design RISC-V machine that was less vulnerable than these side channel attacks that the bunch of us wouldn't advocate that people should use that *and* free software.

@cwebber Oh, I would certainly advocate for libre hardware. What I was replying to was your original message:

> Would you buy/use a computer that ran 3x slower than modern machines if it were more secure (less vulnerable to side-channel attacks)?

I interpreted this as buying a modern e.g. Intel processor that has Meltdown/Spectre microcode mitigations, which can cut performance of certain processes by half (which we have to deal with at work).

But RISC-V is another story. We actually gain something substantial there.

@mikegerwitz I wasn't talking about the microcode updates specifically, but I think they're also a good example if you put the non-freeneess aside of the question as I posed it. But for context, what prompted this conversation was a chat on Friam (meeting of some programming language nerds that happens once a week) where Meltdown/Spectre were discussed, and more fundamental cpu architectural changes were proposed (as well as changing some ways we program, because it's Friam)

@cwebber Ah, well, to actually answer your question:

- I generally prefer to mitigate issues, even if that means inconvenience or lack of performance. I put a great deal of time into making life intentionally difficult for myself, for many different things, in the name of security.

- In certain circumstances, I may choose not to adopt that practice depending on my threat model and the tradeoffs.

- For people who aren't able to understand the risks and tradeoffs thoroughly, I'd recommend that they go with less performant systems in favor of mitigations.

- BUT, in the context of Intel, their microcode updates are non-free, and so I won't install them, and I won't recommend that people install them. But I will warn them of the risks.

TBH this is the main thing making me wary of purchasing a Purism laptop---I really would like to eventually, but I'm having a lot of trouble justifying using an Intel processor (or most modern hardware, for that matter, that isn't libre) for any computing that I may consider sensitive. And a personal laptop inevitably falls under that category.

It's a shitty situation. But yes, I would consider purchasing a computer that's 3x slower for personal computing. If I'm doing something CPU or memory intensive like compilation, I usually offload to a separate box anyway, since that isn't usually sensitive.
Sign in to participate in the conversation

Octodon is a nice general purpose instance. more