Lpc2000

Hello,

The boot loader for 2104/5/6 (and I understand earlier versions of boot 
loader for other parts as well) by default catch UND, PRE and ABT type 
exceptions.  These cause the CPSR and LR register to be displayed.

You can verify this by branching any memory location containing 0xffff in 
thumb mode. For parts with boot loader starting at 0xe000 (or 0xd000), "G 
57772 T" (or G 53766 T") should do the trick.   You would get CPRS and LR 
displayed repeatedly as large decimal numbers as the boot loader catches 
the sequence of exceptions.

On the 2292 when I do a "G 57772 T", the boot loader does not display 
anything.  It appears to just hangs and requires a hard reset to come out 
of this.  This begs the question as to what happens to the exception handler.

The reasons for this change would be of concern to anyone who relies on CRP 
feature of the LPCs.  Here are the explanation.

The startup code for 2105 is as follows:

>         ldr     pc, _RST        @ reset entry point
>         ldr     pc, _UND        @ undefined instruction
>         ldr     pc, _SWI        @ software interrupt
>         ldr     pc, _PRE        @ prefetch abort
>         ldr     pc, _ABT        @ data fetch abort
>         nop                     @ reserved
>         ldr     pc, _IRQ        @ interrupt entry
>         ldr     pc, _FIR        @ fast interrupt
>
>_RST:   .word   reset
>_UND:   .word   error
>_SWI:   .word   0
>_PRE:   .word   error
>_ABT:   .word   error
>         .word   0
>_IRQ:   .word   0
>_FIR:   .word   0


Note that UND, PRE and ABT exceptions invoke the "error" handler.

In the case of devices with CRP, given LPC wakes up with JTAG debugging 
enabled, boot loader must disable it CRP is enabled.  It does this by first 
disabling it, and then re-enabling it later if CRP is not enabled.

The code to disable JTAG debugging on the 2292 is as follows:

>         ldr     r2, =PINSEL2
>         mov     r3, #0
>         swp     r0, r3, [r2]

The writing of 0 to PINSEL2 by the third "swp" instruction disables JTAG 
debugging.  One would expect this be done at "start" label.  Thus one would 
expect that JTAG debugging will be disabled on execution the fourth 
instruction after reset, the first being the vector itself.

It appears that boot loader designers consider four instruction cycles too 
long to secure the device from JTAG based CRP exploits.  They considered it 
worth reducing this by just one cycle (to three instructions cycles), at 
the expense of doing away with UND, PRE and ABT exception handler code.

Not only have they done away with handling these exceptions, but they have 
now made the system indeterminate when one of these exceptions do 
occur.  This is because if an UND exception occurred (for example by "G" 
command I referred to above) control is transferred to the second 
instruction instead of the first.

What is of concern is that the boot loader designers have chosen to move 
the code up so that they now disable JTAG in three instructions in stead of 
four.  This must mean that they are aware of JTAG exploits that defeat CRP.

For those skeptics who said that they consider CRP safe until someone posts 
the exploit here in the forum, here is another compelling argument to think 
again.

Jaya 

Send instant messages to your online friends http://au.messenger.yahoo.com

Jayasooriah wrote:

>What is of concern is that the boot loader designers have chosen to move 
>the code up so that they now disable JTAG in three instructions in stead of 
>four.  This must mean that they are aware of JTAG exploits that defeat CRP.
>
>For those skeptics who said that they consider CRP safe until someone posts 
>the exploit here in the forum, here is another compelling argument to think 
>again.
>
>  
>
While I respect your desire to look into the CRP, I am not interested in 
supposition.  As I understand it, the JTAG runs at a fractional rate vs 
the CPU clock.  You cannot run the JTAG above the rate the CPU is 
running at.  So, in my way of thinking, the time it would take you to 
seize control via the JTAG, the processor has had ample time to execute 
a few instructions to disable further use of the JTAG.

I do believe that this is what Philips is doing.  Now, I would be 
interested in some theoretical / empirical evidence that the JTAG can 
stop the process in less than those 3 .. 4 opcode executions.  This 
would evidence a problem indeed.

Regards,

TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Hi Tom,

If we accept what you say, it appears trading one instruction cycle off the 
window of opportunity for exception handling is a silly thing to do.

The designers made a deliberate tradeoff.  I am asking why.  Does this 
action dismiss the threat or does it just reduce the window of opportunity?

One can only draw inferences from Philips silence that the latter is the case.

Kind regards,

Jaya

PS1:  I am curious as to where it is stated that JTAG cannot run above the 
rate the CPU is running at.

PS2:  In counting instruction cycles, you have to take into account 
pipeline delays.

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@...> wrote:
 > While I respect your desire to look into the CRP, I am not interested in
 > supposition.  As I understand it, the JTAG runs at a fractional rate vs
 > the CPU clock.  You cannot run the JTAG above the rate the CPU is
 > running at.  So, in my way of thinking, the time it would take you to
 > seize control via the JTAG, the processor has had ample time to execute
 > a few instructions to disable further use of the JTAG.
 >
 > I do believe that this is what Philips is doing.  Now, I would be
 > interested in some theoretical / empirical evidence that the JTAG can
 > stop the process in less than those 3 .. 4 opcode executions.  This
 > would evidence a problem indeed.

Send instant messages to your online friends http://au.messenger.yahoo.com

Hello Jaya,

On Monday 06 February 2006 02:13, Jayasooriah wrote:
> Hi Tom,
>
> If we accept what you say, it appears trading one instruction cycle off the
> window of opportunity for exception handling is a silly thing to do.
>
> The designers made a deliberate tradeoff.  I am asking why.  Does this
> action dismiss the threat or does it just reduce the window of opportunity?
>
> One can only draw inferences from Philips silence that the latter is the
> case.

Sure - my bet is that they had a nice weekend, and didn't bother checking that 
forum.

>
> Kind regards,
>
> Jaya
>
> PS1:  I am curious as to where it is stated that JTAG cannot run above the
> rate the CPU is running at.

http://www.arm.com/support/faqip/3732.html
The LPCs are ARM7TDMI-S cores, requiring the synchronization logic shown in 
the above faq entry. That means they can't run TCK above 1/6th of the core 
frequency.

>
> PS2:  In counting instruction cycles, you have to take into account
> pipeline delays.

Regards,

Dominic

Hi Dominic,
If the clocks are unrelated / asynchronous and you rely on RTCK, then sure the fastest you 
can run the TCK at is 1/6 of the core frequency. But if you control the core frequency (i.e. 
generate it and feed it into the oscillator pin) and also generate TCK, I reckon that you 
might be able to push TCK up to 1/2 of the core frequency and get it through the 
synchronizer.

Now I don't know how many TCK ticks it takes to issue a command over JTAG (or if you 
can take over while the CPU is held in reset all the way from power-on). But the MAM is 
fully disabled so you'll need seven core ticks for each FLASH memory access. I do hope 
that someone who knows JTAG can tell me "Well the scan chain is 32 bits long and a 
command is 4 bits long so you'll need at least 36 TCK, i.e. 72* core cycles to take over. 
And in that time the core has executed over 10 instructions so the potential trapdoor is 
already bolted shut". I don't know JTAG so I can't say such things.

*according to my suspicion that you can push TCK up to half the core frequency

Regards,
Danish
--- In lpc2000@yahoogroups.com, Dominic Rath <Dominic.Rath@...> wrote:

> 
> http://www.arm.com/support/faqip/3732.html
> The LPCs are ARM7TDMI-S cores, requiring the synchronization logic shown in 
> the above faq entry. That means they can't run TCK above 1/6th of the core 
> frequency.
> 
> Regards,
> 
> Dominic
>

Hello,

On Monday 06 February 2006 21:01, dr_danish_ali wrote:
> Hi Dominic,
> If the clocks are unrelated / asynchronous and you rely on RTCK, then sure
> the fastest you can run the TCK at is 1/6 of the core frequency. But if you
> control the core frequency (i.e. generate it and feed it into the
> oscillator pin) and also generate TCK, I reckon that you might be able to
> push TCK up to 1/2 of the core frequency and get it through the
> synchronizer.
>
> Now I don't know how many TCK ticks it takes to issue a command over JTAG
> (or if you can take over while the CPU is held in reset all the way from
> power-on). But the MAM is fully disabled so you'll need seven core ticks
> for each FLASH memory access. I do hope that someone who knows JTAG can
> tell me "Well the scan chain is 32 bits long and a command is 4 bits long
> so you'll need at least 36 TCK, i.e. 72* core cycles to take over. And in
> that time the core has executed over 10 instructions so the potential
> trapdoor is already bolted shut". I don't know JTAG so I can't say such
> things.

You can't access the JTAG port while the device is in reset, because the LPCs 
keep the test logic in reset, too.

Test logic comes out of reset in Test-Logic-Reset. From there, you have to go 
to Shift-IR to select the SCAN_N instruction, that's 5 TCK cycles. The IR 
register is 4 bits long, but the last bit is scanned when moving out of 
Shift-IR, so you spend 3 ticks shifting bits into the IR reg. From there, you 
have to move to Shift-DR to select the EmbeddedICE scan chain. This takes 7 
TCK cycles. The SCAN_N register is 4 bits long, so you shift 3 bits. Back to 
Shift-IR to select INTEST takes 8 ticks. 3 ticks for the instruction. 7 Ticks 
back to Shift-DR. The EmbeddedICE scan chain is 38 bits long, requiring a 
shift of 37 cycles. The synchronization latches only open in Run-Test/Idle, 
so you have to move there in 5 ticks, plus one tick in R-T-I for the debug 
request to register.
5 + 3 + 7 + 3 + 8 + 3 + 7 + 37 + 5 + 1 = 79 TCK cycles.

>
> *according to my suspicion that you can push TCK up to half the core
> frequency
>
> Regards,
> Danish
>

Regards,

Dominic

>    Date: Mon, 6 Feb 2006 08:32:31 +0100
>    From: Dominic Rath <Dominic.Rath@...>
>Subject: Re: re: CRP exploits using JTAG
>
>...
>
>http://www.arm.com/support/faqip/3732.html
>The LPCs are ARM7TDMI-S cores, requiring the synchronization logic shown in
>the above faq entry. That means they can't run TCK above 1/6th of the core
>frequency.

Thanks for the reference.  I admit I had not see this.  In TDMI-S Technical 
Reference Manual (Revision 4), it says in Section 6.4 under heading "Clocks 
and Resets", that "you must connect processor clock to both CLK and TCK on 
the ETM".  [Sorry ARM documents do not allow cut and paste ...]

In any case this appears to be a requirement to access the ETM and not the 
processor scan chain itself.

 From past experience (on another ARM variants), I know that the TCK runs 
independent of CPU clock, and that TAP comes out of reset is independent or 
what state the processor is in.

I doubt we will ever see "here is how reducing startup code by one branch 
stops JTAG exploits" type of poster in this forum.

Jaya 

Send instant messages to your online friends http://au.messenger.yahoo.com

Dominic, I do not think this is the threat the designers were defending.

>    Date: Mon, 6 Feb 2006 21:21:04 +0100
>    From: Dominic Rath <Dominic.Rath@...>
>Subject: Re: Re: CRP exploits using JTAG
>
>On Monday 06 February 2006 21:01, dr_danish_ali wrote:
> > Hi Dominic,
> > If the clocks are unrelated / asynchronous and you rely on RTCK, then sure
> > the fastest you can run the TCK at is 1/6 of the core frequency. But if you
> > control the core frequency (i.e. generate it and feed it into the
> > oscillator pin) and also generate TCK, I reckon that you might be able to
> > push TCK up to 1/2 of the core frequency and get it through the
> > synchronizer.

For what it is worth, I think you should be able to push it to core 
frequency itself as the TDMI-S TRM seems to imply in "Clocks and Resets" 
section.

> > ...
> > But the MAM is fully disabled so you'll need seven core ticks
> > for each FLASH memory access.

I am interested to know how to use this information to work out exactly how 
many cycles it takes to carry out each of the three instructions below:

>         ldr     r2, =PINSEL2                                    @e000
>         mov     r3, #0                                          @e004
>         swp     r0, r3, [r2]                                    @e008

There are four flash memory accesses and three execute cycles.  I am 
guessing it is something like 4*7 (flash) + 3*3 (execute) - 3 (pipeline) = 
34 TCKs.

Now if we add one more instruction (to retain exception handler code), it 
will add another two flash memory accesses and one execute cycle, making 
the total 49 TCKs.

So if someone can come up with a calculation to the effect that JTAG can be 
used to exploit within 49 ticks, but not within 34 ticks, then we can say 
an exploit has been blocked and losing exception handler in the process was 
worth it.

>You can't access the JTAG port while the device is in reset, because the 
>LPCs keep the test logic in reset, too.

I am curious if this is stated anywhere or if you determined this by 
experiment.  Note, besides ETM chain, there is also a processor chain that 
can be accessed.

>Test logic comes out of reset in Test-Logic-Reset. From there, you have to 
>go to Shift-IR to select the SCAN_N instruction, that's 5 TCK cycles. The 
>IR register is 4 bits long, but the last bit is scanned when moving out of 
>Shift-IR, so you spend 3 ticks shifting bits into the IR reg. From there, 
>you have to move to Shift-DR to select the EmbeddedICE scan chain. This 
>takes 7 TCK cycles. The SCAN_N register is 4 bits long, so you shift 3 
>bits. Back to
>Shift-IR to select INTEST takes 8 ticks. 3 ticks for the instruction. 7 
>Ticks back to Shift-DR. The EmbeddedICE scan chain is 38 bits long, 
>requiring a shift of 37 cycles. The synchronization latches only open in 
>Run-Test/Idle, so you have to move there in 5 ticks, plus one tick in 
>R-T-I for the debug request to register.
>5 + 3 + 7 + 3 + 8 + 3 + 7 + 37 + 5 + 1 = 79 TCK cycles.

I can  follow your logic here, but 79 ticks seems too far off the mark 
compared to 34 and 49 above.  Have out missed out something?

Jaya


Send instant messages to your online friends http://au.messenger.yahoo.com

Jayasooriah wrote:

>Dominic, I do not think this is the threat the designers were defending.
>  
>
>>You can't access the JTAG port while the device is in reset, because the 
>>LPCs keep the test logic in reset, too.
>>    
>>
>
>I am curious if this is stated anywhere or if you determined this by 
>experiment.  Note, besides ETM chain, there is also a processor chain that 
>can be accessed.
>
>  
>
Understandably, Philips does not go into detail as to how JTAG operates, 
this is an IEEE spec now and documents are available elsewhere. JTAG is 
very very well documented: Joint Test / Action Group.  JTAG is not a 
"secret" but was created in response to a growing problem in the ATE 
(Auto Test Engineering) and software development arena in dealing with 
more complex processors.

This link would get you started into understanding JTAG:
http://klabs.org/richcontent/old_news/old_news_7/old_news_7.htm

TomW



-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Tom, I cannot find anything in your reference that says you cannot access 
the JTAG port while the processor is in reset. I hope I am not missing 
something obvious in your reference.

The TEST-LOGIC-RESET (nTRST) referred to in your reference many times is 
independent of processor reset (nRESET) which I refer to as LPC reset.  If 
these are linked in LPC, I like to see where this is stated.

Also, in relation to your comment that IEEE JTAG publications are no 
secret, yes JTAG is open but the IEEE does not (and cannot) define 
instructions for designer added chains.  Only the designer can tell you 
what these are and what they do.

Note that the specifications (as interpreted in ARM7DTMI-S TRM) states that 
you cannot use EXETEST, SAMPLE, and PRELOAD instructions on the scan chains 
1 and 2 because "unpredictable behaviour occurs".

This simply means that what actually happens is not covered by the 
specifications.  This is because it depends on the particular 
implementation.  There has been at least one instance I know of personally 
where such an instruction was exploited to do "creative" things the 
designers could not have predicted or anticipated.

Summary: a) with JTAG enabled (before and) upon reset, it is hard to prove 
that it cannot be cannot be used to exploit CRP; b) it would be easy to 
show how JTAG can be used to exploit CRP here but there are legal 
ramifications to consider; and c) given boot loader is a core and necessary 
component of CRP, I would not recommend anyone rely on CRP without any from 
of certification as to the integrity of boot loader implementation.

Jaya

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@...> wrote:
 >
 > Jayasooriah wrote:
 >
 > >Dominic, I do not think this is the threat the designers were defending.
 > >
 > >
 > >>You can't access the JTAG port while the device is in reset, because the
 > >>LPCs keep the test logic in reset, too.
 > >>
 > >>
 > >
 > >I am curious if this is stated anywhere or if you determined this by
 > >experiment.  Note, besides ETM chain, there is also a processor chain that
 > >can be accessed.
 > >
 > >
 > >
 > Understandably, Philips does not go into detail as to how JTAG operates,
 > this is an IEEE spec now and documents are available elsewhere. JTAG is
 > very very well documented: Joint Test / Action Group.  JTAG is not a
 > "secret" but was created in response to a growing problem in the ATE
 > (Auto Test Engineering) and software development arena in dealing with
 > more complex processors.
 >
 > This link would get you started into understanding JTAG:
 > http://klabs.org/richcontent/old_news/old_news_7/old_news_7.htm
 >
 > TomW

Send instant messages to your online friends http://au.messenger.yahoo.com

Hello,

On Tuesday 07 February 2006 04:21, Jayasooriah wrote:
> I am curious if this is stated anywhere or if you determined this by
> experiment.  Note, besides ETM chain, there is also a processor chain that
> can be accessed.
>
Philips stated it, but only after several reports in this group, in the 
"[lpc2000] destroyed LPC2138 via software" thread (though with the usual 
amount of unclarity, stating that jtag was disabled after reset, and only 
reenabled by software ;)).
Before that, I found it out by experiment. Force nSRST low, and you can shift 
into the device whatever you want, without any effect. Also, the content of 
the EmbeddedICE registers is reset, so the target wont break on a previously 
set breakpoint (other ARMs support this).

> >Test logic comes out of reset in Test-Logic-Reset. From there, you have to
> >go to Shift-IR to select the SCAN_N instruction, that's 5 TCK cycles. The
> >IR register is 4 bits long, but the last bit is scanned when moving out of
> >Shift-IR, so you spend 3 ticks shifting bits into the IR reg. From there,
> >you have to move to Shift-DR to select the EmbeddedICE scan chain. This
> >takes 7 TCK cycles. The SCAN_N register is 4 bits long, so you shift 3
> >bits. Back to
> >Shift-IR to select INTEST takes 8 ticks. 3 ticks for the instruction. 7
> >Ticks back to Shift-DR. The EmbeddedICE scan chain is 38 bits long,
> >requiring a shift of 37 cycles. The synchronization latches only open in
> >Run-Test/Idle, so you have to move there in 5 ticks, plus one tick in
> >R-T-I for the debug request to register.
> >5 + 3 + 7 + 3 + 8 + 3 + 7 + 37 + 5 + 1 = 79 TCK cycles.
>
> I can  follow your logic here, but 79 ticks seems too far off the mark
> compared to 34 and 49 above.  Have out missed out something?

These 79 TCK cycles are the minimum necessary to write the Debug control 
register when coming out of Test-Logic-Reset. You just can't do it with less 
TCKs.

>
> Jaya

Dominic,

I believe you are not distinguishing between JTAG reset and LPC reset.

JTAG operations are carried out using the TAP (Test Access Port) 
controller.  This TAP controller can be forced to its "reset" state by 
driving signal nTRST LOW or by pushing a sequence through TMS for a given 
number (I recall 5) of TCKs.

To use the boundary scan interface, nTRST must be driven LOW and then HIGH 
again. You appear to have held it low, and hence your observations.

Driving nTRST HIGH does not mean you have also to drive nRESET HIGH.  The 
TAP controller can be accessed with nRESET held low, and this how "boundary 
scanning" is used for debugging in the days before ETM (Embedded Trace 
Macrocell).

One discovers chains, and instructions that operate on these chains, by 
scanning the TAP controller.  The ETM (understandably) may be held in reset 
state while nRESET is low.  However this appears not to be the case for for 
chain 1 or any other chains not covered by IEEE specifications.

By its nature JTAG implementations typically do no more than what they are 
expected to do in the sense the designers do not worry about what happens 
if instructions or data other than what is expected is shifted in.  So it 
is very hard to say what can and cannot be done if we go beyond public 
instruction set.  Not being able to "fuse off" JTAG port is its biggest 
drawback in the context of CRP.

I would not assume CRP is safe just because nobody has posted a JTAG 
exploit in this forum.  I would enumerate threats, then assess each threat 
in terms of risks and costs.  Putting your product in student laboratories 
is a very different ball game to sending them out to some country that does 
not have enforceable copyright laws.

IMO, JTAG window has too large an attack surface area to consider it safe 
for most (if not all) of the requirements I have had to evaluated.  Adding 
to this, the fact that boot loader code is closed and comes with no 
certification of any kind makes CRP no more than "child proofing" as one 
poster put it.

Regards

Jaya

PS:  I bet you can find ways to reduce the 79 TCK requirements by taking in 
to account the state the shift registers before you shift but this is not 
why I would not take the 79 TCK requirement seriously.  If you needed this 
many cycles then it does not make sense to reduce the window of opportunity 
by one jump instruction at the expense of exception handling, as was done 
on the 2292.

--- In lpc2000@yahoogroups.com, Dominic Rath <Dominic.Rath@...> wrote:
 > Philips stated it, but only after several reports in this group, in the
 > "[lpc2000] destroyed LPC2138 via software" thread (though with the usual
 > amount of unclarity, stating that jtag was disabled after reset, and only
 > reenabled by software ;)).

 > Before that, I found it out by experiment. Force nSRST low, and you can 
shift
 > into the device whatever you want, without any effect. Also, the content of
 > the EmbeddedICE registers is reset, so the target wont break on a 
previously
 > set breakpoint (other ARMs support this).
 >
 > > >Test logic comes out of reset in Test-Logic-Reset. From there, you 
have to
 > > >go to Shift-IR to select the SCAN_N instruction, that's 5 TCK cycles. The
 > > >IR register is 4 bits long, but the last bit is scanned when moving 
out of
 > > >Shift-IR, so you spend 3 ticks shifting bits into the IR reg. From there,
 > > >you have to move to Shift-DR to select the EmbeddedICE scan chain. This
 > > >takes 7 TCK cycles. The SCAN_N register is 4 bits long, so you shift 3
 > > >bits. Back to
 > > >Shift-IR to select INTEST takes 8 ticks. 3 ticks for the instruction. 7
 > > >Ticks back to Shift-DR. The EmbeddedICE scan chain is 38 bits long,
 > > >requiring a shift of 37 cycles. The synchronization latches only open in
 > > >Run-Test/Idle, so you have to move there in 5 ticks, plus one tick in
 > > >R-T-I for the debug request to register.
 > > >5 + 3 + 7 + 3 + 8 + 3 + 7 + 37 + 5 + 1 = 79 TCK cycles.
 > >
 > > I can  follow your logic here, but 79 ticks seems too far off the mark
 > > compared to 34 and 49 above.  Have out missed out something?
 >
 > These 79 TCK cycles are the minimum necessary to write the Debug control
 > register when coming out of Test-Logic-Reset. You just can't do it with 
less
 > TCKs.
 >
 > >
 > > Jaya
 >

Send instant messages to your online friends http://au.messenger.yahoo.com

Jaya,

On Wednesday 08 February 2006 15:32, Jayasooriah wrote:
> Dominic,
>
> I believe you are not distinguishing between JTAG reset and LPC reset.
I am distinguishing between JTAG reset and LPC reset. I wouldn't say nSRST if 
I meant nTRST, or vice versa. nTRST is hardly of any use (my OpenOCD works 
fine without it).

> JTAG operations are carried out using the TAP (Test Access Port)
> controller.  This TAP controller can be forced to its "reset" state by
> driving signal nTRST LOW or by pushing a sequence through TMS for a given
> number (I recall 5) of TCKs.
Yes.

> To use the boundary scan interface, nTRST must be driven LOW and then HIGH
> again. You appear to have held it low, and hence your observations.
No. This behaviour has been confirmed by someone from Rowley.

> Driving nTRST HIGH does not mean you have also to drive nRESET HIGH.  The
> TAP controller can be accessed with nRESET held low, and this how "boundary
> scanning" is used for debugging in the days before ETM (Embedded Trace
> Macrocell).
Debugging doesn't use the ETM. Debugging uses the EmbeddedICE macrocell.
On the LPCs, driving nRESET low keeps the TAP controller in reset, too. 
Period.

> ... snip ...
> PS:  I bet you can find ways to reduce the 79 TCK requirements by taking in
> to account the state the shift registers before you shift but this is not
> why I would not take the 79 TCK requirement seriously.  If you needed this
> many cycles then it does not make sense to reduce the window of opportunity
> by one jump instruction at the expense of exception handling, as was done
> on the 2292.
The scan chain select register is set to 0 after reset, and the instruction 
register is set to the IDCODE instruction. That means you have to:
- select the SCAN_N instruction
- shift in b0010 (Scan chain 2 is the EmbeddedICE macrocell)
- select the INTEST instruction
- shift in data for the EmbeddedICE control register to request a debug entry
Just because you believe that this is the reason why Philips dumped the 
exception vectors doesnt necessarily mean that there's a way to cut the 
number of TCK cycles down.

Regards,

Dominic

Dominic,

My apologies. I misread nSRTS as nTRST, and I incorrectly referred to 
EmbeddedICE-RT macrocell as ETM -- I did not meant to discuss ETM at all.

I have no experience with EIRM debugging myself and what I am raising here 
is mainly based on scanning ARM7-DTMI-S Technical Reference Manual (TRM) 
(Revision 4) for the purposes of this discussion :)

At 03:19 09/02/2006, lpc2000@yahoogroups.com wrote:
>    Date: Wed, 8 Feb 2006 16:58:45 +0100
>    From: Dominic Rath <Dominic.Rath@...>
>Subject: Re: re: CRP exploits using JTAG
>...
> > To use the boundary scan interface, nTRST must be driven LOW and then HIGH
> > again. You appear to have held it low, and hence your observations.
>No. This behaviour has been confirmed by someone from Rowley.

I was quoting the above from 5.12.1 of the TRM.  Note that it also says in 
this section that when the boundary scan interface is not used, you can tie 
DBGnTRST input low.  Is this what your OpenCD tool does?

>...
>On the LPCs, driving nRESET low keeps the TAP controller in reset, too.
>Period.

I heard you the first time, but where would one find this information? If 
it was  established by experimentation, how was nTRST driven?  LOW then 
HIGH or just LOW?

>Just because you believe that this is the reason why Philips dumped the
>exception vectors doesnt necessarily mean that there's a way to cut the
>number of TCK cycles down.

IMHO we (you and I) cannot conclusively say one way or another.  Only the 
designers can, and they have chosen not to.

What they have said, however, is:

"EmbeddedICE logic ... allows instructions to execute at a slow debug speed 
or at fast system speed"

"The scan chains that are around the core for production test are reused in 
the debug state ..."

If I had my JTAG to play with (and the time to play), I would try the 
following while nRESET is held low:

a) select SCAN_N instruction
b) select chain #1 (later 5,6,7,9-15 and so on)
c) select INTEST instruction
d) scan DBGBREAK bit (for chain #1)

and then see how long it then takes to enter debug mode in halt state upon 
releasing nRESET.

Jaya

PS:


Send instant messages to your online friends http://au.messenger.yahoo.com

Dominic has mentioned this and trying to set the core to break from
reset will not work with some ARM7 cores, the two i know of are the
LPC and the STR7.
The jtag cell and ice logic are both reset when the reset (nSRT) are
asserted, this is done internally without touching TSRT.

Your method is used (see below) but will not work in the case of the
LPC/STR7 - it has been tried.

The behaviour you mention is used on some arm cores (mainly ARM9) to
set a breakpoint at address 0 and perform a hard reset.

Regards
Spen

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> Dominic,
> 
> My apologies. I misread nSRTS as nTRST, and I incorrectly referred to 
> EmbeddedICE-RT macrocell as ETM -- I did not meant to discuss ETM at
all.
> 
> I have no experience with EIRM debugging myself and what I am
raising here 
> is mainly based on scanning ARM7-DTMI-S Technical Reference Manual
(TRM) 
> (Revision 4) for the purposes of this discussion :)
> 
> At 03:19 09/02/2006, lpc2000@yahoogroups.com wrote:
> >    Date: Wed, 8 Feb 2006 16:58:45 +0100
> >    From: Dominic Rath <Dominic.Rath@>
> >Subject: Re: re: CRP exploits using JTAG
> >...
> > > To use the boundary scan interface, nTRST must be driven LOW and
then HIGH
> > > again. You appear to have held it low, and hence your observations.
> >No. This behaviour has been confirmed by someone from Rowley.
> 
> I was quoting the above from 5.12.1 of the TRM.  Note that it also
says in 
> this section that when the boundary scan interface is not used, you
can tie 
> DBGnTRST input low.  Is this what your OpenCD tool does?
> 
> >...
> >On the LPCs, driving nRESET low keeps the TAP controller in reset, too.
> >Period.
> 
> I heard you the first time, but where would one find this
information? If 
> it was  established by experimentation, how was nTRST driven?  LOW then 
> HIGH or just LOW?
> 
> >Just because you believe that this is the reason why Philips dumped the
> >exception vectors doesnt necessarily mean that there's a way to cut the
> >number of TCK cycles down.
> 
> IMHO we (you and I) cannot conclusively say one way or another. 
Only the 
> designers can, and they have chosen not to.
> 
> What they have said, however, is:
> 
> "EmbeddedICE logic ... allows instructions to execute at a slow
debug speed 
> or at fast system speed"
> 
> "The scan chains that are around the core for production test are
reused in 
> the debug state ..."
> 
> If I had my JTAG to play with (and the time to play), I would try the 
> following while nRESET is held low:
> 
> a) select SCAN_N instruction
> b) select chain #1 (later 5,6,7,9-15 and so on)
> c) select INTEST instruction
> d) scan DBGBREAK bit (for chain #1)
> 
> and then see how long it then takes to enter debug mode in halt
state upon 
> releasing nRESET.
> 
> Jaya
> 
> PS:
> 
> 
> Send instant messages to your online friends
http://au.messenger.yahoo.com
>

Hello Jaya,

On Wednesday 08 February 2006 23:35, Jayasooriah wrote:
> Dominic,
>
> My apologies. I misread nSRTS as nTRST, and I incorrectly referred to
> EmbeddedICE-RT macrocell as ETM -- I did not meant to discuss ETM at all.
>
> I have no experience with EIRM debugging myself and what I am raising here
> is mainly based on scanning ARM7-DTMI-S Technical Reference Manual (TRM)
> (Revision 4) for the purposes of this discussion :)
>
> > > To use the boundary scan interface, nTRST must be driven LOW and then
> > > HIGH again. You appear to have held it low, and hence your
> > > observations.
> >
> >No. This behaviour has been confirmed by someone from Rowley.
>
> I was quoting the above from 5.12.1 of the TRM.  Note that it also says in
> this section that when the boundary scan interface is not used, you can tie
> DBGnTRST input low.  Is this what your OpenCD tool does?
The "No" was refering to "You appear...".
nTRST would allow you to reset the test logic, without affecting the operation 
of the core, but as you correctly observed this can be achieved using 5x TCK 
with TMS high, too. My OpenOCD allows you to specify whether nTRST is 
available at all, and if it should be used - during normal (debug-)operation, 
nTRST has to be driven high. Tying DBGnTRST low would disable the TAP.

> >...
> >On the LPCs, driving nRESET low keeps the TAP controller in reset, too.
> >Period.
>
> I heard you the first time, but where would one find this information? If
> it was  established by experimentation, how was nTRST driven?  LOW then
> HIGH or just LOW?
Tested by driving nRESET low. Driving it Low and then High lets the target 
run, and that's not what we want.

> >Just because you believe that this is the reason why Philips dumped the
> >exception vectors doesnt necessarily mean that there's a way to cut the
> >number of TCK cycles down.
>
> IMHO we (you and I) cannot conclusively say one way or another.  Only the
> designers can, and they have chosen not to.
>
> What they have said, however, is:
>
> "EmbeddedICE logic ... allows instructions to execute at a slow debug speed
> or at fast system speed"
This refers to the way ARM7/9 cores are debugged. Slow means that the core is 
clocked by the TAP controller (one core cycle for every tck spent in 
Run-Test/Idle when Scan Chain 1 is selected), while fast means that the core 
resynchronizes back to system speed, executes the instruction (usually a 
load/store to access memory), and reenters debug state. "Fast" doesn't mean 
that it's "faster" to execute instructions at system-speed than at 
debug-speed.

> "The scan chains that are around the core for production test are reused in
> the debug state ..."
>
> If I had my JTAG to play with (and the time to play), I would try the
> following while nRESET is held low:
>
> a) select SCAN_N instruction
> b) select chain #1 (later 5,6,7,9-15 and so on)
> c) select INTEST instruction
> d) scan DBGBREAK bit (for chain #1)
When nRESET is held low, you can't even shift the IDCODE out of the device. 
The TAP doesn't react at all. When shifting an instruction into the device, 
b0001 should be shifted out (it is when nRESET is high), but when nRESET is 
low, only zeroes appear at TDO (could be high impedance, too, but that's what 
my interfaces return).

> and then see how long it then takes to enter debug mode in halt state upon
> releasing nRESET.
>
> Jaya
>
> PS:

Regards,

Dominic

Still nothing concrete or specific.

It is irresponsible to carry on a thread implying there are CRP 
exploits using JTAG

For those with an elementary knowledge of microcontroller 
architecture it is easy to understand that on reset a signal can be 
raised that blocks debug break signals from JTAG and that this 
blocking action will require a specific action to clear. This might 
be called a very effective 'child proof' lock.

It is extraordinarily bad form to imply in a title that CRP exploits 
with JTAG exist. Many will not read beyond the subject title.

I have said this before and I will say it again. What is the real 
agenda?

John Heenan



--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
> 
> I would not assume CRP is safe just because nobody has posted a 
JTAG 
> exploit in this forum.  I would enumerate threats, then assess each 
threat 
> in terms of risks and costs.  Putting your product in student 
laboratories 
> is a very different ball game to sending them out to some country 
that does 
> not have enforceable copyright laws.
> 
> IMO, JTAG window has too large an attack surface area to consider 
it safe 
> for most (if not all) of the requirements I have had to evaluated.  
Adding 
> to this, the fact that boot loader code is closed and comes with no 
> certification of any kind makes CRP no more than "child proofing" 
as one 

> poster put it.
> 
> Regards
> 
> Jaya

Heenan,
We others, who also have half abrain,  appreciate the energy in this
examination and hope it proves that we all KNOW such security is tight, but
we embrace those who have the energy to question - and that of others who
with detailed rebuttal prove we are safe with a chippie we all respect -or
we wouldnt be here.

May I and others who understand no chip of this complexity can have ZERO
BUGS offer our respect, affection and support for the designers who struggle
to produce good silicon - and to others who perform exhaustive and publicly
published testing of same. And Im sure the testers - who have more than half
a brain in my analysis, also have respect and affection for the designers.
The Ying and the Yang.
Like democracy we debate and through our debate we build something stronger.
We share our minds.

So stuff ur religious politics up your Kwazoo - and pass it on to G W Bush.

Europe will be stronger, because wider separated minds will share a wider
experience.
Provided we debate.
Religion tries to make all minds the same and those societies who weaken to
religion will wane.

SO QUESTION  REALITY ... analyse ur lovin..as the song goes ...you may
appreciate it more ... or get something better quicker....

Rgds to all this sunny morn from downunder.

DonW






----- Original Message ----- 

From: "John Heenan" <l10@...>
To: <lpc2000@yahoogroups.com>
Sent: Friday, February 10, 2006 12:24 AM
Subject: [lpc2000] Silly and irresponsible title Re: CRP exploits using JTAG


> Still nothing concrete or specific.
>
> It is irresponsible to carry on a thread implying there are CRP
> exploits using JTAG
>
> For those with an elementary knowledge of microcontroller
> architecture it is easy to understand that on reset a signal can be
> raised that blocks debug break signals from JTAG and that this
> blocking action will require a specific action to clear. This might
> be called a very effective 'child proof' lock.
>
> It is extraordinarily bad form to imply in a title that CRP exploits
> with JTAG exist. Many will not read beyond the subject title.
>
> I have said this before and I will say it again. What is the real
> agenda?
>
> John Heenan
>
>
>
> --- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
> >
> > I would not assume CRP is safe just because nobody has posted a
> JTAG
> > exploit in this forum.  I would enumerate threats, then assess each
> threat
> > in terms of risks and costs.  Putting your product in student
> laboratories
> > is a very different ball game to sending them out to some country
> that does
> > not have enforceable copyright laws.
> >
> > IMO, JTAG window has too large an attack surface area to consider
> it safe
> > for most (if not all) of the requirements I have had to evaluated.
> Adding
> > to this, the fact that boot loader code is closed and comes with no
> > certification of any kind makes CRP no more than "child proofing"
> as one
> > poster put it.
> >
> > Regards
> >
> > Jaya
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

Don Williams wrote:

>Heenan,
>We others, who also have half abrain,  appreciate the energy in this
>examination and hope it proves that we all KNOW such security is tight, but
>we embrace those who have the energy to question - and that of others who
>with detailed rebuttal prove we are safe with a chippie we all respect -or
>we wouldnt be here.
>
>  
>
Wheeee!  Are we having a bad day?

I, too, find the thread about CRP tiresome...  So far, no substance.

TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Don,

we al respect engineers who come up with facts, do measurements,
experiments to sustain their theories but let's be real, so far we got
a memory dump of a LPC2104 bootloader, which be no means has any
security options according to Philips. 
This is about as irrelevant as it can be within the LPC2000 family
because ALL other members do have a security option.
We also got many hypothetical constructs with little or no facts based
on LPC silicon but on "experience with ARM and JTAG". This has been
discussed way longer than the shelve life and it really starts to
smell. I absolutely second Heenan and Tom that 2 months of discussions
with probably 200-300 posts half of all from one person are too much
of the good thing. 
If someone really sees CRP fail I am the first who wants to know but
until then we have read enough about theories that were not even
followed up with practical test by the same person.  
Are we all the students of an academic that come with theories and
asks us to do the work to proof him wrong!?

I really try to be fair here but let's go on with life and focus on
work, please

A not so cheerful Bob

p.s. I know I will get flamed for this post but at least most of my
postings are based on facts, experiments and measurements.

-- In lpc2000@yahoogroups.com, "Don Williams" <donw@...> wrote:
>
> Heenan,
> We others, who also have half abrain,  appreciate the energy in this
> examination and hope it proves that we all KNOW such security is
tight, but
> we embrace those who have the energy to question - and that of
others who
> with detailed rebuttal prove we are safe with a chippie we all
respect -or
> we wouldnt be here.
> 
> May I and others who understand no chip of this complexity can have ZERO
> BUGS offer our respect, affection and support for the designers who
struggle
> to produce good silicon - and to others who perform exhaustive and
publicly
> published testing of same. And Im sure the testers - who have more
than half
> a brain in my analysis, also have respect and affection for the
designers.
> The Ying and the Yang.
> Like democracy we debate and through our debate we build something
stronger.
> We share our minds.
> 
> So stuff ur religious politics up your Kwazoo - and pass it on to G
W Bush.
> 
> Europe will be stronger, because wider separated minds will share a
wider
> experience.
> Provided we debate.
> Religion tries to make all minds the same and those societies who
weaken to
> religion will wane.
> 
> SO QUESTION  REALITY ... analyse ur lovin..as the song goes ...you may
> appreciate it more ... or get something better quicker....
> 
> Rgds to all this sunny morn from downunder.
> 
> DonW
> 
> 
> 
> 
> 
> 
> ----- Original Message ----- 
> From: "John Heenan" <l10@...>
> To: <lpc2000@yahoogroups.com>
> Sent: Friday, February 10, 2006 12:24 AM
> Subject: [lpc2000] Silly and irresponsible title Re: CRP exploits
using JTAG

> 
> 
> > Still nothing concrete or specific.
> >
> > It is irresponsible to carry on a thread implying there are CRP
> > exploits using JTAG
> >
> > For those with an elementary knowledge of microcontroller
> > architecture it is easy to understand that on reset a signal can be
> > raised that blocks debug break signals from JTAG and that this
> > blocking action will require a specific action to clear. This might
> > be called a very effective 'child proof' lock.
> >
> > It is extraordinarily bad form to imply in a title that CRP exploits
> > with JTAG exist. Many will not read beyond the subject title.
> >
> > I have said this before and I will say it again. What is the real
> > agenda?
> >
> > John Heenan
> >
> >
> >
> > --- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@> wrote:
> > >
> > > I would not assume CRP is safe just because nobody has posted a
> > JTAG
> > > exploit in this forum.  I would enumerate threats, then assess each
> > threat
> > > in terms of risks and costs.  Putting your product in student
> > laboratories
> > > is a very different ball game to sending them out to some country
> > that does
> > > not have enforceable copyright laws.
> > >
> > > IMO, JTAG window has too large an attack surface area to consider
> > it safe
> > > for most (if not all) of the requirements I have had to evaluated.
> > Adding
> > > to this, the fact that boot loader code is closed and comes with no
> > > certification of any kind makes CRP no more than "child proofing"
> > as one
> > > poster put it.
> > >
> > > Regards
> > >
> > > Jaya
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>