Read your own source, the architecture dependent blobs are for the GPU architecture, not the CPU.
Linux on POWER just loads those blobs like any other arch and uses the open source drivers.
POWER9 Benchmarks
Xavier Cooper
Carson Rogers
>You stupid fuck read phoronix.com
I don't understand what you are trying to prove, the binary blob doesn't run on the CPU, its code which is loaded onto the GPU at runtime. RaptorCS even lists AMD GPUs as compatible on their wiki.
Ethan King
>not a security risk at all, trust (((us))) at AMD
I'll eat my words if they ever opensource the microcode. But we know that will never happen intentionally.
Nathan Sanders
I agree that the firmware should be opened but what possible vulnerability do you foresee?
The GPU still only interacts with the kernel via an open source driver, it has no control over the RAM, MMU or network card.
What can it actually do?
Ethan Davis
You realize every single ASIC in nearly every component of any computer you'd care to name is the hardware equivalent of a "binary blob", since you don't can't read the VHDL files they're made from, let alone verify the fab's fidelity to those files, right?
Nolan Cox
Most modern PCIe devices run their own microcode, GPUs, NVMe SSDs, HBAs and RAID controllers, etc. Even some NICs have microcode from what I understand.
Technically the GPU can read and write to any system memory address it wants via its DMA engines.
If a GPU is behind a PCIe switch (or on a root complex which supports P2P transactions) along with the NIC then theoretically it could communicate to the outside world by interacting with it directly. However the microcode would have to have an entire copy of that NICs driver, which in practice would have to be every single NIC ever made for it to reliably work, and the GPU would have to work out where the NIC is and what model, etc...
Similar attacks could be done by a userspace application via a filesystem running on top of an NVMe SSD. NVMe SSDs have DMA engines and many common ones run firmware.
IOMMUs protect against this type of attack though.
Angel Ward
Well, it could house a entire operating system+rootkit like minix that is only loaded while it is on. Kinda like jewtel's ME or AMD's PSP or ARM's (((kikzone))) but more effecient.
Open source does not mean secure. The possibly independent operating system running entirely on the GPU could start sending errors down the command stream of instructions as to implement persistent rootkit like functionality. For one example your CPU directs the buffer to the screen but in that moment when it does so you could implement your rootkit with faulty GPU code hidden as bugs in the kernel. And considering amd contributes to the kernel in large amounts it would be very easy to do. This is just one example of a few that spring to my mind. Yet more reasons not to use newer AMD GPU's and the newest nvidia GPU's with their blobs. Stick to the old r300 series or the nouveau supported GPU's you insecure faggots.
No you moron, show me a single use case of AMD's newest GPU's on another architecture without specialized blobs. The only thing I could find even related is archive.fo
Brandon Johnson
Yes I am aware of that. But just like GNU's libre OS list, I treat non-writeable blobs that are burned onto the hardware as part of the hardware. Loadable blobs can be manipulated however. But non-loadable's not so much unless it was malicious from the factory. But if you care about it being malicious from the factory you are stepping into true security type areas at which point, why aren't you designing the hardware from the ground up as you point out? Why bother with a talos ii other then it's easier to verify its functionality being entirely opensource or able to be so?
And this is why people buy devices like the talos II, because you don't have to deal with any of this shit. Get all of it FOSS and begone blobs. There's even opensource SSD's now for your opensource/security autism.
Or it could just call linux kernel functions in memory. Get creative.
Henry Ross
CPUs hold special privileges compared to every other component (except maybe your NICs, I guess). None of what you speculated is any likelier than malicious SIPs being hidden inside your retro hardware.
How? If you verify checksums before flashing ROMs with each upgrade, that's impossible unless your entire system has already been compromised to the extent counterfeit ROMs could be flashed without your knowledge.
Ethan Sanchez