Cool that we are still discovering new things about old hardware. My only fear is that new hardware is too locked down to extends its life for either practical or hobby use. For example, modern Intel management engine could be used to have an always on webserver that consumes very little power when idle by turning off the main processor and only monitoring a network port in low power management microcontroller. But I am sure it's all DRMed and unaccessible.
At this point we have to distrust the chips in our own devices. These chips are clearly not being designed to serve us (the owners of the devices that contain them). I'd even be fine with slower processors so long as we had the ability to verify exactly what they are and are not doing. With hardware we could trust not to betray us or prevent us from doing whatever we wanted we'd be better off than with locked down processors that prevent us from doing what we want but perform 'approved' operations faster.
> I'd even be fine with slower processors so long as we had the ability to verify exactly what they are and are not doing. With hardware we could trust not to betray us or prevent us from doing whatever we wanted we'd be better off than with locked down processors that prevent us from doing what we want but perform 'approved' operations faster.
It’s time to bring back old hardware sitting in closets as while they may be obsolete from a performance perspective they are ahead in terms of privacy. Let’s stop stripping old hardware support out of the Linux kernel and keep distros for old hardware alive.
done exactly this - reading & commenting from an old ThinkPad running OpenBSD. I don't buy new computers, I buy old ones from craigslist (in fact, multiple, so I can use the same system & compatible parts for many years to come). :)
I've heard stories of Thinkpads with UEFI-level rootkits, flashed a modified UEFI myself (though my edits didn't achieve what I set out to do), and read about white-hat exploits putting keyloggers on the EC (power/keyboard controller): https://hackaday.com/2021/07/20/extracting-the-wifi-firmware.... I wouldn't fully trust used computers, to the extent I'd trust a Precursor, single-tasking microcontroller, or pre-2000 game console.
> reading & commenting from an old ThinkPad running OpenBSD
How old? IBM Thinkpads were often decent enough that I'd pick one up if I saw a good deal, but Lenovo makes them now and they've got a long history of pre-installing malware and backdoors in their products (often in exchange for money). It's a shame, because I hear they play very well with linux.
I'm not sure a Lenovo device would be any safer than the latest processors
Pretty much all OEMs preinstall adware. Microsoft infects their own OS with crapware.
They don't all ship with malware infested UEFI so that even reinstalling your OS won't remove the bloatware they installed. Also Lenovo has, multiple times now, installed adware on systems that seriously compromised the security of the user and/or the device.
Adware is bad, remote code execution is much worse.
Superfish was bad enough, but once the public became aware that the malware existed and was so insecure that it made their devices vulnerable to be hacked Lenovo provided people with a fix to remove the malware, but it left the security vulnerability that the malware introduced to the system in place leaving everyone to think they solved the problem when they were still vulnerable. People had to track down news articles and social media posts for information on how to correct the problem until Lenovo updated their instructions. (https://arstechnica.com/information-technology/2015/02/how-t...)
OpenBSD Intel Atom n270+1GB RAM netbook user there, among others.
Lariza as the big webkit2gtk4 browser, Links and Lynx as normal browser, with media bound to mpv+yt-dlp and nsxiv. MuPDF and a pipe with einfo -pp | lynx... | less for ebooks. ImageMagick, FFMPEG, sox. C, Perl for programming.
Bitlbee and Swirc for multi IM chat, sfeed for RSS news and podcasts, slrn for Usenet news.
A slightly hacked PCSX4ALL emulator (PSX) plus Mednafen for retrogaming among Slashem, BSDGames and Frotz for IF games.
Who said slow? OK, no Google Earth but I can use some TCL/TK based OSM map viewer from the TkIMG demos, and no Wine to play the games for that era. But, meh, I only get GL 1.4, not enough for proper DirectX9 translation (GL 2.1 it's the true basic DX9->GL mapping), so I've got lots of libre alternatives from https://osgameclones.com and a custom ScummVM compiled from ports with --enable-all-engines added to the configure script so I can play games from the Apple II era, passing thru Ultima IV, Maniac Mansion, Broken Sword up to Blade Runner and, soon, Sanitarium.
These days I would bet all internal/debugging features are gated behind asymmetric crypto-based challenge/response. And it's probably physically impossible to decap a <10nm chip and inspect visually. I don't see a way around it other than hoping for implementation bugs. It might be the end of the road for the hackers :(
The AMD FX 8320 tower that I bought 2 weekends ago was one of the last CPUs from AMD to not have a PSP, platform security processor. Which is part of why I bought it...
Not-so-shockingly, the way they did it was to use an actual 286 chip to "emulate" itself, with some extra pins to allow the debugging hardware to monitor it and take control.
...and the code of the ICE itself ran on the CPU, so in other words, it's like a hypervisor. It's amazing that Intel was so close to giving the 286 a true virtualisation feature.
I first posted about this on the VCFed.org forums in 2019,
> STOREALL, on the other hand, is used for a surprising purpose: as part of the sequence to exit from ICE mode! The reason is that it is the only instruction capable of exiting protected mode, acting very much like a reset.
Ah so that's why Intel didn't want anyone to know about ICE. Could STOREALL be used to write a real exploit? It's interesting since I imagine that in order to know your security works, you have to violate it. I would just hope Intel's been practicing this in a way which doesn't let the bad guys do it too.
Prior to the introduction of SMM, Ring 0 (CPL0) was full privilege. The ability to kick the CPU into ICE mode, even if there was some way to actually do something in ICE mode [0] would have been, at most, a way to get at some Intel secret sauce. At attack against the system owner wasn’t in the cards, because the system owner never had any protection from CPL 0 code in the first place. (Unless the system could be induced to self destruct, but even a pretty good self destruct was likely possible from CPL 0 by destroying CMOS or potentially overwriting firmware.)
Even with the addition of SMM, this wouldn’t have been a very big deal - SMM was mostly a kludge to allow system vendors to provide value-added (supposedly) features, and an SMM break would just allow reverse engineering of or interference with these.
On a modern system, it’s a bigger deal. An attack against the ME is every bit as bad as it sounds. Even an attack against SMM breaks Secure Boot and protections against malicious firmware updates [1], which, in turn, could break some TPM protections.
[0] Maybe with cache poisoning? If the instruction after STOREALL could be fetched from cache and regular ring 0 could poison that cache, code execution in ICE mode might be possible.
[1] This is IMO a terrible design on Intel’s part. For some reason, UEFI secure variables are nearly universally implemented by protecting a region of flash from writes originating outside SMM mode. Once in SMM mode, they can be freely overwritten (at least unless SMM itself implements a protected kernel, which is the new hotness). Coming up with simpler and more secure designs is not terribly hard IMO.
>Maybe with cache poisoning? If the instruction after STOREALL could be fetched from cache and regular ring 0 could poison that cache, code execution in ICE mode might be possible.
The 286 had no internal cache (in the sense of CPUs today). It did have a queue of prefetched instruction bytes, as well as another queue of up to 3 decoded instructions. But that gets flushed by STOREALL, since it effectively returns the CPU to the same state as after a reset, only with the ICE mode flip-flop set.
(Normal breakpoints, or any control transfer at all, also have to clear the queues, else the CPU would first execute whatever it had prefetched before continuing with code from the new location!)
And yes, in my experiments with this I did try to stuff something in the prefetch queue anyway, as well as setting the IDT limit to zero and enabling the trap flag in the hope that it would cause a triple-fault while in ICE mode. No such luck.
What might be possible is some external hardware that pushes opcode bytes onto the bus with the right timing. I'm not enough of a hardware person to design something like this, and don't think the DMA controller could be (ab)used for that purpose.
Even with cheap modern equipment it should be no problem to manipulate the bus of something as glacially slow as a 286. With common bus frequencies, you don't even need to be really careful with the PCB layout, and e.g. a Zynq (FPGA+ARM SoC) is probably total overkill already but convenient and fun.
But the unbonded pads that you mention are a far greater concern to me...
From an extremely cursory read of old webpages, it sounds like the main problem is that the signal that initiates an ICE bus transaction (ICES1# & ICES0# which, by analogy to S0 and S1 are active-low and initiate bus cycles) are unbonded. I bet a good enough guess could be made from the address and data lines to feed instructions and data to the CPU in ICE mode. Distinguishing memory reads from writes could be interesting.
AFAIK, nobody outside of Intel has a clear idea why they made the "protection enable" bit sticky on the 286. If the attacker controls ring 0, preventing them from exiting protected mode serves no purpose.
Ah, you think it was intended for "security"? I always imagined one of two things:
1) Intel didn't bother implementing or properly verifying that all the state transitions from protected to real mode work perfectly. But just the existence of LOADALL, and its use, pretty much completely invalidates that theory. Especially now that I learned from your article that ICEs were running the CPU in protected mode...
2) They really, really wanted to lure people away from real mode, and show protected mode as the future. Real mode being deprecated, ideally you would only use it to bootstrap into protected mode and nothing else. Somewhat related to that is the very exotic Intel 80376, which was essentially a 80386 with only protected mode! https://www.pagetable.com/?p=460
A quick search shows that LOADALL can only be run from ring 0, so the same might be true for STOREALL. So ring 0 kernel could use STOREALL to return to real mode, but ring 3 user code would probably get an illegal instruction trap.
As mentioned in the post, LOAD/STOREALL only run in ring 0. Also you can't use it to return to real mode except from code running in ICE address space, which isn't accessible except on the special bond-out chip version.
What you can do with STOREALL - with the F1 prefix - is store a bunch of internal registers to memory and then have an external chip (such as the AT keyboard controller) reset the CPU.
Intel for some unknown reason tried really hard to make it impossible to exit protected mode!
Yeah. The trick on the 386/486 is that the visible segment registers are only part of the actual registers. When you load a segment register, relevant data (base, limit, as far as I recall) from the descriptors get loaded into the invisible part (so a sort of "descriptor cache").
The "trick" was just to load the segment registers with a selector pointing to a descriptor with a large segment, and then just go back to real mode without immediately reloading the segment registers, as Intel very careful prescribes in their manual. The CPU would still use the unchanged hidden part of the registers for addressing. As soon as you load another value, that gets replaced with a real mode conformant 64k limit.
Now I'm really pretty curious what was in those "internal" registers! I assume it's not just the descriptor cache?
EDIT: Based on the vcfed thread mentioned earlier[1], seems like it just might be temporary registers that microcode uses, so potentially not have any effect across instructions.
"This must be passed to the FPU interface, which acts somewhat like a DMA controller and contains its own base and limit registers." What may be fun is the coprocessor segment overrun exception.
>"When comparing ICE mode to System Management Mode,
you could easily conclude that SMM was derived from ICE mode because their similarities are striking.
Certainly, they have more similarities than differences. In reality, SMM appears to be both a subset and a superset of ICE mode. For the purposes of this comparison, I'll contrast 80386 ICE mode with Pentium SMM. Consider the following similarities:
o Both modes use a microprocessor input pin to trigger invocation. On the 80386 DX, this undocumented pin is located at position B6. On SL-enhanced Intel microprocessors, this pin is named SMI#.
o Both modes use a microprocessor output pin to indicate when in ICE or SMM mode. On the 80386 DX, this undocumented pin is located at position C7. On SL-enhanced Intel microprocessors, this pin is named SMIACT#.
o Both modes may be entered from any processor mode at any time by asserting the applicable input pin.
o Both modes have the ability to resume to any processor mode and to any CPL upon completion.
o Both modes save the entire microprocessor state to a state-save map upon entrance.
o The state-save map area is in a protected memory space, isolated from user memory.
o Both modes restore the entire microprocessor state from the state-save map. Neither LOADALL nor the SMM- equivalent RSM instruction sanity check the data in the state save map upon resumption. On the 386 or 486, LOADALL doesn't validate any of the microprocessor state from the state-save data. Therefore it is possible to use LOADALL to perform microprocessor tricks that would otherwise be illegal. For example, you could enable paging, yet remain in real mode. SMM uses the RSM instruction to restore the microprocessor state. RSM does perform some minor sanity checks (like the real-mode paging check), but otherwise does little. Using either instruction, it is possible to change the access rights of segment descriptors to illegal values - like making the code segment writable in protected mode or setting the GDT access rights (which in theory don't exist) to Not-Present.
o The ICE-mode LOADALL instruction on the 486 and the RSM instruction on all SL-enhanced microprocessors are disabled when operating outside of their respective operating modes. Both instructions generate an invalid opcode exception when executed outside of ICE mode and SMM, respectively.
o The order in which the microprocessor state information is written is exactly the same, but the direction is different. ICE mode writes data from bottom to top, and SMM writes data from top to bottom (like a stack).
o Both modes begin execution in real mode, with all segments as read/writable and having 4-GB limits.
o Both modes begin execution of a special handler after the microprocessor state is saved.
o The most compelling similarity of all is the state-save map. When viewed side-by-side, the state save map of ICE mode and SMM look virtually identical.
Should take about the same time as LOADALL (195 clocks).
All they needed it to do was reset the CPU. But instead the instruction simulates something like an ICE breakpoint and all the state gets written to memory! And then you have to run LOADALL as well just to clear the "ICE mode" bit again.
