Lpc2000

--- In lpc2000@yahoogroups.com, "John Heenan" <l10@...> wrote:
> 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!

It does look like your boot loader is different.  The three
instructions I was referring to in boot loader 2.1 on LPC2148 (which
has its part ID coded as that for LPC2138) are as follows:

>	ldr	r2, =PINSEL2				@d000
>	mov	r3, #0					@d004
>	swp	r0, r3, [r2]				@d008

I said it does "one thing" simply because the first two instructions
prepare the registers and the third instruction is the one that
actually carries out the operation of disabling JTAG interface.

Indeed in a later post, you find the same sequence in your boot
loader, but with 5 instructions preceding it.

The purpose of these five instructions appears to be the work around
for the MAM.1 bug.  Without this work around, a write to SRAM followed
by a read of SRAM will yield corrupt data.

> 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.

You have alluded us to another property of the LPC boot loaders.  It
looks like the boot loader implementors have no reservations about
writing code in the area that is reserved for interrupt vectors.

This is not good practice IMHO and I would not include boot loader
code in my trust domain, which I must do if I were to rely on CRP that
is implemented by  the boot loader.

I have not seen any developments by way of improvements to boot
loader, or by way of how Philips handles bug reports relating to the
boot loader that would prompt me to reconsider.

You are entitled to form your own opinion no doubt.

> 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.

ATMEL fuse bits behave like "real" fuse bits you refer to in that once
you blow it you cannot mend it back, except when you want to recover
the chip while losing all software loaded onto it.

This recovery option IMHO this useful feature, that you "mend" the
blown fuse bit *after* (and only after) the entire on-chip flash
memory is erased.

If for any reason the on-chip flash was not completely erased (for
example if  it was interrupted by novel means), the fuse bits will not
mend.  This makes it protection far more robust and the LPC scheme has
no comparision.

> What by overclocking and/or running the micrcontroller at marginal or 
> execssive voltages?

No, but by operating the boot loader "beyond specifications" as you
put it.  It would be naive to assume that would-be attackers will not
feed CSI with data that the programmers had not anticipated.  I have
explained how I was able to crash the CSI.

> 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.

I think you started on the wrong premise by narrowly defining "thing"
as an instruction.

In the boot loader I looked into, the implementors thought it was
necessary to turn of JTAG in minimum of three instruction cycles. 
They could have made it four and avoid trading off exception handling
but they did not.

Now from your findings, it appears that they have added five
instructions to this window of opportunity.  This begs the question as
to why?

Are adding instructions in area reserved for vectors without
consideration of its impact when boot loader triggers an exception? 
Could it be that they are trading off pressing need to fix MAM.1 bug
with a further increase in the window of opportunity?

You an I cannot answer these questions and there is little to be
served by emotionally charged speculations.  I am satisfied I do not
know the answers, and I chose not to include the boot loader into my
trust domain until I know more.

> 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?

As I said, feel free to make any assumptions you want.  I have not
mislead you or anyone else.

I was provided with a set of assumptions and based on which to express
my opinion. I did just that..  You do not have to agree with it.

Raising the same issue over and over again just serves to solicits
rebuttals like this one where there is a component of repetition.

> 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.

Eh?  When the manual specifies RAM as starting at 0x40000000 it would
be ludicrous to suggest that this address is dependent on endian-ness.

I see a red herring here.

Jaya