Over the years there have been a few CPUs designed to directly run a high-level programming language, the most common approach being to build a physical manifestation of a portable code virtual machine. An example might be the experimental Java processors which implemented the JVM. Similarly, in 1976 Itty Bitty Computers released an implementation of Tiny BASIC which used a simple virtual machine, and to celebrate 50 years of Tiny BASIC, [Zoltan Pekic] designed a CPU that mirrors that VM.

The CPU was created within a Digilent Anvyl board, and the VHDL file is freely available. The microcode mapping ROM was generated by a microcode compiler, also written by [Zoltan]. The original design could execute all of the 40 instructions included in the reference implementation of Tiny BASIC; later iterations extended it a bit more. To benchmark its performance, [Zoltan] set the clock rate on the development board equal to those of various other retrocomputers, then compared the times each took to calculate the prime numbers under 1000 using the same Tiny BASIC program. The BASIC CPU outperformed all of them except for Digital Microsystems’ HEX29.

The next step was to add a number of performance optimizations, including a GOTO cache and better use of parallel operations. [Zoltan] then wrote a “Hello World” demo, which can be seen below, and extended the dialect of Tiny BASIC with FOR loops, INPUT statements, multiple LET statements, the modulo operator, and more. Finally, he also extended the CPU from 16-bit to 32-bit to be able to run an additional benchmark, on which it once again outperformed retrocomputers with comparable clock speeds.

We’ve previously seen [Zoltan]’s work with FPGAs, whether it’s giving one a cassette interface or using one to directly access a CPU’s memory bus. BASIC has always been a cross-platform pioneer, once even to the extent of creating a free national standard.

Cisco’s ClamAV has a heap-based buffer overflow in its OLE2 file scanning. That’s a big deal, because ClamAV is used to scan file attachments on incoming emails. All it takes to trigger the vulnerability is to send a malicious file through an email system that uses ClamAV.

The exact vulnerability is a string termination check that can fail to trigger, leading to a buffer over-read. That’s a lot better than a buffer overflow while writing to memory. That detail is why this vulnerability is strictly a Denial of Service problem. The memory read results in process termination, presumably a segfault for reading protected memory. There are Proof of Concepts (PoCs) available, but so far no reports of the vulnerability being used in the wild.

AMD Vulnerability Leaks

AMD has identified a security problem in how some of its processors verify the signature of microcode updates. That’s basically all we know about the issue, because the security embargo still isn’t up. Instead of an official announcement, we know about this issue via an Asus beta BIOS release that included a bit too much information.

I Read the Docs

There’s nothing quite as fun as winning a Capture The Flag (CTF) challenge the wrong way. The setup for this challenge was a simple banking application, with the challenge being to steal some money from the bank’s website. The intended solution was to exploit the way large floating point numbers round small values. Deposit 1e10 dollars into the bank, and a withdraw of $1000 is literally just a rounding error.

The unintended solution was to deposit NaN dollars. In JavaScript-speak that’s the special Not a Number value that’s used for oddball situations like dividing by a float that’s rounded down to zero. NaN has some other strange behaviors, like always resulting in false comparisons. NaN > 0? False. NaN < 0? False. NaN == NaN? Yep, also false. And when the fake bank web app checks if a requested withdraw amount is greater than the amount in the account? Since the account is set to NaN, it’s also false. Totally defeats the internal bank logic. How did the student find this unintended solution? “I read the docs.” Legendary.

Another Prompt Injection Tool

[Utku Sen] has a story and a revamped tool, and it leads to an interesting question about LLMs. The story starts with a novel LLM prompt, that gives more natural sounding responses from AI tools. LLMs have a unique problem, that there is no inherent difference between pre-loaded system prompts, and user-generated prompts. This leads to an attack, where a creative user prompt can reveal the system prompt. And in a case like [Utku]’s, the system prompt is the special sauce that makes the service work. He knew this, and attempted to protect against such attacks. Within an hour of releasing the tool to the public, [Utku] got a direct message on X with the system prompts.

There’s a really interesting detail, that the prompt injection attack only worked 1 out of 11 times. This sent me down an LLM rabbit hole, asking whether LLMs are deterministic, and if not, why not. The simple answer is the “temperature” control knob on LLMs add some random noise to the output text. There seems to be randomness even when the LLM temperature is turned to zero, caused either by floating point errors, or even a byproduct of doing batched inference. Regardless, prompt injection attacks may only work after several tries.

And that brings us to promptmap tool. It is intended to evaluate a system prompt, and launch multiple attempts to poison or otherwise inject malicious user prompts into the system. And of course, it is now capable of using the approach that successfully revealed [Utku]’s system prompt.

Cloudflare’s Unintentional GPS

There’s a really interesting unintended side effect of using Cloudflare’s CDN network: Users load data from the nearest datacenter. Unique data can be served to a target user, and then the cache can be checked to leak coarse location information. This is novel research, but ultimately not actually all that important from a security perspective. The primary reason is that the same sort of attack has always existed and can be used to extract a much more valuable piece of user identifying data: The user’s IP address.

The Unauthenticated, Unencrypted radios that control The German Power Grid

[Fabian Bräunlein] and [Luca Melette] were just looking for radio-controlled light switches, to pull off a modern take on Project Blinkenlights. What they found was the Radio Ripple Control protocol, an unauthenticated, unencrypted radio control protocol. That just happens to control about 40 Gigawatts of power generation across Germany, not to mention street lamps and other bits of hardware.

The worst-case scenario for an attacker is to turn on all of the devices that use grid power, while turning off all of the connected devices that generate power. Too much of an imbalance might even be capable of resulting in the dreaded grid-down scenario, where all the connected power generation facilities lose sync with each other, and everything has to be disconnected. Recovery from such a state would be slow and tedious. And thankfully not actually very likely. But even if this worst-case scenario isn’t very realistic, it’s still a severe vulnerability in how the German grid is managed. And fixes don’t seem to be coming any time soon.

Bits and Bytes

The Brave browser had a bit of a dishonest downloads issue, where the warning text about a download would show the URL from the referrer header. The danger is that a download may be considered trustworthy, even when it’s actually being served from an arbitrary URL.

If JavaScript in general or next.js in particular is in your security strike zone, you’ll want to check out the write-up from [Rachid.A] about cache poisoning in this particular framework, and the nice cache of security bounties it netted.

Zoom has a weird security disclosure for one of their Linux applications, and it contains a description I’ve never seen before: The bug “may allow an authorized user to conduct an escalation of privilege via network access.” Given the CVSS score of 8.8 with an attack vector of network, this should probably be called a Remote Code Execution vulnerability.

Subaru had a problem with STARLINK. No, not the satellite Internet provider, the other STARLINK. That’s Subaru’s vehicle technology platform that includes remote start and vehicle tracking features. That platform had a pair of flaws, the first allowing an attacker to reset any admin’s password. The second is that the Two Factor Authentication protection can be bypassed simply by hiding the pop-up element in the HTML DOM. Whoops! Subaru had the issues fixed in under 24 hours, which is impressive.

And finally, Silent Signal has the intriguing story of IBM’s i platform, and and a compatibility issue with Windows 11. That compatibility issue was Microsoft cracking down on apps sniffing Windows passwords. And yes, IBM i was grabbing Windows passwords and storing them in the Windows registry. What a trip.

When homebrewing a CPU, one has to deal with microcode. Microcode is the low-level nuts and bolts of how, precisely, a CPU executes instructions (like opcodes) and performs functions such as updating the cycle counter or handling interrupt requests. To make this task easier, [Bob Alexander] created a microcode compiler built in Google Sheets to help with his own homebrew work, but it’s flexible and configurable enough to be useful to others, as well.

A CPU’s microcode usually lives in read-only memory, and writing the microcode is only one step in the journey. [Bob]’s tool compiles his microcode into files that can be burned into memory (multiple EEPROM chips, in [Bob]’s case) or used as a Verilog program in the case of implementing the CPU in an FPGA. It’s configurable enough to be adapted for other homebrew CPU projects, though one would of course have to re-write the microcode portion.

A read-only version of the spreadsheet makes for some fun browsing, and if it piques your interest enough to get a copy of your own complete with the compiler script, you can do that here. It uses Google Sheets, and writes the output files into one’s Google Drive.

This kind of low-level project really highlights the finer points of just how the hard work of digital computing gets done. A good example is the Gigatron which implemented a RISC CPU using only microcode, memory, and logic gates in the late 70s. We’ve even seen custom microcode used to aid complex debugging.

Back in the last century, Intel saw itself faced with a need to have ‘second source’ suppliers of its 8088 and 8086 processors, which saw NEC being roped in to be one of those alternative suppliers to keep Intel’s customers happy with the μPD 8086 and μPD 8088 offerings. Yet rather than using the Intel provided design files, NEC reverse-engineered the Intel CPUs, which led to Intel suing NEC over copying the microcode that forms an integral part of the x86 architecture. In a recent The Chip Letter entry by [Babbage] this case is covered in detail.

Although this lawsuit was cleared up, and NEC licensed the microcode from Intel, this didn’t stop NEC from creating their 8086 and 8088 compatible CPUs in the form of the V30 and V20 respectively. Although these were pin- and ISA-compatible, the internal microcode was distinct from the Intel microcode due to the different internal microarchitecture. In addition the V20 and V30 also had a special 8080 mode, that provided partial compatibility with Z80 software.

Long story short, Intel sued NEC with accusations of copyright infringement of the microcode, which led to years of legal battle, which both set many precedents about what is copyrightable about microcode, and ultimately cleared NEC to keep selling the V20 and V30. Unfortunately by then the 1990s had already arrived, and sales of the NEC chips had not been brisk due to the legal issues while Intel’s new 80386 CPU had taken the market by storm. This left NEC’s x86-compatible CPUs legacy mostly in the form of legal precedents, instead of the technological achievements it had hoped for, and set the tone for the computer market of the 1990s.

Thanks to [Stephen Walters] for the tip.

The 8086 has been around since 1978, so it’s pretty well understood. As the namesake of the prevalent x86 architecture, it’s often studied by those looking to learn more about microprocessors in general. To this end, [Ken Shirriff] set about reverse engineering the 8086’s multiplication algorithm.

[Ken]’s efforts were achieved by using die photos of the 8086 chip. Taken under a microscope, they can be used to map out the various functional blocks of the microprocessor. The multiplication algorithm can be nutted out by looking at the arithmetic/logic unit, or ALU. However, it’s also important to understand the role that microcode plays, too. Even as far back as 1978, designers were using microcode to simplify the control logic used in microprocessors.

[Ken] breaks down his investigation into manageable chunks, exploring how the chip achieves both 8-bit and 16-bit multiplication in detail. He covers how the numbers make their way through various instructions and registers to come out with the right result in the end.

It’s a fun look at what’s going on at the ground level in a chip that’s been around since before the personal computer revolution. For any budding chip designers, it’s a great academic exercise to follow along at home. If you’ve been doing your own digging deep into CPU architectures, don’t hesitate to drop us a line!

The aptly-named [chip-red-pill] team is offering you a chance to go down the Intel rabbit hole. If you learned how to build CPUs back in the 1970s, you would learn that your instruction decoder would, for example, note a register to register move and then light up one register to write to a common bus and another register to read from the common bus. These days, it isn’t that simple. In addition to compiling to an underlying instruction set, processors rarely encode instructions in hardware anymore. Instead, each instruction has microcode that causes the right things to happen at the right time. But Intel encrypts their microcode. Of course, what can be encrypted can also be decrypted.

Using vulnerabilities, you can activate an undocumented debugging mode called red unlock. This allows a microcode dump and the decryption keys are inside. The team did a paper for OffensiveCon22 on this technique and you can see a video about it, below.

So far, the keys for Gemini Lake and Apollo Lake processors are available. That covers quite a number of processors. Of course, there are many more processors out there if you want to try your hand at a similar exploit.

This same team has done other exploits, such as executing arbitrary microcode inside an Atom CPU. If you want to play along, you might find this useful. You do know that your CPU has instructions it is keeping from you, don’t you?

Over on Hackaday.io, [Zoltan Pekic] has been busy building a stack of tools for assisting with verifying and debugging retro computing applications. He presents his take on using Intel hex files for customised in-circuit testing, which is based upon simple microcoded sequencers, which are generated automatically from a high level description.

The idea is that it is very useful to be able to use an FPGA development board to emulate the memory bus component of the CPU, allowing direct memory access for design validation purposes. This approach will also allow the production of a test rig to perform board level verification. The microcode compiler (MCC) generates all the VHDL, and support files needed to target a Xilinx FPGA based dev board, but is generic enough to enable targeting other platforms with a little adaptation.

Another interesting use case enables in-circuit tracing of buggy memory accesses, with the microcode sequencer decoding the accesses and dumping the relevant information out to either a serial port, or even direct to an embedded VGA controller, hardware allowing.

This automated approach to generating customisable microcoded hardware is a very nice trick to have in your bag, and even if it only helps in certain circumstances, [Zoltan] notes that it at least serves as an interesting example of the architecture of computers from history, if not much else.

Source for the example 8085 project can be found on the project GitHub, and the toolchain source can found here also.

For an interesting practical use of microding to implement emulations of historical hardware, checkout this neat switchable reproduction calculator project.