A Real GPU On The Raspberry Pi — Barely.

[Jeff Geerling] saw the Raspberry Pi Compute Module 4 and its exposed PCI-Express 1x connection, and just naturally wondered whether he could plug a GPU into that slot and get it to work. It didn’t. There were a few reasons why, such as the limited Base Address Register space, and drivers that just weren’t written for ARM hardware. A bit of help from the Raspberry Pi software engineers and other Linux kernel hackers and those issues were fixed, albeit with a big hurdle in the CPU. The Broadcom chip in the Pi 4, the BCM2711, has a broken PCIe implementation.

There has finally been a breakthrough — Thanks to the dedicated community that has sprung up around this topic, a set of kernel patches manage to work around the hardware issues. It’s now possible to run a Radeon HD 5000/6000/7000 card on the Raspberry Pi 4 Compute Module. There are still glitches, and the Kernel patches to make this work will likely never land upstream. That said, It’s possible to run a desktop environment on the Radeon GPU on a Pi, and even a few simple benchmarks. The results… aren’t particularly inspiring, but that wasn’t really ever the point. You may be asking what real-world use is for a full-size GPU on the Pi. Sure, maybe crypto-mining or emulation, or being able to run more monitors for digital signage. More than that, it might help ensure the next Pi has a working PCIe implementation. But like many things we cover here, the real reason is that it’s a challenge that a group of enthusiasts couldn’t leave alone.

Continue reading “A Real GPU On The Raspberry Pi — Barely.”

SSH Is Magic, But Tunnels Are Even Better

Once upon a time, I was doing on-site support for a hardware install at a hotel a few years ago. The remote tech’s remote desktop software didn’t want to play with my Linux laptop, so he couldn’t get into the switch he needed to configure, to make the install work. I asked if it had an SSH port he could use, were he were in the room with me. Of course it did, but that didn’t do him much good. I ran a reverse SSH tunnel out to my public server, and pointed it at the switch on the local side. I convinced him to SSH to my server on the given port, and he was magically connected to his switch. He was literally in awe of that trick, and demanded to know how it could be done. SSH is magical, but tunneling traffic over SSH is straight-up wizardry. [Shawn Powers] agrees, and decided to help the rest of us understand the process.
Continue reading “SSH Is Magic, But Tunnels Are Even Better”

This Week In Security: Java’s Psychic Signatures, AWS Escape, And A Nasty Windows Bug

Java versions 15, 16, 17, and 18 (and maybe some older versions) have a big problem, ECDSA signature verification is totally broken. The story is a prime example of the dangers of unintended consequences, the pitfall of rolling your own crypto, and why to build a test suite for important code. In Java 15, the ECDSA verification code was re-written, moving the code from C++ to a Java-native implementation. The new code misses an important check, that the initialization and proof values are both non-zero.

Continue reading “This Week In Security: Java’s Psychic Signatures, AWS Escape, And A Nasty Windows Bug”

Ray-Traced Doom Really Shines!

We’re huge fans of taking retro games and adding new graphics features to them, so you had to know that when [Sultim Tsyrendashiev] released his ray-traced Doom engine, we would have to cover it. Now this does break with tradition — instead of running Doom on every conceivable platform, this version requires an AMD or Nvidia ray tracing capable card. On the other hand, the spirit of Doom is certainly alive, as ray-traced Doom has already been demonstrated on the Steam Deck. Check out the video below for a demo, and come back after the break for more info.

The most exciting part of this graphical feat may be the RayTracedGL1 library that “simplifies the process of porting applications with fixed-function pipeline to real-time path tracing.” Besides Doom, there’s also been demos made of Serious Sam and Half-Life 1. There’s even experimental Linux support! We managed to compile and test it on our system, running a 6700 XT and Fedora 35 with bleeding edge Mesa. There are a few visual glitches to work out, but it’s an outstanding project so far. The only complaint we have is that it’s based on prboom, not the still-maintained GZDoom, though with enough attention who knows where the project will go. If this leaves you hungry for more, check out more retro-upgrades, or Doom on more devices.

Continue reading “Ray-Traced Doom Really Shines!”

This Week In Security: OpenSSH, Git, And Sort-of NGINX 0-day

OpenSSH has minted their 9.0 release, and it includes a pair of security changes. Unlike most of the releases we cover here, this one has security hardening to prevent issues, not emergency fixes for current ones. First up, the venerable scp/rcp protocol has been removed. Your scp commands will now use SFTP under the hood. The more interesting security change is the new default key exchange, the NTRU algorithm. NTRU is thought to be quantum-hard.
Continue reading “This Week In Security: OpenSSH, Git, And Sort-of NGINX 0-day”

This Week In Security: Vulnerable Boxes, Government Responses, And New Tools

The Cyclops Blink botnet is thought to be the work of an Advanced Persistent Threat (APT) from Russia, and seems to be limited to Watchguard and Asus devices. The normal three and four letter agencies publicized their findings back in February, and urged everyone with potentially vulnerable devices to go through the steps to verify and disinfect them if needed. About a month later, in March, over half the botnet was still online and functioning, so law enforcement took a drastic step to disrupt the network. After reverse-engineering the malware itself, and getting a judge to sign off on the plan, the FBI remotely broke in to 13 of the Watchguard devices that were working as Command and Control nodes. They disinfected those nodes and closed the vulnerable ports, effectively knocking a very large chunk of the botnet offline.

The vulnerability in WatchGuard devices that facilitated the Botnet was CVE-2022-23176, a problem where an “exposed management access” allowed unprivileged users administrative access to the system. That vague description sounds like either a debugging interface that was accidentally included in production, or a flaw in the permission logic. Regardless, the problem was fixed in a May 2021 update, but not fully disclosed. Attackers apparently reversed engineered the fix, and used it to infect and form the botnet. The FBI informed WatchGuard in November 2021 that about 1% of their devices had been compromised. It took until February to publish remediation steps and get a CVE for the flaw.

This is definitely non-ideal behavior. More details and a CVE should have accompanied the fix back in May. As we’ve observed before, obscurity doesn’t actually prevent sophisticated actors from figuring out vulnerabilities, but it does make it harder for users and security professionals to do their jobs. Continue reading “This Week In Security: Vulnerable Boxes, Government Responses, And New Tools”

This Week In Security: More State-Sponsored Activity, Spring4Shell

[Editor’s note: There is a second, fake iteration of this column out today. This is obviously the real column.]

An alert from CISA, combined with an unsealed pair of indictments, sheds some new light on how Russian hackers pursue high-value targets. The key malware here is Triton, essentially a rootkit designed for the Tricon safety systems, widely deployed at refineries and other infrastructure facilities. One of the early deployments of this was to a Saudi oil plant in 2017. This deployment seems to have been botched, as it caused malfunctions and shut the plant down for about a week.

The new information is confirmation that the same operators, out of the “Central Scientific Research Institute of Chemistry and Mechanics”, attempted to target US facilities with the same campaign. The Wired coverage initially struck me as odd, as it detailed how these Russian attackers researched US refineries, looking for the most promising targets. How exactly did US intelligence agencies know about the research habits of agents in Russia? The details of the indictment has the answer: They were researching US refineries by downloading papers from the US Department of Energy. As the IP addresses of this Russian research group is known and tracked, it was easy enough for US agencies to make the connection.

Continue reading “This Week In Security: More State-Sponsored Activity, Spring4Shell”