> >>> If its FLASH, then its reprogrammable [...]
> >> Yes, but if it's soldered to the board, it's only as reflashable as
> >> the surrounding electronics makes it.
> > It's hard to believe Sun flashes the devices and *then* solders them
> > to the board (though this is quite possible for high volume builds
> > *if* the flashes are all *identical* -- i.e. no serial numbers!)
>
> Why would that be a necessary condition?  Or am I just exposing my
> ignorance of high-volume manufacturing?  I can't see any reason they
> couldn't have a serial number, incremented each time one is flashed, in
> the flashing equipment.

It *isn't* a "necessary condition".  Rather, a *practical* one -- depending
on what sort of equipment is used to flash the devices.  Note that Sun
could conceivably outsource that task -- having the vendor "serialize"
(or otherwise "customize") the devices.  Depends on what they need
by way of "customization" and what they are willing to pay for it.  It
has always seemed easier IMO to let the product program itself.
Mate it to a (simple) fixture, let it sit there for 30 seconds and then move
on
to the next one...

E.g., many of the gizmos I've designed have calibrations and other
option settings installed at time of manufacture.  So, in my case, I
want the boards built with virgin parts that "I" can program in-circuit.
One of the wins of flash is that reprogramming *is* so easy.  So,
I can put a burn-in routine in the flash, shake and bake it for 72 hours,
then burn the "real" code into the flash along with the custom tweeks.
It is conceivable that I could buy the flashes preprogrammed with the
shake-and-bake code but that just means tying the vendor into the
manufacturing loop more than I would like (i.e. if I want to change the
test routines, I don't want to have to worry about how many
preprogrammed devices will need to be REprogrammed... don't
want to have to formally convey the new code image to the vendor, etc.

> However, if they weren't going to design the board to reflash them,
> they'd use a mask ROM rather than flash.

Exactly.  Masked ROM sucked because it required the vendor to become
more involved in the manufacturing cycle, reduced your flexibility to
make changes, etc.  I.e. all the issues above...

> > So, chances are, there are some provisions on the board already to
> > flash the devices "in circuit" with or without the aid of the
> > processor.
>
> ISTR someone saying that the existing code _is_ willing to reflash it,
> provided the new code is suitably signed.

Yes.  But the signature is the pisser.  I am suggesting that the
"existing code" had to get in the Flash *somehow*.  And, I am
further suggesting that it got in there *after* the device was
mated to the PCB (i.e. not preprogrammed by the vendor
prior to assembly).  So, poking around might give some insight.
(e.g., a conspicuous jumper labeled "FLASH ICT" or "FLASH
JTAG", etc.)

> That means that either (a) someone needs to forge a signature or (b)
> someone has to find a security hole in some existing already-signed
> version (not necessarily the latest, as long as it's one existing
> sunrays are willing to flash).
>
> A thought: how many NetBSD folk are there who'd be willing to let some
> of their cycles be used in a distributed attack on the signature
> scheme?  We don't have to completely break the scheme, just produce
> _one_ forged signature, for a "grappling hook" that's willing to flash
> the _real_ NetBSD bootcode.  I don't know the signature scheme in use,
> but forging a signature is probably what I've seen called
> "embarrassingly parallel", so that many widely distributed machines can
> be usefully brought to bear.  Of course, I also don't know the
> signature scheme well enough to know whether it's practical to do even
> _with_ distributed processing power.
>
> The big problem is not cracking one sunray, but rather making it
> possible for random sunray owners out there to crack their sunrays,

Are all images signed using the same key?  I.e. can you FTP
*one* "good" image and install it on N different machines?
Does anything in the targeted machine interact/alter the
image installed?  (e.g., wrapping the serial number into the
hash, etc.)

> without needing to invest a dozen times the sunray's cost in JTAG
> interfaces or ICE boards for the cpu in question.  Thus the
> signature-forging question.

JTAG interface is a few low speed pins on a parallel port.  E.g., you
can "build" one by soldering a few wires to a DB25 and writing a piece
of code to tweek the pins in question.  Vendors often provide
free Pea Sea tools to do this via "LPT" port...

Biggest hassle is figuring out *if* the interface exists, etc.
Any docs on the CPU in question?

What sort of packaging technology (industry part number?)
does the flash use?  May be possible to solder something
"piggy-back" to the existiing flash and leave the old one in
place (disabled, of course).

--don