Thank you for raising your displeasure with my references to ATMEL.
I do not advocate any particular device or manufacturer. I work on
any device from any manufacturer that I am asked to work on.
I developed the AVR boot loader for laboratory use. It worked so well
that other clients started using it as-is for other purposes.
Different requirements led to I being asked to repeat this for the
LPC. I found problems. Philips did not respond adequately. So I
raised the issues in this forum.
I can assure you I have no desire whatsoever to be anywhere in the
vicinity of the "class action" one poster quite vexatiously
referred
to. Neither was it my intentinon to get you or anyone to use ATMEL.
Jaya
--- In lpc2000@lpc2..., "rtstofer" <rstofer@p...> wrote: >
>
> > While it takes just one test to show a security vulnerability, is
not
> > feasible (or valid) to claim a system is secure (or assure quality)
> by
> > testing alone.
>
> True, security can never be proven. So why not review the claims of
> Philips and make a decision: I believe therefore I will buy. I don't
> believe so I'll use Atmel.
>
> If you think Philips will post the code or describe the internals on
> this forum, I think you are mistaken.
>
> Stay with Atmel.
>
> Richard
>
> While it takes just one test to show a security
vulnerability, is not
> feasible (or valid) to claim a system is secure (or assure quality) by > testing alone.
True, security can never be proven. So why not review the claims of
Philips and make a decision: I believe therefore I will buy. I don't
believe so I'll use Atmel.
If you think Philips will post the code or describe the internals on
this forum, I think you are mistaken.
Stay with Atmel.
Richard
Reply by jayasooriah●January 4, 20062006-01-04
--- In lpc2000@lpc2..., Dominic Rath <Dominic.Rath@g...> wrote: > JTAG is enabled after the chip comes out of
reset,
> and it is disabled on the third instruction.
I have stated this from disassembling the code.
> I've tested this by applying a continous TCK
and
> monitoring the output (see my posts in the original thread).
> The bootloader then checks the value present at 0x1fc,
> and reenables JTAG if it didn't find the 0x87654321.
Disassembly is proof enough. No need for testing.
> You can't exploit this window because on
ARM7TDMI-S cores
> the JTAG input is synchronized with the processor clock
> (hence the RTCK carrying a synchronized version of TCK).
Is this is documented anywhere?
While it takes just one test to show a security vulnerability, is not
feasible (or valid) to claim a system is secure (or assure quality) by
testing alone.
There is a lot more that can be done via the JTAG inteface than what
is documented.
