[tpearson-raptor]

To the downvoters: I'm guessing you wanted to run Windows 10 "safely" somehow, or sandbox your games. There's almost no other reason to be this stuck on x86; at the end of the day it's just a consumer architecture that some well known privacy disrespecting software requires to run. It's not even that great of an architecture from a technical perspective, it just happens to have the financial weight of the prosumer market behind it right now.

Here's reality:

This laptop won't stop Windows exfiltrating your data. These x86 systems are leaky, they require sizeable amounts of low level binary firmware to even boot, and proper isolation is near impossible. Try sticking a PCIe diagnostic system on an open PCIe slot and sending commands to the WiFi or Ethernet card -- most likely it'll respond [1]. Then consider the firmware in the various controllers attached to the PCIe bus, including your GPU.

It's probably a violation of your game's anticheat system to try to sandbox it. It's definitely a violation of the NVIDIA driver EULA to run it in a virtual machine, unless you pay the enterprise driver license fees and use a server grade adapter. The kind of adapter you won't usually find in a laptop, by the way.

This is a topic that I find very frustrating. We all know you want to do the above. It can't be done without license violations all over the place, or head-in-sand make-believe "security", on modern x86 hardware. No wishing, hoping, etc. will make this change.

[1] Yes, this is known to happen on specific x86 systems that I have personally tried (in that case, it was a malfunctioning GPU writing to the disk controller!). Invalid cross-device access was also tried on a POWER box, where the invalid accesses were blocked and logged as intended.

[rvense]

I gave that comment a downvote because I thought it was disrespectful.

System76 have been providing practical solutions for running free software on available hardware for years now. That does indeed deserve kudos, even from you.

Keeping a kilowatt of computing power running at all times at home and connecting to it with a dumb ChromeOS terminal as you're suggesting is quite honestly not a viable solution for many people. And excluding practicalities (which a real person, of course, cannot) it might even be worse for security depending on your threat model.

[tpearson-raptor]

That may be. However, I was using Linux on bog-standard computers before System76 was even founded -- preinstalling Linux on a computer isn't exactly revolutionary, and it's in a completely different league from the work that has been required to bring up entire new CPUs (!) to compete with the increasingly locked x86 systems.

No idea where you're getting a kilowatt from. My desktop uses maybe 120W or so, with a lot of that going to the AMD GPU.

If we're going to trade barbs over ecological damage, what happens to all those Intel and AMD systems that would have been useable if they had just had updates to the locked/signed firmware, but are instead floating around in landfills because the vendor decided they wanted to enforce their control and not issue security updates?

[rvense]

> That may be. However, I was using Linux on bog-standard computers before System76 was even founded -- preinstalling Linux on a computer isn't exactly revolutionary

System76 is making free software computing more attractive and available. You might think of what they do as easier than what you do, and you might disagree with the way they prioritize security over other factors in their products, but I still think it's pretty bad of you to imply that what they're doing is not valuable to this community.

[tpearson-raptor]

OK, I think I may have been misunderstood...

What they are doing in that space is valuable. However, with just a bit more tweaking, they could offer something a whole lot more valuable in parallel, and leave this whole semi-open x86 issue behind. If they were to offer even a couple of actually open source firmware systems, and indicate somewhere in the marketing that the x86 boxes are only partly open source, that would not only eliminate the entire controversy here but also allow them to take the next logical step in open software. If their core mission has basically been to make open source easy to consume, that's a worthy goal; why not go a bit further and make open source on open hardware with fully open firmware just as easy to consume?

Clearly there's demand, from the comments in this thread alone!

[SmellyGeekBoy]

I'm a fan of what Raptor is trying to achieve but you perhaps need to go easy on the company Kool Aid. Hijacking another manufacturer's comment thread to push your own agenda is one thing, ranting and being disrespectful is quite another.

[tpearson-raptor]

I wouldn't be here if I didn't see a bunch of headlines yesterday that made it sound like these new laptops have proper open firmware.

They don't. That's why I'm here, to provide the missing other half of the story.

[madez]

Let me take this opportunity to ask you a question here after you making clear the problems you see.

Hardware becomes more complex and can include internal software that from a user perspective is just part of the hardware. But in fact, it is software running doing complex things outside of the oversight and control of the user.

Do you have plans to not just have open software but also open hardware? Do you hope to offer a device in the future with not just free software, but with the source files of the integrating hardware like the motherboard as well as of the chips like CPU and auxiliary ICs? Do you see a possibility to start with an open RSIC-V CPU?

[tpearson-raptor]

Actually, yes! We're closely monitoring the development progress of the open toolchains for various FPGAs; with POWER ISA now being open for implementation by anyone anywhere, I could easily see a future where extremely sensitive work is seamlessly moved from a large closed ASIC like the current IBM POWER chips to a completely software compatible, but significantly slower, soft SoC running in an FPGA. Or even an ASIC, if methods are eventually developed to verify the ASICs match the input design files at scale (i.e. non-destructive testing).

This seamless transition is one of the key benefits of an open ISA in my mind; development and testing of algorithms can be handled on the closed but top of the line (i.e. extremely powerful) ASIC, then when sensitive data is being handled that same binary can literally be run without changes on the soft core or other slower, but open, system. You could even compile on the slower ultra-trusted system, and test the binary on the larger ASIC -- lots of interesting possibilities here!

[madez]

That is exciting! Open and well-documented FPGAs are definitely useful and very interesting to have in a device. Have you looked into OpenPiton [0], PULP [1], BOOM [2], or lowRISC [3]? While I'm hopeful that you find these projects personally interesting, I'm also looking forward to eventually see them in devices. Sorry for not listing any open POWER CPU/SoC projects as I'm not aware of any. Please share if you know any.

[0] https://github.com/PrincetonUniversity/openpiton [1] https://github.com/pulp-platform [2] https://github.com/riscv-boom/riscv-boom [3] https://www.lowrisc.org/

[tpearson-raptor]

Microwatt is the first fully open POWER core:

https://github.com/antonblanchard/microwatt

It's also structured very well, quite clean for learning purposes etc. The current goal so far as I know is to perfect this core, and fork for a more complex / powerful variant. Maybe by the time that's done, the open FPGA tooling will have caught up enough to be able to run a usefully fast (~200MHz) POWER soft core, all in FPGA logic...

I'd strongly prefer a ppc64 core over a RISC-V core for one simple reason: we have a wide deployed base of very powerful ppc64 machines, and not having to keep cross compilers and related environments around is a massive streamlining step that we don't even know the full effects of yet (it hasn't been legal until now to have the SoC under development running the same architecture as the high end workstations and servers used to develop [for] it). The demo of using mainline GCC on a POWER box to build a binary for the Microwatt (that would also run on the host with KVM, if desired, for fast trace and debug) was most impressive.

[jtl999]

> It's probably a violation of your game's anticheat system to try to sandbox it

Funny enough I've heard claims recently that Steam/VAC detects KVM virtualization and temporary kicks from VAC games as a result.

[tpearson-raptor]

I wouldn't be surprised -- it's a gaping hole for anticheat software if not addressed. In fact, long term the anticheat is going to have to require a completely locked-down (console-like) experience from boot firmware (ME/PSP attested) through OS and userspace, or it will not be effective.

Which is one reason why I don't rent games on Steam, and why I bought a PS4 instead. If I'm going to have to game on a completely locked down system, I vastly prefer to do it on a system that doesn't touch any of my personal data and for which I can still buy permanent, resalable (and yes, even lendable) games on physical media.

PC gaming hasn't interested me since Steam on Windows with mandatory anticheat became the primary way to play games.