Setting up a cluster of computers used to be a high-end trick used in big data centers and labs. After all, buying a bunch of, say, VAX computers runs into money pretty quickly (not even counting the operating expense). Today, though, most of us have a slew of Raspberry Pi computers.
Because the Pi runs Linux (or, at least, can run Linux), there are a wealth of tools out there for doing just about anything. The trick is figuring out how to install it. Clustering several Linux boxes isn’t necessarily difficult, but it does take a lot of work unless you use a special tool. One of those tools is Docker, particularly Docker Swarm Mode. [Alex Ellis] has a good video (see below) showing the details of a 28 CPU cluster.
According to reports from Android Police and ZDNet, you may soon have a new operating system from Google to run on your Raspberry Pi. Details are still extremely sparse, the only description on the GitHub page is “Pink + Purple == Fuchsia (a new Operating System)”. But, here’s what we do know:
The new OS, called Fuchsia, will be based on Magenta, which is in turn built on LittleKernel. That means that, surprisingly, Google will not be using a Linux kernel for the new OS but something more like an embedded RTOS. Although Google is targeting embedded systems, the possibility of being able to run it on a desktop has been mentioned, so it may not be too minimalistic.
Google’s Travis Geiselbrecht has named the Raspberry Pi 3 specifically as one system it will run on, and said that it’ll be available soon. But, it seems Google is aiming to make it run on a variety of ARM devices (both 32 bit and 64 bit), as well as 64 bit PCs. This is a direct effort to compete against other commercial embedded operating systems that are currently available, and especially on IoT devices.
If you’re eager to see what this is all about, you can follow Google’s quick start recipes and see what you can come up with, although details are still sketchy enough that we’re just going to wait a bit.
Step one was to make sure that the thing works. Normally, you’d hook up a wired serial terminal and start hacking. [Ncrmnt] took it one step further and wired in a HC-05 Bluetooth serial module, so he can pull up the debug terminal wirelessly. The rest of the hackery was just crafting a bootable SD card and poking around in the Android system that was still resident in the flash memory of the system.
Once the board was proven workable, [Ncrmnt] designed and printed a sweet custom case using Solvespace, a constraint-based 3D CAD modeler that was new to us until recently. The case (after three prints) was a perfect fit for the irregularly shaped system board, a 3.7 V LiIon battery, and a speaker. He then added some nice mounting tabs. All in all, this is a nice-looking and functional mini-computer made out of stuff that was destined for the trash. It’s fast, it’s open-source, and it’s powerful. Best of all, it’s not in the dumpster.
If you don’t have root, you don’t own a device, despite what hundreds of Internet of Things manufacturers would tell you. Being able to access and write to that embedded Linux system in your new flashy gadget is what you need to truly own a device, and unfortunately this is a relatively uncommon feature. At this year’s DEF CON, [Brad Dixon] unveiled a technique that pwns a device using only a sewing needle, multimeter probe, or a paperclip. No, it won’t work on every device, and the devices this technique will work with are poorly designed. That doesn’t mean it doesn’t work, and that doesn’t mean the Pin2Pwn technique isn’t useful, though.
The attack relies on how an embedded Linux device boots. All the software needed to load Linux and the rest of the peripheral magic is usually stored on a bit of Flash somewhere on the board. By using a pin, probe, or paperclip to short two data pins, or two of the latch pins on this memory chip, the bootloader will fail, and when that happens, it may fall back to a uboot prompt. This pwns the device.
There are a few qualifications for this Pwn using a pin. If the device has JTAG, it doesn’t matter – you can already own the device. If, however, a device has a locked-down JTAG, unresponsive serial ports, or even their own secure boot solution, this technique might work.
This exploit works on the property of the bootloader. This bit of code first looks at a piece of Flash or other memory separate from the CPU and loads whatever is there. [Brad] found a few devices (mostly LTE routers) that would try to load Linux from the Flash, fail, try to load Linux again, fail, and finally drop to a uboot prompt.
As with any successful exploit, an equally effective mitigation strategy must be devised. There are two ways to go about this, and in this case, the software side is much better at getting rid of this attack than the hardware side.
Since this attack relies on the software falling back to uboot after an unsuccessful attempt at whatever it should be booting, the simplest and most effective mitigation technique is simply rebooting the device if the proper firmware can’t be found. Having a silent serial console is great, but if the attack relies on falling back to uboot, simply not doing that will effectively prevent this attack.
The hardware side is a little simpler than writing good firmware. Instead of using TSSOP and SOIC packages for storing the device firmware, use BGAs. Hide the pins and traces on an inner layer of the board. While this isn’t a foolproof way of preventing the attack – there will always be someone with a hot air gun, magnet wire, and a steadier hand than you – it’s hard to glitch a data line with a sewing needle if you can’t see the data line.
We toss together our own PCB designs, throwing in a microcontroller here or there. Anything more demanding than that, and we reach for a Raspberry Pi or BeagleBone (or an old Linksys router). Why don’t we just whip together a PCB for a small Linux computer? Because we don’t know how…but [Jonas] apparently does. And when we asked him why he did it, he replied “because I can!”
His Ethernet-to-6LoWPAN gateway project is a small, OpenWRT-capable Linux computer in disguise. Rather than yet another Raspberry Pi project, he designed around an Atmel AT91SAM9G25 400 MHz CPU, and added some memory, Ethernet, and a CC2520 radio chip to handle the wireless side. It’s all done on a four-layer board, and hotplate/skillet reflowed. This seems temptingly like something within our reach. [Jonas] had access to X-ray machines to double-check his reflow work, which probably isn’t necessary, although it looks really cool.
When finished, the project will link together a 6LoWPAN network (probably home automation) and his home wired network. That makes this device a rival to something like Philips’ Hue Bridge, which was the subject of some controversy when they locked out other devices for a few days until they recanted. Indeed, in response to this, there’s been quite a lot of effort at hacking the firmware of the Hue device, just to stay on the safe side in case Philips plays shenanigans again.
Soon, that’s not going to be necessary. [Jonas]’s design is open from the ground up, and coupled with open software running on top of the OpenWRT router operating system, that’s the full stack. And that’s great news for folks who are thinking about investing in a home automation technology, but afraid of what happens then the faceless corporations decide to pull the plug on their devices.
As a rule, I try hard not to get sucked into religious wars. You know, Coke vs Pepsi. C++ vs Java. Chrome vs Firefox. There are two I can’t help but jump into: PC vs Mac (although, now that Mac has turned into Unix, that’s almost more habit than anything else) and–the big one–Emacs vs vi.
If you use Linux, Unix, or anything similar, you are probably at least aware of the violence surrounding this argument. Windows users aren’t immune, although fewer of them know the details. If you aren’t familiar with these two programs, they are–in a way–text editors. However, that’s like calling a shopping mall “a store.” Technically, that’s correct, but the connotation is all wrong.
Like most religious wars, this one is partly based on history that might not be as relevant as it used to be. Full disclosure: I’m firmly in the Emacs camp. Many of my friends are fans of vi–I try not to hold it against them. I’ll try to be balanced and fair in my discussion, unless I’m talking about my preference. I don’t have to be fair when it comes to my opinions. Just to be clear: I know how to use vi. My preference isn’t based out of not wanting to learn something new.
Sure, you’re a hardcore superuser, but that doesn’t mean you don’t enjoy the finer things in life — like shiny squircles and getting every new app first. But, what’s an OS-indiscriminate person like yourself going to do when it comes time to purchase music? That’s where the recover_itunes tool shines, and if you’re a Linux user with an iPhone, it might just be your new best friend.