5 ms·
I would second the Raspberry Pi, it would be more or less immune to malware that targets x86 land, even Linux based malware. Still, I'd not have it connected to
by morganvachon 12y ago
I would second the Raspberry Pi, it would be more or less immune to malware that targets x86 land, even Linux based malware. Still, I'd not have it connected to the network and I would wipe the Pi's SD card afterward, just to be sure. Scripts can run on any architecture.
The Pi doesn't have a BIOS or EFI on board, it uses a special partition on the SD card to POST from, so there's no worry of the device itself being infected.
- matteotom 12y agoIn that case, you might be better off using a MIPS based device (old router, maybe?), since ARM is gaining popularity.
- kbenson 12y agoFrom what I've heard recently, targetting ARM may be problematic because two ARM processors may not support the same features, or function the same way. Then again, maybe there's a low-end subset of ARM instructions that should work an any chip, similar to the instruction set for the i386?
- wtracy 12y agoThe Arm specification primarily focuses on the protected mode opcodes used by applications. This is why Arm application binaries are portable across machines. The real mode opcodes needed to bring up a kernel are a mess on Arm, with each manufacture using their own instruction set.
- pjc50 12y agoThis explanation is garbled. The opcodes are not fundamentally different (although more are added from ARMv6 to ARMv7 e.g. the Pi 1 to Pi 2 transition), and there isn't the X86 different set of "real mode" opcodes. What is different is the boot sequence and system register layout. On a PC you can write one bootloader that works across multiple systems because either the peripherals are at the same place or BIOS/UEFI code is provided to sort it out for you. This is not the case on ARM; uboot and devicetree are attempts to fix it.
- justincormack 12y agoYou can feature detect at runtime. And or pick a subset. It is complicated but workable.
- nitrogen 12y agoThe Pi doesn't have a BIOS or EFI on board, it uses a special partition on the SD card to POST from, so there's no worry of the device itself being infected. It might be possible for a malicious script that gains root access to replace the SD card firmware with something that looks clean on the Pi, but delivers malware when some conditions are met.
- a1369209993 12y agoYou can always boot from a ROM/7400 board with no writeback capability, although that's a bit of a pain to set up.
- morganvachon 12y agoYep, which is why I said "I would wipe the Pi's SD card afterward, just to be sure. Scripts can run on any architecture." The SD card is not part of the RPi; there's nothing on the board itself that is writable.
- nitrogen 12y agoWiping the SD card using standard disk tools would not affect the SD card's firmware. SD cards are not dumb storage devices; they have built-in CPUs that handle DRM, protocol interfacing, and wear leveling, possibly among other things. That CPU has its own firmware, which might be reprogrammable by an attacker that knows the right commands to send.
- morganvachon 12y agoFair enough, I didn't think about that. I guess if you were using a RPi for a quarantine job like this, you would consider the SD cards as one time use devices and destroy them after use. The RPi itself shouldn't be affected though.