@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 http://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 @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.
@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)