I have a project for which I'm planning to use the MC9S12DG256
processor running from internal flash, and would also like to use the
external bus to access RAM and peripherials.
I read something in one of the documents for this processor which
suggested that if I was running in secure mode (locked flash), then I
couldn't access the external bus at all.
This doesn't seem to make much sense, so I'm assuming that I just
misunderstood.
Has anyone booted one of these processors in single chip mode (i.e.
boot from internal flash), but still managed to access the external
bus? Does this still work in secure mode?
Thanks for any assistance.
Rgds,
Steve
MC9S12DG256 secure mode and external bus
Started by ●December 31, 2005
Reply by ●January 2, 20062006-01-02
Steve,
Actually, when the MC9S12DG256 operates in expanded mode, and the Flash is
secured, the Flash indeed cannot be accessed. This is in order to protect
against de-soldering an HCS12 part, installing it in an expanded mode
board, and read all the secured Flash content by executing from external
memory...
In addition, operation of the expanded bus on the HCS12 is a real
challenge. It is do-able - but not easy. If you like, you can read an
article I wrote on the subject:
http://www.nohau.com/appnotes/hcs12-expanded-mode-guide.pdf
To bypass many of the above problems, plus be able to access the internal
Flash while secured and external RAM, it is better to operate the
MC9S12DG256 in Normal Single-Chip mode, and access the external RAM by
bit-banging the appropriate ports (writing and reading the appropriate port
pins that interface with the external RAM). This is slower, but in many
applications the access speed to external RAM in not very critical (since
the code executes from internal Flash at full-speed, so access to external
RAM happen relatively infrequently and can therefore be slow).
If you need to use expanded mode, you can additionally consider using the
newer S12X family - and the MC9S12XDP512. This device has a much nicer
expanded mode bus design, well designed for expanded bus use with no glue
logic.
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
At 00:56 01/01/2006 +0000, you wrote:
>I have a project for which I'm planning to use the MC9S12DG256
>processor running from internal flash, and would also like to use the
>external bus to access RAM and peripherials.
>
>I read something in one of the documents for this processor which
>suggested that if I was running in secure mode (locked flash), then I
>couldn't access the external bus at all.
>
>This doesn't seem to make much sense, so I'm assuming that I just
>misunderstood.
>
>Has anyone booted one of these processors in single chip mode (i.e.
>boot from internal flash), but still managed to access the external
>bus? Does this still work in secure mode?
>
>Thanks for any assistance.
>
>Rgds,
>Steve
Actually, when the MC9S12DG256 operates in expanded mode, and the Flash is
secured, the Flash indeed cannot be accessed. This is in order to protect
against de-soldering an HCS12 part, installing it in an expanded mode
board, and read all the secured Flash content by executing from external
memory...
In addition, operation of the expanded bus on the HCS12 is a real
challenge. It is do-able - but not easy. If you like, you can read an
article I wrote on the subject:
http://www.nohau.com/appnotes/hcs12-expanded-mode-guide.pdf
To bypass many of the above problems, plus be able to access the internal
Flash while secured and external RAM, it is better to operate the
MC9S12DG256 in Normal Single-Chip mode, and access the external RAM by
bit-banging the appropriate ports (writing and reading the appropriate port
pins that interface with the external RAM). This is slower, but in many
applications the access speed to external RAM in not very critical (since
the code executes from internal Flash at full-speed, so access to external
RAM happen relatively infrequently and can therefore be slow).
If you need to use expanded mode, you can additionally consider using the
newer S12X family - and the MC9S12XDP512. This device has a much nicer
expanded mode bus design, well designed for expanded bus use with no glue
logic.
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
At 00:56 01/01/2006 +0000, you wrote:
>I have a project for which I'm planning to use the MC9S12DG256
>processor running from internal flash, and would also like to use the
>external bus to access RAM and peripherials.
>
>I read something in one of the documents for this processor which
>suggested that if I was running in secure mode (locked flash), then I
>couldn't access the external bus at all.
>
>This doesn't seem to make much sense, so I'm assuming that I just
>misunderstood.
>
>Has anyone booted one of these processors in single chip mode (i.e.
>boot from internal flash), but still managed to access the external
>bus? Does this still work in secure mode?
>
>Thanks for any assistance.
>
>Rgds,
>Steve
Reply by ●January 2, 20062006-01-02
Hi Doron;
Yup, I was afraid that was what the answer would be. 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.
I guess I'll be using the port A/B lines directly as digital I/O to
talk to my peripherials. This really won't cause me that much
trouble, it's just annoying to pay for the external bus on the chip
and not be able to use it.
Thanks,
Steve
--- In 68HC12@68HC..., Doron Fael <doronf@n...> wrote:
>
> Steve,
>
> Actually, when the MC9S12DG256 operates in expanded mode, and the
Flash is
> secured, the Flash indeed cannot be accessed. This is in order to
protect
> against de-soldering an HCS12 part, installing it in an expanded mode
> board, and read all the secured Flash content by executing from
external
> memory...
>
> In addition, operation of the expanded bus on the HCS12 is a real
> challenge. It is do-able - but not easy. If you like, you can read an
> article I wrote on the subject:
> http://www.nohau.com/appnotes/hcs12-expanded-mode-guide.pdf
>
> To bypass many of the above problems, plus be able to access the
internal
> Flash while secured and external RAM, it is better to operate the
> MC9S12DG256 in Normal Single-Chip mode, and access the external RAM by
> bit-banging the appropriate ports (writing and reading the
appropriate port
> pins that interface with the external RAM). This is slower, but in many
> applications the access speed to external RAM in not very critical
(since
> the code executes from internal Flash at full-speed, so access to
external
> RAM happen relatively infrequently and can therefore be slow).
>
> If you need to use expanded mode, you can additionally consider
using the
> newer S12X family - and the MC9S12XDP512. This device has a much nicer
> expanded mode bus design, well designed for expanded bus use with no
glue
> logic.
>
> Hope this helps,
> Doron
> Nohau
> HC12 In-Circuit Emulators
> www.nohau.com/emul12pc.html
>
> At 00:56 01/01/2006 +0000, you wrote:
> >I have a project for which I'm planning to use the MC9S12DG256
> >processor running from internal flash, and would also like to use the
> >external bus to access RAM and peripherials.
> >
> >I read something in one of the documents for this processor which
> >suggested that if I was running in secure mode (locked flash), then I
> >couldn't access the external bus at all.
> >
> >This doesn't seem to make much sense, so I'm assuming that I just
> >misunderstood.
> >
> >Has anyone booted one of these processors in single chip mode (i.e.
> >boot from internal flash), but still managed to access the external
> >bus? Does this still work in secure mode?
> >
> >Thanks for any assistance.
> >
> >Rgds,
> >Steve >
>
Yup, I was afraid that was what the answer would be. 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.
I guess I'll be using the port A/B lines directly as digital I/O to
talk to my peripherials. This really won't cause me that much
trouble, it's just annoying to pay for the external bus on the chip
and not be able to use it.
Thanks,
Steve
--- In 68HC12@68HC..., Doron Fael <doronf@n...> wrote:
>
> Steve,
>
> Actually, when the MC9S12DG256 operates in expanded mode, and the
Flash is
> secured, the Flash indeed cannot be accessed. This is in order to
protect
> against de-soldering an HCS12 part, installing it in an expanded mode
> board, and read all the secured Flash content by executing from
external
> memory...
>
> In addition, operation of the expanded bus on the HCS12 is a real
> challenge. It is do-able - but not easy. If you like, you can read an
> article I wrote on the subject:
> http://www.nohau.com/appnotes/hcs12-expanded-mode-guide.pdf
>
> To bypass many of the above problems, plus be able to access the
internal
> Flash while secured and external RAM, it is better to operate the
> MC9S12DG256 in Normal Single-Chip mode, and access the external RAM by
> bit-banging the appropriate ports (writing and reading the
appropriate port
> pins that interface with the external RAM). This is slower, but in many
> applications the access speed to external RAM in not very critical
(since
> the code executes from internal Flash at full-speed, so access to
external
> RAM happen relatively infrequently and can therefore be slow).
>
> If you need to use expanded mode, you can additionally consider
using the
> newer S12X family - and the MC9S12XDP512. This device has a much nicer
> expanded mode bus design, well designed for expanded bus use with no
glue
> logic.
>
> Hope this helps,
> Doron
> Nohau
> HC12 In-Circuit Emulators
> www.nohau.com/emul12pc.html
>
> At 00:56 01/01/2006 +0000, you wrote:
> >I have a project for which I'm planning to use the MC9S12DG256
> >processor running from internal flash, and would also like to use the
> >external bus to access RAM and peripherials.
> >
> >I read something in one of the documents for this processor which
> >suggested that if I was running in secure mode (locked flash), then I
> >couldn't access the external bus at all.
> >
> >This doesn't seem to make much sense, so I'm assuming that I just
> >misunderstood.
> >
> >Has anyone booted one of these processors in single chip mode (i.e.
> >boot from internal flash), but still managed to access the external
> >bus? Does this still work in secure mode?
> >
> >Thanks for any assistance.
> >
> >Rgds,
> >Steve >
>
Reply by ●January 3, 20062006-01-03
--- 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.
> 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.
Reply by ●January 3, 20062006-01-03
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
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
Reply by ●January 3, 20062006-01-03
--- In 68HC12@68HC..., "Michael Huslig" <mhuslig@k...>
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
Good point. And if there was any way designed to distinguish "secure
code" from whatever else (including whatever anyone else is allowed to
add later), then it should be strict about keeping that distinction,
right?
The distinction is that internal Flash/ROM is considered the "secure
code". And no, this is not a complex virtual machine, so I don't
expect it to verify the byte code on such a complex level (that's why
Java is famous).
Sure, I think it would be nice to have that sort of architecture
available, but I am glad there is also this less expensive one.
Mike, I hope you don't take my comments personal, and not to be rude
nor ignorant. I would have demanded the same only a couple years ago.
It seems I've come to appreciate the delicate balance of the MC9S12
technology.
>
> 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
Good point. And if there was any way designed to distinguish "secure
code" from whatever else (including whatever anyone else is allowed to
add later), then it should be strict about keeping that distinction,
right?
The distinction is that internal Flash/ROM is considered the "secure
code". And no, this is not a complex virtual machine, so I don't
expect it to verify the byte code on such a complex level (that's why
Java is famous).
Sure, I think it would be nice to have that sort of architecture
available, but I am glad there is also this less expensive one.
Mike, I hope you don't take my comments personal, and not to be rude
nor ignorant. I would have demanded the same only a couple years ago.
It seems I've come to appreciate the delicate balance of the MC9S12
technology.
Reply by ●January 3, 20062006-01-03
> 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
> 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
Reply by ●January 3, 20062006-01-03
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.
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.
Reply by ●January 3, 20062006-01-03
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 >
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 >
Reply by ●January 3, 20062006-01-03
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
>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
