8271 floppy controller reverse engineer journey write-up

[scarybeasts]

Hi,

Here's a blog post describing the 8271 reverse engineering journey a few of us recently went on:

https://scarybeastsecurity.blogspot.com ... 1970s.html

Hope you enjoy reading it as much I enjoyed writing it and being part of the team that came together to crack this nut!


Cheers
Chris

[Diminished]

Well, that puts a big smile on my face.

Having seen the complexity of the chip, I must confess to a feeling of surprise every time my BBC Micro successfully loads a disc.

I read it through quickly, but I'm really looking forward to studying it more carefully.

Great work, Sir.

I'd still like to see the Beeb ULAs done some day! Presumably no code in those, though. :/

[lurkio]

Tremendous work, everyone, and a great write-up!

I have only the vaguest inkling of an understanding of what an amazing set of discoveries you've made, but I'm still massively impressed! Well done to all involved!

[Diminished]

At one point while this was going on I did have an 8271 set up on a breadboard, connected up to an LPC1788 microcontroller, in a vain hope that we might be able to steal some bus state through glitching. I regret not taking a photo of that. It's all packed away again now.

There is a memorable quote from Steve Furber about the development of the ARM 1, something like, "Acorn gave us two things that Intel and Motorola had never given their design teams: They gave us no money, and they gave us no people." When I first heard this, I chuckled and nodded sagely, but this aphorism has taken on a deeper meaning for me now I have seen first-hand the crazy over-engineering exhibited in the design of the 8271. Furber really wasn't kidding.

Intel actually did us a big favour in one specific way: The fact that the program ROM's row decoder had 108 rows. It was guesser who first noticed that the row decoder operated on a predictable, traditional, in-order binary count, but we couldn't be sure of the bit ordering of the address lines that fed that decoder. Having a number of rows that wasn't a power-of-two gave the game away, though, because it meant there was really only one bit ordering that made sense; any other choice would have regions in the address space that would overflow the ROM. The fact that I traced the bus lines to lots of other components, and that all of them seemed to connect to the bus in an order consistent with their layout, was the remaining clue we needed that guesser's ROM dump was correctly ordered.

We also tangentially found that the disc-eating test mode is only peckish if no 8271 commands have been executed after power-on. If Acorn had written the MOS and DFS in such a way that just one 8271 command was sent during machine initialisation, none of this would have ever happened. I will submit an advisory to Acorn suggesting that it would be a good idea to execute some sort of null 8271 command during machine initialisation. Might be worth a CVE, too.

I kept meaning to ask about the provenance of the test mode. All that work, and it was never found! Dear me.

[BigEd]

Great stuff - great adventure and a great write up. Thanks for sharing!

[scarybeasts]

We also tangentially found that the disc-eating test mode is only peckish if no 8271 commands have been executed after power-on.

This doesn't match my machine. I just did *. with a disc in drive 0. Then ?&FE82=4 and... awful noises as usual. Actually I have a new favorite drive and it makes a different type of awful noise. Very interesting.

Of course, I forgot about having my Gotek + FlashFloppy there as drive 1 it was _not_ happy on its LCD display. By some miracle, the mounted DSD seems ok stiil. Need to *VERIFY it but scared to do so.


Cheers
Chris

[Diminished]

This doesn't match my machine. I just did *. with a disc in drive 0. Then ?&FE82=4 and... awful noises as usual. Actually I have a new favorite drive and it makes a different type of awful noise. Very interesting.

Of course, I forgot about having my Gotek + FlashFloppy there as drive 1 it was _not_ happy on its LCD display. By some miracle, the mounted DSD seems ok stiil. Need to *VERIFY it but scared to do so.

Oh dear. That was an unexpectedly successful piece of accidental social engineering. Mitnick would be proud.

Seriously, though, that's really strange. IIRC I tried it multiple times and it only worked immediately after power-on, and I'm sure someone else reported the same behaviour. I'll be sure to try it again next time I'm in front of hardware. I have three 8271s, too, so I might try it with all of them.

Ah, well. Back to something less glamorous.

[KenLowe]

Excellent write up .

A lot to take in there!

[scarybeasts]

Seriously, though, that's really strange. IIRC I tried it multiple times and it only worked immediately after power-on, and I'm sure someone else reported the same behaviour. I'll be sure to try it again next time I'm in front of hardware. I have three 8271s, too, so I might try it with all of them.

What's interesting is that if you power up to the "Acorn DFS" prompt, DFS has initialized and in the process (DFS 0.9) issued 3x SPECIFY and 1x WRITE SPECIAL REGISTER command[*]. These commands could be considered "simple" I suppose.


Cheers
Chris

[*] As per beebjit -log disc:commands

[JasonStonier]

Incredible journey, and a great writeup. I really get how exciting this journey was for the team - it's archaeology of the purest kind and the depth of insight and intellect is worthy of the greatest respect.

[shakesc]

Its a great write up, enjoyed reading that

[Diminished]

So I read it all again, more carefully this time.

The question of arbitrary code execution is one I had also been wondering about. With a hardcoded program ROM and no real RAM it was never going to be terribly easy, but gaining some control over the stack might at least have provided some ROP-style gadgetry options. But I suppose the lack of stack manipulation opcodes shoots this idea down, too. There could have been a whole new dimension of ROP fun with the whole event handler architecture waiting in the wings. Perhaps something could be done if you somehow tampered with it electronically, but I guess that's not likely to be possible in the Beeb context without a hardware mod.

What is great, though, is how you turned the 8271's unique strengths into a weakness for the purposes of writing illegal bitstreams. Starting a track write for twice the circumference of the disc, and then triggering parallel jobs on the second revolution to mess about with the registers of the running operation is hilarious. You add multitasking to your silicon, you'd better expect a whole new class of attacks against it!

Silly Intel!

[Richard Russell]

Post off-topic. Deleted by author.

[Diminished]

I guess I never discussed why I got interested in this in the first place.

Well, I built this piece of junk, and it obviously required spending some time staring at the 8271 'sheet in the process.

I also became aware (since BeebMaster managed to stockpile some) that spare 8271s were becoming very thin on the ground, so at the time of working on the above, I started wondering about the possibility of producing an 8271 clone based on a microcontroller. (The Beeb ULAs are the other component that are really begging for a clone, which is why I was keen on getting decaps of those, too, but that's another discussion.)

I am sure it can be done, but how? (In some ways, this reverse engineering victory has made it harder!)

For the byte processor, it seems like there are two options -- either write some microcontroller code that accurately does the same job as the code in the 8271 (similar to beebjit's 8271 driver?), or just go the whole hog, write an emulator for the byte processor, and actually execute the real code from the ROM on a microcontroller. Can the latter be done fast enough?

The (cloned) bit processor also has a bit of work to do, needing to both write and read bitstreams at the drive's data rate, and also perform things like CRC calculation. This could perhaps be managed by a microcontroller too, but could that functionality be integrated into whatever chip was used for the byte processor (potentially compromising the byte processor's timing) or would it be a safer idea to base a clone on a genuine dual-core, two-microcontroller design like Intel's, in which the two cores cannot interfere with one another's timing integrity? Or maybe even not use a microcontroller for the I/O portion, and do it in logic?

However you slice it, Chris's The Sentinel effort has certainly produced a punishing test case that would have to function correctly for the project really to be a success.

Thinking about all the subtleties in the timing you'd need to produce a working clone that could be plugged into a Beeb makes my brain hurt. At least you could ignore the DMA functionality...

Maybe something to think about.

[cmorley]

A bottom of the range $1 STM32G0 or STM32F0 (Cortex M0) running at 48MHz with it's hardware CRC unit and DMA would crush running a 8271 VM. The only thing you might need is $1 of logic/CPLD to do the computer bus interface because the STM32 couldn't bit bash that.

Kudos for the reverse engineering and write up BTW!

[Coeus]

I am sure it can be done, but how? (In some ways, this reverse engineering victory has made it harder!)

That depends on how much of a purist you want to be and what the end goal is. Is the intention is to be able to run software, including copy-protected software, written for the BBC micro? There is a view that emulating a piece of hardware as accurately as possible is the best insurance against finding programs that rely on doing something weird and undocumented but things this reverse engineering has exposed would not have been known by software writers in the 1908s and therefore would not have been relied upon.

But if you want to run Chris's modern curiosities then obviously that's different.

[guesser]

Clearly the solution is to finish reverse engineering it down to the gate level and re-implement it exactly the same in a large CPLD

[BigEd]

I know you're joking, but the size of this thing is really quite surprising. From the writeup:

22,000 transistors!! We knew this was a bit of a chonker, but for reference, the 6502 has 3,218 transistors

Now, Arlet has implemented a 6502 on four CPLDs (with great care and attention) so all things being equal, which is never the case, we should budget about 28 CPLDs for the 8271. It really is a chonker.

[Diminished]

28 CPLDs

I thought a little more about this.

Just in the interests of having a working example, I dug out the code from the Disc Toaster which writes out the bitstream to the drive. There are two tight busy-wait loops in here which loop round 21 times in between sending bits to the drive:

Code: Select all

.set V_FDD_118,                     21

  mov     r5,  #V_FDD_118
.P_fdd_write_track_wait_1:  @ wait
  subs    r5,  r5,  #1
  bne     .P_fdd_write_track_wait_1

This gives an idea of the amount of time that you have available for "other activities" (e.g. servicing the byte processor) while the thing is performing a drive operation. The 'Toaster is an ARM7TDMI running at 50 MHz. It's very back-of-envelope stuff but it seems like at this clock speed you might have dozens of cycles to play with, rather than hundreds. This is for writes; because the drive spindle speed can't be guaranteed, my gut feeling is that perhaps you'd want to sample reads at twice the bitcell rate. Particularly if you were going to implement the byte processor by executing the real ROM code, you might want to go for a 100 MHz device. I dunno.

How to generate the clock? You'd probably need it to run synchronously with the 4 MHz clock the Beeb supplies to the 8271. I don't know the capability of your average PLL on your average microcontroller, but this is perhaps another argument for targeting 100 MHz, since you can do 4 MHz x 25 to get 100 MHz (50 MHz would require a 12.5x multiplier). x25 might be outside the capability of your average PLL on your average microcontroller, so maybe you'd need an external PLL in between the Beeb and the μC?

Regarding separating the two simulated cores, one approach might be to set a timer for the drive's bitcell speed (or maybe twice that?) and execute all the bit processor code in interrupt context. All the byte processor stuff would be done in userspace. The constant IRQs would jitter the timing of byte processor operations; I have no idea if that is going to matter or not.

The alternative would be to write the byte processor code in a real-time style, splitting it into short, carefully-timed routines, dispatching them from some sort of state machine, and calling the state machine constantly between bits in the bit processor code (effectively using the byte processor as the busy-wait for the bit processor). This seems like it would be very painful to write, but this way you could do the whole thing in userspace with predictable timing -- but still not necessarily compatible timing.

[BigEd]

Something which would worry me: a sector header, and a sector, don't have a synchronised bit clock with what came before, so you get rather little time to sync up in the run-in. I'm not sure how you get a PLL to do that. Or indeed, how you do it at all!

[Diminished]

Something which would worry me: a sector header, and a sector, don't have a synchronised bit clock with what came before, so you get rather little time to sync up in the run-in. I'm not sure how you get a PLL to do that. Or indeed, how you do it at all!

I hadn't thought about this.

I guess you'd just have to hideously oversample the bitstream, but that wouldn't leave time for anything else!

Dual-core might be necessary in that case.

[cmorley]

Microcontrollers have a large variety of timers, universal serial trancievers, DMA and other peripherals to solve these kind of problems. USARTs already do the oversampling for you. You can DMA counter values triggered by transitions which means you get a block of memory filling up with periods or half periods. The ST timer guide/manual is hundreds of pages, these things are very powerful because of their peripherals.

[Diminished]

Microcontrollers have a large variety of timers, universal serial trancievers, DMA and other peripherals to solve these kind of problems. USARTs already do the oversampling for you. You can DMA counter values triggered by transitions which means you get a block of memory filling up with periods or half periods. The ST timer guide/manual is hundreds of pages, these things are very powerful because of their peripherals.

Hmm. This does sound promising.

At any rate, it sounds like one would maybe want to tackle the bit processor first and try to get that working, before moving on to the byte processor.

I'm sure there are lots of floppy drive controller projects already kicking around in the retrocomputing world, so it might be possible to steal a fair portion of the bit processor code.

[Diminished]

bam

https://hackaday.com/2020/11/22/intels- ... processor/