Reply by Steve Calfee July 14, 20052005-07-14
On Thu, 14 Jul 2005 14:16:46 +0200, Alexander Becher
<abecher@i4.informatik.rwth-aachen.de> wrote:

>I wrote: >> I am facing the following situation: I have a microcontroller (e.g. >> Atmel ATmega 128 or TI MSP430) connected via SPI to a flash memory >> chip (e.g. Atmel AT45DB014B or ST M25P80). I'd very much like to >> enable a second microcontroller to access the flash memory. >> >> The central question in this regard is: Can I add this second >> microcontroller to the bus without changing the software on the first >> microcontroller or the wiring to it? Or do I need some support for >> this configuration in the first uC? > >Many thanks to everyone who replied so far. I'll try to give some more >background on the scenario. > >This work is part of a security analysis of an existing product. >Therefore, the software on the 1st uC is fixed. The wiring can only be >changed by tampering with the product while it is fielded, e.g. by >using a soldering iron and assorted accessories. At the same time, the >2nd uC used to carry out the attack is not limited to any particular >class of products and might even be a laptop computer. > >If I were designing a new product, it would certainly be easy to go for >a different bus system with true multi-master capability, or >alternatively to implement some software handshake between the two uCs. > >However, in this scenario, this is not possible. From what I've gathered >from the replies, I see three options: > >(a) Emulate the bus in the second uC. Connect the 1st uC to the second >uC instead of the SPI bus, and make the 2nd uC a slave on the SPI >connection to the 1st uC and a master on the bus to the flash. > >The advantage of this approach is that operation of the 1st uC would not >be interrupted, except for some timing delays due to the emulation. > >The disadvantage is that the wiring still needs to be changed, if I >understood correctly, and that the emulation needs to be written in the >first place. Also, the flash is not the only device on the SPI bus (the >lines are shared with an RF transceiver), which would make this even >more complicated. > >(b) Power down the 1st uC or keep it in reset state while the 2nd uC is >accessing the bus. > >Advantage: Simple software for 2nd uC. > >Disadvantage: Regular operation is interrupted. If at all possible, I >would like to avoid this, as this might lead to detection of the >attack. > >(c) Use a tri-state buffer on the SPI pins of the 1st uC. > >Advantage: 1st uC can be disconnected by the 2nd uC without resetting >it, meaning that the interruption will probably not be noticed unless >the 1st uC tries to access the SPI bus while it is disconnected. > >Disadvantage: Still needs a change in the wiring. > >If anybody still has comments, I'd be glad to hear them. > >Regards >Alexander Becher
Well, you could use a SPI bus analyzer and sniff the SPI bus. This would allow you to see everything read or written by the master, without it knowing you are watching. This would not allow you to write to anything on the SPI bus, or read anything the master did not read. In this senario you are just a passive wiretap. This can be very helpful in debugging a SPI bus, I don't know if it will help with your app. Regards ~Steve There is no "x" in my email address.
Reply by Alexander Becher July 14, 20052005-07-14
I wrote:
> I am facing the following situation: I have a microcontroller (e.g. > Atmel ATmega 128 or TI MSP430) connected via SPI to a flash memory > chip (e.g. Atmel AT45DB014B or ST M25P80). I'd very much like to > enable a second microcontroller to access the flash memory. > > The central question in this regard is: Can I add this second > microcontroller to the bus without changing the software on the first > microcontroller or the wiring to it? Or do I need some support for > this configuration in the first uC?
Many thanks to everyone who replied so far. I'll try to give some more background on the scenario. This work is part of a security analysis of an existing product. Therefore, the software on the 1st uC is fixed. The wiring can only be changed by tampering with the product while it is fielded, e.g. by using a soldering iron and assorted accessories. At the same time, the 2nd uC used to carry out the attack is not limited to any particular class of products and might even be a laptop computer. If I were designing a new product, it would certainly be easy to go for a different bus system with true multi-master capability, or alternatively to implement some software handshake between the two uCs. However, in this scenario, this is not possible. From what I've gathered from the replies, I see three options: (a) Emulate the bus in the second uC. Connect the 1st uC to the second uC instead of the SPI bus, and make the 2nd uC a slave on the SPI connection to the 1st uC and a master on the bus to the flash. The advantage of this approach is that operation of the 1st uC would not be interrupted, except for some timing delays due to the emulation. The disadvantage is that the wiring still needs to be changed, if I understood correctly, and that the emulation needs to be written in the first place. Also, the flash is not the only device on the SPI bus (the lines are shared with an RF transceiver), which would make this even more complicated. (b) Power down the 1st uC or keep it in reset state while the 2nd uC is accessing the bus. Advantage: Simple software for 2nd uC. Disadvantage: Regular operation is interrupted. If at all possible, I would like to avoid this, as this might lead to detection of the attack. (c) Use a tri-state buffer on the SPI pins of the 1st uC. Advantage: 1st uC can be disconnected by the 2nd uC without resetting it, meaning that the interruption will probably not be noticed unless the 1st uC tries to access the SPI bus while it is disconnected. Disadvantage: Still needs a change in the wiring. If anybody still has comments, I'd be glad to hear them. Regards Alexander Becher
Reply by Rob Turk July 9, 20052005-07-09
"Thomas Magma" <somewhere@overtherainbow.com> wrote in message 
news:QJxze.1906260$6l.386874@pd7tw2no...
> > 2) The second micro would control the tri-state of the first and take > control of the SPI. It depends on his specific application whether this > would be a viable solution. >
Not a good approach. If the second controller tri-states the signal lines while the first controller has an operation in progress then you'd end up with 'unpredictable results' at best. I would go for one of these approaches: 1. If the first controller doesn't need to run all the time, tie the second controller to the reset line of the first controller. When the second controller wants access, place the first controller in reset state. Most controllers will place their outputs in Hi-Z mode when in reset state. 2. Make changes to the first controller hardware/software. Tie an 'access request' line from the second controller to an input of the first controller. When the first controller thinks it's safe, have it tri-state it's SPI lines and signal 'access granted' to the second controller via another line. Full handshake, and entirely safe. Rob
Reply by Thomas Magma July 8, 20052005-07-08
Kinda a slim chance this one will work for you, but if both micros don't 
need to be running at the same time, some micros will high Z their pins when 
powered down. Have the second micro control power to the first, then it can 
safely access the SPI bus, and then software high Z it's pins when the first 
micro is running.

Just a crazy thought.

Thomas

"Alexander Becher" <abecher@i4.informatik.rwth-aachen.de> wrote in message 
news:3j7ggvFng6c5U1@news.dfncis.de...
> Hello everyone, > > I am facing the following situation: I have a microcontroller (e.g. > Atmel ATmega 128 or TI MSP430) connected via SPI to a flash memory chip > (e.g. Atmel AT45DB014B or ST M25P80). I'd very much like to enable a > second microcontroller to access the flash memory. > > The central question in this regard is: Can I add this second > microcontroller to the bus without changing the software on the first > microcontroller or the wiring to it? Or do I need some support for this > configuration in the first uC? > > Obviously, I used Google with the wrong search terms, so I'm trying my > luck here. I'd appreciate any replies. > > Regards > Alexander Becher >
Reply by Jim Granville July 8, 20052005-07-08
Alexander Becher wrote:
> Hello everyone, > > I am facing the following situation: I have a microcontroller (e.g. > Atmel ATmega 128 or TI MSP430) connected via SPI to a flash memory chip > (e.g. Atmel AT45DB014B or ST M25P80). I'd very much like to enable a > second microcontroller to access the flash memory. > > The central question in this regard is: Can I add this second > microcontroller to the bus without changing the software on the first > microcontroller or the wiring to it? Or do I need some support for this > configuration in the first uC? > > Obviously, I used Google with the wrong search terms, so I'm trying my > luck here. I'd appreciate any replies.
When you say access, do you mean Read and Write ? It will be much easier if you can add support in the first uC - SPI is not multi-master, so to simply OR-WIRE the bus, requires handshake between the controllers. Your-turn/My-turn stuff, and that should include write-time allowances. One side effect of this sharing, is that it is still just possible a write/read will fail, so the firmware should include verify/retry. If you had a system where the original was in ROM, then it is still possible: One way is to create a virtual Flash device, that to the original looks like the genuine article, but is actually your other uC, and now it handles in SW the hand-over to the physical device. This will restrict your second uC choice, as most small uC's have rather poor SPI Slave operation on multi-byte streams - or, you could use a CPLD to assist. -jg
Reply by Grant Edwards July 8, 20052005-07-08
On 2005-07-08, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:
> Grant Edwards <grante@visi.com> wrote: >> On 2005-07-08, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote: > >> Perhaps he's trying to avoid forking the firmware that runs in >> the old processor. > > If forking the hardware is always easier than forking the > software,
But nobody said that. My reading of the OP was that forking the hardware is a given: the new product has to have a new board. Now the choice is does the new product require forking the old firmware or not. Assuming the old product must remain supported, it would be nice if the old firmware worked in both products.
>> If the old processor tries to use the SPI bus while it's >> disconnected let's hope the error handling in the old SW is up >> to snuff. > > Given that the error symptoms this would cause to the disabled > master are stricly in the "this cannot ever, possibly happen" > category, odds are it's not.
I expect you're right. The chances of the firmware for the old processor being able to tolerate being arbitrarily disconnected from the SPI bus at any point are pretty close to zero. At a minimum he'll have to connect the old/new processors together with a couple pins so that they can negotiate over bus ownership. -- Grant Edwards grante Yow! You should all JUMP at UP AND DOWN for TWO HOURS visi.com while I decide on a NEW CAREER!!
Reply by Hans-Bernhard Broeker July 8, 20052005-07-08
Grant Edwards <grante@visi.com> wrote:
> On 2005-07-08, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:
> Perhaps he's trying to avoid forking the firmware that runs in > the old processor.
If forking the hardware is always easier than forking the software, then either the CMS is braindead, or somebody thought it wasn't necessary to apply it to hardware, too, which I count as "using it very badly".
> If the old processor tries to use the SPI bus while it's > disconnected let's hope the error handling in the old SW is up to > snuff.
Given that the error symptoms this would cause to the disabled master are stricly in the "this cannot ever, possibly happen" category, odds are it's not. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
Reply by Thomas Magma July 8, 20052005-07-08
"Hans-Bernhard Broeker" <broeker@physik.rwth-aachen.de> wrote in message 
news:3j7malFokhtlU3@news.dfncis.de...
> Thomas Magma <somewhere@overtherainbow.com> wrote: >> Seems to me that you would have to high z the SPI interface on the >> original >> micro. You could do this in hardware with a tri-state buffer but this >> means >> changing the wiring, which is what you asked to avoid. However there are >> huge advantages to not changing the original software, based one how your >> company handles software control and documentation. > > Two comments: > > 1) If getting a software change filed into the configuration > management system is noticably harder than getting a hardware change > filed, then I would tend to claim you have a seriously broken CMS on > your hands (or you're using it very badly). > > 2) A hardware change alone almost certainly wouldn't help, anyway: > only the software will be in a position to know when to high-z those > pins. > > -- > Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) > Even if all the snow were burnt, ashes would remain.
Two comments. 1) DO-178A or equivalent. 2) The second micro would control the tri-state of the first and take control of the SPI. It depends on his specific application whether this would be a viable solution. I was just providing possible solutions to help in the thought process. Without knowing his specific application or hardware or the engineering quality procedures of his company, it's impossible to suggest the most effective method of implementation. Thomas
Reply by Hans-Bernhard Broeker July 8, 20052005-07-08
Alexander Becher <abecher@i4.informatik.rwth-aachen.de> wrote:

> I am facing the following situation: I have a microcontroller (e.g. > Atmel ATmega 128 or TI MSP430) connected via SPI to a flash memory chip > (e.g. Atmel AT45DB014B or ST M25P80). I'd very much like to enable a > second microcontroller to access the flash memory.
Plugging multi-master capability into an existing bus system that isn't designed to support them is quite certainly impossible without change to existing masters. Think about it: how would your existing master know that it may not touch the bus while the second one is using it, if its designer never had reason to believe that such a thing might happen? The thing's called the "master" because it owns the bus, and may do with it whatever it wants, any time it wants. There's no way you're going to break it out of that attitude without breaking its package. Therefore I suspect your best bet would be to seriously re-think the goal: why do you want to do this, and what completely different ways might exist to do it? Second-best, implement a protocol on top of SPI to let the masters hand over ownership of the bus from one to the other. Token-passing or regular "do you need the bus?" queries from the current master to the dormant one would be among the obvious choices. For this to work, the masters also have to be able to act as SPI slaves. Otherwise, you'll need physical intervention, i.e. the "ueber-master" could have direct control over parts of the hardware of the secondary master, so it can disable its transmitters or even disconnect it from the lines completely. Or just forget about SPI and use a protocol that's actually designed for multi-master applications. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
Reply by Grant Edwards July 8, 20052005-07-08
On 2005-07-08, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:
> Thomas Magma <somewhere@overtherainbow.com> wrote:
>> Seems to me that you would have to high z the SPI interface on >> the original micro. You could do this in hardware with a >> tri-state buffer but this means changing the wiring, which is >> what you asked to avoid. However there are huge advantages to >> not changing the original software, based one how your >> company handles software control and documentation. > > Two comments: > > 1) If getting a software change filed into the configuration > management system is noticably harder than getting a hardware > change filed, then I would tend to claim you have a seriously > broken CMS on your hands (or you're using it very badly).
Perhaps he's trying to avoid forking the firmware that runs in the old processor.
> 2) A hardware change alone almost certainly wouldn't help, > anyway: only the software will be in a position to know when > to high-z those pins.
Unless you gave the new processor control over the old processor's buffers. The new processor could then "disconnect" the old one. If the old processor tries to use the SPI bus while it's disconnected let's hope the error handling in the old SW is up to snuff. -- Grant Edwards grante Yow! Just imagine you're at entering a state-of-the-art visi.com CAR WASH!!