Lpc2000

> > The web site falsely claims the 'first thing' the LPC2148 
> > bootloader does is to disable the JTAG debug port. The claim is 
false 
> > because the boot loader does two 'other things' first. The 'third 
> > thing' is to assign 0 to VPB register PINSEL2, which simply 
enables 
> > port 1 pins solely for GPIO use and cuts off access to JTAG debug 
and 
> > to trace. I will pose a question, why make false claims?
> 
> What does "thing" mean?  One instruction?  Could it be that the 
author
> has a higher level view of the structure of the boot loader and 
refers
> to all your three instructions as just one "thing"?

To quote from the web site at address 
http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/boot-loader.html

"However the first thing the boot loader in LPC2148 does (in a quite 
hasty fashion as if to minimise the window of opportunity) is to 
disable JTAG debug port.  This code is executed for both hardware and 
watchdog resets.  Why disable JTAG debug port if  is indeed already 
disabled on reset?"

The 'first thing', as falsely claimed on the web site, has to wait 
eight ARM instructions to complete after reset with additional wait 
states imposed by accessing the VPB. If it was genuinely the 'first 
thing' it would only require three ARM instructions to complete! 
Facts like this cannot be twisted out of. It has nothing to do with 
the issue of accessing SRAM with MAM disabled as no SRAM is accessed 
during the first eight insrtructions.

I have provivded one credible and practical possible answer, that is 
to allow access to GPIO ports irrespective of reset condition. I can 
think of at least one other. I am sure experts can suggest others.

> I certainly have disassembled version 1.62 boot loader on my LPC2292
> and have a good idea of how it is organised.  I would (probably) 
have
> said exactly the same thing.
> 
> > The first three ARM instructions assign 2 to VPB register MAMCR.
> > The next two ARM instructions assign 3 to VPB register MAMTIM.
> > The next three instructions assign 0 to PINSEL2 using a SWP 
command 
> > and stores the prior value of PINSEL2 in R0
> > 
> > It is trivial to skip over the SWP command to avoid becoming 
> > disconnected from the JTAG.
> 
> This is IMO the core weakness of the CRP method used by Philips
> compared to other methods like fuse bits used by ATMEL.

This is just so bizarre. 

ATMEL fuse bits are nothing more than non volatile storage bits, 
which guess what, so is address 0x1FC where the CRP value is held!

MSP430 microcontrollers use a real fuse that can be blown to disable 
JTAG. MSP430 microcontrollers also have a boot loader, called a BSL 
(Boot Strap Loader). Blowing the JTAG fuse on an MSP430 has no effect 
on the BSL.

> 
> > There is nothing in any of this sequence that justifies 
reasonable 
> > doubt about Philips claims.
> 
> I can think of the obvious one -- what happens if the attacker is 
able
> force and exception to be taken that forces the sequence to be 
entered
> not at the top?

What by overclocking and/or running the micrcontroller at marginal or 
execssive voltages? These are issues that have nothing to do with 
claims about the CRP and it far more likely the microcontroller will 
be fried rather than broken into.

You might as well state it is obvious you can huff and puff and blow 
my house down! While it is obvious you can try it is not obvious you 
will succeed, particularly if my house is not made of paper!

> 
> > While I could find out how many cycles are required to make JTAG 
> > attempt to assert an internal debug signal, I know is not a 
trivially 
> > small amount.
> 
> This is where your problem is.  You should find out exactly how many
> cycles are required.  There are good reasons for doing this:

> 1/  There is no reason to execute the three instructions at the
> locations reserved for vectors.  In doing so a vulnerability has 
been
> introduced that could break CRP, namely that an attacker can force 
and
> exception and jump to somewhere other than first instruction.
> 
> 2/  Bootloader implementors could have moved this code to the real
> start of the boot loader where it initialises LPC Limit Register (to
> limit size of on-chip RAM and ROM) by leaving the vector as it is.
> 
> It appears that they chose not too do this for good reasons.  It is
> quite plausible this reason has to do with how quickly JTAG 
interface
> could be used to take control of the core.

You have misrepresented my points, which I understand is a reocurring 
complaint.

ADDITIONALLY WHAT IS YOUR PROBLEM WITH ACCEPTING MY CENTRAL POINT 
THAT AN ENABLED JTAG DOES NOT MEAN  NECESSARILY INTERNAL DEBUG 
SIGNALS JTAG MAY BE ATTEMPTING TO ASSERT WILL BE ALLOWED TO ACT? THIS 
IS OBVIOUS TO ANYONE WITH EVEN A MODEST COMPETENT KNOWLEDGE OF 
ELECTONICS AND MICROCONTROLLER ARCHITECTURE.

A Ph.D. does not certify even a modest level of basic competence.

> 
> > For the LPC2xxxx series only one JTAG cycle is allowed 
> > for six processor clock cycles. Number of cycles required can be 
> > assessed from examining open source JTAG code. Open source JTAG 
code 
> > has its origins in code written by R Longo in 2000 for an Atmel 
ARM 
> > processor. Atmel also has JTAG code (under NDA), which it is 
possible 
> > to view without signing an NDA.
> > 
> > Even if there was no disablement of an internal debug bus signal 
> > pending writing to CSPR, it is possible there are simply not 
enough 
> > clock cycles avaialble to assert an internal debug signal.
> 
> Others argue that it is likely there are more than enough clock 
cycles
> available, or the boot loader implementors would not have resorted 
to
> trading off exception handling at the expense of a branch 
instruction.

Round and round again in an endless miserable merry go round we are 
not allowed to get off. Issue addressed in capitals above.

> > In 
> > addition claims that the supposed evidence is the 'first thing' 
done 
> > is false.
> 
> See above -- it looks like your interpretation of the claim is 
wrong.

Facts are facts. Five is not the same as zero. It is false to imply 
five glaringly obvious and highly visible ARM instructions can be 
whisked away into nothingness to justify a false 'first thing' claim.
 
> > In addition claims about stack overruns etc in the bootloader are 
> > irrelevant as all such claims involve using the bootloader 
outside 
> > the published specifications.
> 
> Quite far from that IMHO. An attacker can use this to force the
> exception that is needed to compromise the start up sequence. 

Again nothing solid or concrete, which I have complained about 
before. You know very well there are no relevant operations that can 
make such exploits if CRP works as specified, so why mislead us?

> 
> > Also there is little part of the 
> > bootloader specification which states it is designed to have data 
> > interpreted in human readable form, so why make bizarre snide 
> > commments about the format of information?
> 
> Just last week I had the privilege of speaking to a mixed bunch of
> embedded system programmers.  When discussing a requirement relating
> to entering of memory addresses I suggested they to specify the 
format
> as hexadecimal.

Mixed bunch??

> 
> They looked at me in bewilderment and asked how else does one 
specify
> memory addresses these days.  I said "octal" and one of them said I
> was being picky.
> 
> When I said "decimal" they all burst into laughter!
> 
> Jaya
>

I think any approach that can help guard against endian issues with 
trivial additional resources is to be welcomed and praised, rather 
than sneered and laughed at.

If programmers are forced to convert addresses to decimal then there 
is no confusion about the endianess of the information. This is a 
solution to a very practical and real problem, particularly on 
devices that can move between 16 bit Thumb and 32 bit ARM endian 
formats.

Since when does a Ph.D. and responsbilities in a big city university 
grant you a licence to treat us with such intellectual contempt that 
you just will not listen and acknowledge valid points? 

John heenan