As far back as we can remember, there have always been hacks, exploits, and just curiosity about undocumented CPU instructions. The Z80 had them. Even the HP41C calculator had some undocumented codes. The HCF (Halt and Catch Fire) instruction was apocryphal, but we always heard the old video controller chips could be coaxed into blowing up certain monitors. You don’t hear too much about things like that lately, perhaps because fewer people are working in assembly language.
[Sergi Àlvarez i Capilla] not only works in assembly language, he was writing an ARM assembler when he noticed something funny. Instructions are built in a regular pattern and some of the patterns were missing. What to do? [Sergi] lost no time trying them out.
His result? He found at least one instruction that causes a Raspberry Pi to lock up dead. All by itself, that’s not a big deal, but the instruction isn’t protected so any user program could potentially lock up a Pi. A reset will set things right, of course. No combustion occurs. The newer models, by the way, seem to be immune and [Sergi] tested some phones and other devices with ARM processors to no effect.
The practical implications? Probably not much? But if you were putting a Pi in a critical system, you might find this result interesting. Maybe the best defense against this kind of hack is only having one instruction to start with. The 6502, by the way, was well known for having a large number of useful undocumented op codes. There’s some talk about that in the video below (the undocumented part starts around 6:00).
I’m pretty sure the people in charge of creating Windows ME were hired to design the ARMv6 ISA…
In day one of computer class, 1998, my buddy and I were trying out monitor settings and we blew it up. Not kaboom, but a weird noise, a puff of smoke, and that was the end of that monitor.
Totally possible with CRT monitors, sometimes setting the refresh rate too high or something can toast it. It’s all analog hardware for the most part, it will try do do whatever you tell it, where-as digital displays will just say the signal is out of bounds
Old fixed sync monitors would do that. If you pushed them too far out of their expected sync frequency then you’d end up blowing the HOTs. The fancier multisync ones were much more robust.
I pushed my old view sonic a bit too hard and basically cut it’s lifespan in half.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0040d/Chddhfed.html
Angel breakpoint
Perhaps BCM forgot to disable core debugging in that core?
Huh… Nice catch! (no pun intended)
This even shows up when just throwing the hex-number into google. I wonder why OP hadn’t done that…
Because trying to create a scandal and make a name for yourself is much more exciting.
That seems to be a software debugging feature, so “halt and catch… ???” is probably an accurate description of the problem. Something somewhere in the software stack is presumably catching the exception and then has no idea what to actually do with it.
His decoding of the instruction is wrong. On the command line he specified a sequence of bytes but the ARM documents describe the instruction decoding of 32 bit words which are little endian on the RPi.
This is the ultimate instruction set reference (needs free registration):
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0406c/index.html
On page A8-758 it tells us that this instruction is called UDF and generates a corresponding exception.
This is the last comment needed in this thread, all the comments below are pointless
That’s rich. At the least he found a broken exception handler in the kernel.
Sorry, that was a (hasty) reaction to the comment immediately below, which took this post as an opportunity to rant about all things Broadcom — an unjustified rant, because as Daniel says the instruction is actually documented, OP just forgot to RTFM.
It’s not as though Broadcom had any hand in the design of the ARM core as it is.
But yes, you’re right, the kernel not handling this exception is definitely a bug.
The funny bit is when the OP gets the bytesex backwards when decoding the instruction. It’s a delightful contrast to the security research blabber in the rest of the page, and made me feel just a little less stupid today.
The day closed IP is secure is the day they have been opened. Point and case above.
2nd topic here is why Broadcom mainstream SoC R*i are considered secure at first place ? It’s overpriced piece of obsolete tech. Sadly ARM IP can guaranty security nor quality by it-self. Nor can then guaranty anything when its further developed / modified by Broadcom.
Then we got that the SoC specifically produced for R*i2 has so many flaws one would guess the mass will stop buying it. But obviously no one cares about quality nowadays. Good marketing, good funding, surprising Broadcom contract => then famous then profitable, yet does not mean successful, neither more proven than other SBC ! Not at all. Further more same price ,higher quality of PCB and even perf.wise. There’s the other ESP trend which is opposite , similar poor quality on the very cheap. Learn , test, design, but lest stop fooling ourselves that this can be in-fact safe, nor secure. I’m just scared to think any of those R*i or ESP to be actual 24/7 home automation for an year, what’s left for 5 or 10.
If you planned to use an RPi in a setting that required a very high degree of security, that’s fail number one.
You are forgetting that even though they are flawed, the Pi started as a way to get cheap computing out to people and places that could not afford it.
It’s a device meant for use in education and hobby environments. Anyone using these in a commercial environment should have thought about their priorities.
People that see a very heavily tested chip as obsolete likely never had to do commercial builds.
I like seeing the errata as chips evolve, as we can avoid the same design mistakes.
I’ve seen $450k USD purple backbone fibre routers with the same problem (one blade takes out the others when it goes down). LOL ;-)
Could you please list the many flaws in the BCM2836? It would be nice of you to share your knowledge with us.
Although I don’t think BCM2836 has THAT many flaws, usb core is THE flaw. It’s absolutely horrible cheap POS and they should feel bad for using it.
The core works mostly fine in device mode. It is actually used very much in cellphones and things like that. It has a host mode that almost nobody uses, so probably the issue only came to light when the raspi was developed. The core takes significantly less silicon than other more featureful usb cores so it may be worth it.
Okay, that’s actually a very good point. It was meant to be used for OTG device mode, and getting it to work as a host has involved implementing a lot of things in software that ought to be in hardware.
That it works as well as it does shows some pretty impressive programming chops going on somewhere, but an actual host controller would be nice to have further down the line.
It may have something to do with the fact that the 2835 was never intended to be an applications processor at all, but a media coprocessor for Nokia phones.
The ARM was added between the A0 and B0 spins of the silicon. That’s why there are a lot of oddities like the boot process (including reading a FAT filesystem off of the SD card) taking place on the GPU.
The VideoCore is actually running a fairly comprehensive RTOS (contained in start.elf) while the ARM cores are running Linux.
The Broadcom chip isn’t specifically produced for the Raspberry Pi. It is still a current product as well so it isn’t obsolete. The rest of your rant is hard to decipher.
I’m reminded of the killer POKE command for Commodore PET. Early on hackers found a way to speed up PET a bit by using POKE command. However when CBM released a redesigned PETs later with larger memory, larger screen, etc using the same POKE command could actually cause serious damage.
The old 6809 (tandy/RS Color Computer) did have an instruction that would cause the chip to lock into a loop and heat up and melt down
I think “halt and catch fire” comes from the days of core memory. Some CPUs (or their assemblers) implemented halt as a jump to self instruction. Repeatedly accessing the same magnetic cores, which involves flipping them back and forth across their hysteresis loop, dissipates a significant amount of energy and the cores can start smoking when the CPU halts.
ISTR there actually was a military-spec CPU that had a specific self-destruct opcode for security, it might even have been featured on HaD. Plenty of military kit has self-destruct built in and there’s military training on how to destroy your stuff if the enemy are getting too close.
Sensitive military equipment was issued with a thermite blanket that you’d throw on the top and set fire to. It’d be a puddle of molten metal afterwards.
Some commercial equipment does have self destruct but it usually involves wiping memory of crypto keys if you tamper with the enclosure or the CPU. You’d get them in things like HSMs used for crypto management in banks.
I worked with a military radio set. Those units came with a hammer, a titanium spike and a marked area on the casing where applying the hammer to the spike as documented in the manual would put a hole of carefully specified dimensions through the crypto-chippery inside the box.
I bet “Mr Hammer & The Spike” cost at least 5000 EUR also.- It had a pretty comprehensive set of Q&A documentation attached with it.
The 6502/6510 cpu had a bug where certain unoffical opcodes sent the cpu into a crash/loop condition. I think it was opcode 02h but an external reset would reboot the system without affecting most memory addresses. Zero page/stack/etc would get cleared of course. It was used primarily in protection schemes when the protection check failed and they wanted to lock the system.
I think there was a similar issue with the ZX81. Random idiocy on my part seems to have caused the little clunker to have memory issues that ended its days as my 1st computer.
To be honest that probably wasn’t you. The ZX81’s external 16K RAM pack was notorious. Fixes included bits of velcro to stop it wobbling on the machine’s edge connector, to putting a pint of milk next to it to keep from overheating.
Sinclair was a genius at miniaturisation, and doing things cheap. Reliability, not so much.
Remember this? :)
https://en.wikipedia.org/wiki/Pentium_F00F_bug
F00FC7C8 IIRC. What a useful string of hexadecimal to have burned in one’s memory.
Built in planned obsolescence? End of warranty and this instruction gets thrown after Post?
It’s a debug instruction, and it *is* documented. OP got the byte order wrong.
The scary thing is I got a medical device in our helpdesk that was reported to be having wireless connectivity issues… the chucklefuck vendor apparently resells a Raspberry Pi running Raspbian (installed from a Mac with NOOBS) in a cheap $10 case and cheap $10 power supply and a crummy $10 wireless dongle taped to a $5 USB-Ethernet adapter.
… the Pi is supposed to collect data from a patient monitor and forward it onto a “cloud” based application…
… used by anesthesiologists to document during OR cases.
No tamperproof seals or screws either…