At 19:52 04/01/2006 +0000, you wrote: >Doron suggested that S12X might solve the problem. Can anyone say if >you can use external i/o on S12X when secured? Let be more accurate here: I said that the S12X external bus is much more robust and convenient to use compared to the HCS12 external bus (much better and easier to meet bus-timing, voltage levels compatible with memory devices, and no need for any glue logic to interface to external memory). Regarding security, the S12X does have similar implementation as the HCS12 - it automatically disables the internal Flash when the part is secured and operates in Expanded mode. So the answer to your specific question is: No, the S12X does not resolve this particular problem. Hope this helps, Doron Nohau HC12 In-Circuit Emulators www.nohau.com/emul12pc.html

--- In 68HC12@68HC..., "Oliver Betz" <list_ob@g...> wrote: > it could be forced also by applying illegal signals to mcu pins, e.g. > short clock or reset pulses, over-/undervoltage... > > Only a "no execute" hardware for external memory would be safe. > > Oliver Doron suggested that S12X might solve the problem. Can anyone say if you can use external i/o on S12X when secured?

"Jefferson Smith" <imajeff84663@imaj...> wrote: [...] > > FLASH, then unless you have a programming error it would never try > > "programming error" is the real reason, as I understand it, why they it could be forced also by applying illegal signals to mcu pins, e.g. short clock or reset pulses, over-/undervoltage... Only a "no execute" hardware for external memory would be safe. Oliver -- Oliver Betz, Muenchen

--- In 68HC12@68HC..., Zoltán Kócsi <zoltan@b...> wrote: > Considering that the bus interface sits between the internal bus and > the external bus, it is not necessarily an illusion. The bus Actually your explanation makes more sense to me than mine, but it doesn't seem to solve the real problem of why it's not possible. > FLASH, then unless you have a programming error it would never try "programming error" is the real reason, as I understand it, why they don't enable it. And of course, they are not trying to compete with cheaper MCU, but claim to be better than them. So what I've heard was that there were ways discovered after production that induced errors, toggled specific (or even random) bits, etc. which allowed the hackers to gain control. That is what Freescale was trying to avoid. I think the best idea, however, is being able to allow data accesses and not program fetch while secured, except I don't know what that would involve.

--- In 68HC12@68HC..., "Michael Huslig" <mhuslig@k...> wrote: > > Doron, > > If the programmer of a secured normal single-chip application never > references external memory, how can a hacker inject some data? I see Doron is looking at a different issue in that case. If the hacker can begin execution by starting up in expanded mode. Of cours you are not suggesting that be possible. Doron hasn't at all addressed you latest explanation how the bus would only be used for data. Doron, you've got to think outside the box :) Personally, I think if they did design some easy way to allow enabling the external bus, then there would be more easy ways you don't know about to force it into executing code. Then, the best way is if there was an extra limitation implementation while secured, suggested by Zoltan, that the bus did not physically allow instruction fetches from the external bus. I guess I haven't thought enough before about the difference between program fetch and data fetch. I think Freescale just hasn't though enough about it either. Then my only fear is how much it would cost to get them to think about it.

At 14:40 03/01/2006 -0600, you wrote: >If the programmer of a secured normal single-chip application never >references external memory, how can a hacker inject some data? Reset the CPU into Normal Expanded Wide mode, and hold the PK7/ROMONE pin low during Reset, to have the internal Flash disabled out of Reset and execute out of external memory. Then right after Reset, code is executed from external memory, executing the hackers code. The next step is for the hacker code to jump to address 0x4000 for example then write 0x0F to the MISC register to enable the internal Flash in the 0x8000 - 0xFFFF window. From there, it simply spits out he internal Flash and EEPROM content to the external bus. Luckily, the above is all theoretical, as the internal Flash is permanently disabled when the part is secured and executes in expanded mode. I agree that with more design details it would have been possible to allow internal Flash, expanded mode and security to be enabled together simultaneously. This would however be more complex than current implementation, and possibly more vulnerable to security hackers. The current Freescale implementation is simple, which makes it very effective. You need to realize that expanded mode on HCS12 have been arranged by Freescale mainly to allow in-circuit emulators. Expanded mode was really not expected by Freescale to be used in other field applications, and Freescale would most likely have eliminated the external but on HCS12 parts altogether unless the need for in-circuit emulators. (it increases the complexity of the logic, and slightly increases the price of the silicon). On the S12X the situation is very different regarding external bus. The S12X is the first HC12 part (since the old 68HC812A4) that was designed to seriously consider external bus users. Still, the vast majority of S12X users use Single-Chip mode, but the bus design has been altered and improved immensely to allow easy and convenient expanded mode use as well (correct voltage levels for interfacing to external memory devices, proper easy to meet bus timing, and possibility to interface directly to external memory with no need of any external glue logic). Hope this helps, Doron Nohau HC12 In-Circuit Emulators www.nohau.com/emul12pc.html

Doron, If the programmer of a secured normal single-chip application never references external memory, how can a hacker inject some data? If the programmer of a secured expanded application is careful and only puts "data", like A/D records etc, and does not put program vectors in external memory, how can a hacker get in? Freescale is using 2 bits to signify secured Flash. Maybe the 2nd bit can be used to allow external "data" references. This would at least allow someone to try and protect their Flash program when the "data" doesn't need protection. Mike ----- Original Message ----- From: "Doron Fael" <doronf@doro...> To: <68HC12@68HC...> Sent: Tuesday, January 03, 2006 2:01 PM Subject: Re: [68HC12] Re: MC9S12DG256 secure mode and external bus > Mike, > > The proper way to look at this matter is through the eyes of a potential > hacker. > > Let's assume a Nomal Single-Chip application that uses a secured HCS12 > MCU. > > With your suggestion a hacker could de-solder the secured MCU, and mount > it > on another target that would bring it in external mode, then inject some > data through the external bus that would affect the execution and somehow > cause the execution to be passed to the external bus, so the internal > Flash > content can be read externally, and the security would thus be defeated... > > Since more than 95% of HCS12 applications use Single-Chip mode, this is > the > main focus and concern, and therefore Freescale correctly did not give a > window for hackers to defeat security using external mode. > > Doron > Nohau > HC12 In-Circuit Emulators > www.nohau.com/emul12pc.html > > At 11:38 03/01/2006 -0600, you wrote: >>It seems to me, if the uP is secure, any code on the external bus can only >>be executed if the secure code calls it. If the external bus only has >>data >>or peripherals, and the programmer has faith that his secured code will >>not >>try to execute from the external bus, then access should be allowed. The >>uP >>should have been designed so that it would just not execute code in >>external >>memory if it is secured. >> >>Mike >> >>----- Original Message ----- >>From: "Jefferson Smith" <imajeff84663@imaj...> >>To: <68HC12@68HC...> >>Sent: Tuesday, January 03, 2006 10:40 AM >>Subject: [68HC12] Re: MC9S12DG256 secure mode and external bus >> >> >> > --- In 68HC12@68HC..., "sglow2000" <sglow@e...> wrote: >> > >> >> It really seems >> >> like a poor design decision on the part of >> >> Motorola to prevent the use >> >> of the external bus when running in secure mode. It would seen >> >> perfectly reasonable and safe too allow booting the chip from >> >> the internal flash, and allowing the external bus to be used for >> >> data/peripherial access. >> > >> > Woa, maybe you are under the illusion that data on the bus is separate >> > from program execution. Maybe that's possible in MCU design, but I >> > think far from a capability in this design. >> > >> > In other words, any enabling of the external bus enables execution of >> > external code. That would nullify the the "security". >> > >> > There are many architectures which would be more suitable to design >> > that limitation, but I'm glad a simpler architecture as this one still >> > exists. > > > Yahoo! Groups Links >

Mike, The proper way to look at this matter is through the eyes of a potential hacker. Let's assume a Nomal Single-Chip application that uses a secured HCS12 MCU. With your suggestion a hacker could de-solder the secured MCU, and mount it on another target that would bring it in external mode, then inject some data through the external bus that would affect the execution and somehow cause the execution to be passed to the external bus, so the internal Flash content can be read externally, and the security would thus be defeated... Since more than 95% of HCS12 applications use Single-Chip mode, this is the main focus and concern, and therefore Freescale correctly did not give a window for hackers to defeat security using external mode. Doron Nohau HC12 In-Circuit Emulators www.nohau.com/emul12pc.html At 11:38 03/01/2006 -0600, you wrote: >It seems to me, if the uP is secure, any code on the external bus can only >be executed if the secure code calls it. If the external bus only has data >or peripherals, and the programmer has faith that his secured code will not >try to execute from the external bus, then access should be allowed. The uP >should have been designed so that it would just not execute code in external >memory if it is secured. > >Mike > >----- Original Message ----- >From: "Jefferson Smith" <imajeff84663@imaj...> >To: <68HC12@68HC...> >Sent: Tuesday, January 03, 2006 10:40 AM >Subject: [68HC12] Re: MC9S12DG256 secure mode and external bus > > --- In 68HC12@68HC..., "sglow2000" <sglow@e...> wrote: > > > >> It really seems > >> like a poor design decision on the part of > >> Motorola to prevent the use > >> of the external bus when running in secure mode. It would seen > >> perfectly reasonable and safe too allow booting the chip from > >> the internal flash, and allowing the external bus to be used for > >> data/peripherial access. > > > > Woa, maybe you are under the illusion that data on the bus is separate > > from program execution. Maybe that's possible in MCU design, but I > > think far from a capability in this design. > > > > In other words, any enabling of the external bus enables execution of > > external code. That would nullify the the "security". > > > > There are many architectures which would be more suitable to design > > that limitation, but I'm glad a simpler architecture as this one still > > exists.

> Woa, maybe you are under the illusion that data on the bus is separate > from program execution. Maybe that's possible in MCU design, but I > think far from a capability in this design. Considering that the bus interface sits between the internal bus and the external bus, it is not necessarily an illusion. The bus controller knows very well if it is fetching opcodes or data. If the bus controller is capable of doing all the transformations needed for the wide and narrow bus configurations, the handling of misaligned access for the internal 16-bit bus in a single clock and so on, causing an exception if code execution is attempted when the effective address selects an external element would cost very little hardware. > In other words, any enabling of the external bus enables execution of > external code. That would nullify the the "security". No, it would not. If the CPU boots from the FLASH and runs from the FLASH, then unless you have a programming error it would never try to fetch instructions from any address other than the FLASH. It *could* execute external code but since the code in the FLASH never tries to jump into a non-FLASH area, it would never do. Snooping the bus would not be harmful either, because if the SW doesn't allow visible internal cycles, the bus is not showing you what's happening internally. The security risk of an enabled external bus is similar to the security risk of enabling the CAN controller: a cleverly formatted CAN message, when executed in the CAN receive buffer as code can be used to suck the FLASH content out. Enabling the external bus would not force the CPU to execute arbitrary code at arbitrary locations any more than the CAN controller can force the CPU execute code in its receive buffer. > There are many architectures which would be more suitable to design > that limitation, but I'm glad a simpler architecture as this one still > exists. It is not an architectural simplification issue, it is a design decision issue. There *are* processors simpler than the HC12 that enable external bus while protecting the FLASH. It seems that the designers decided that the only reason to turn on the external bus is to execute code from an outside source and they designed the chip's security model accordingly. Unfortunately, this is not the case, more often you just want to access an external peripheral unit or some extra data RAM. Enabling the external bus would not jeopardise the security of your code in the FLASH, executing external code would. The two are not the same, but the chip treats them as if they were. Zoltan