[Arm-netbook] defining the eoma68 eeprom usage

[luke.leighton]

On Mon, Nov 4, 2013 at 9:57 AM, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Sunday, November 3, 2013 11:03:15 luke.leighton wrote:
>> hi aaron, thanks for joining in here.  most welcome.
>
> :)
>
>> On Sun, Nov 3, 2013 at 9:34 AM, Aaron J. Seigo <aseigo at kde.org> wrote:
>> > "The EEPROM MUST NOT be used for the storage of user data: it is reserved
>> > exclusively for EOMA-68."
>>
>>  yes.  my concerns here are that the EEPROM would be overwritten by
>> user applications otherwise, potentially destroying the ability of CPU
>> Cards to identify the device.
>
> this will depend on the device. for an engineering board, you almost certainly
> want this ability.

 yes.  engineering boards would not be classed as "mass-volume
end-user" boards.  the requirements are very different.  EOMA68 is
designed as a mass-volume standard.

> for a security device, you probably don’t.

 a security device would be an end-user board.

> since being able to write to the eeprom once it leaves the factory is a
> decision made in the choice of eeprom and the PCB writing, i’d suggest leaving
> this up to the device and simply note in the spec the pros/cons of each.

 my feeling is that it has to be stronger than that.  the risks of
mass-returns in the context of mass-volume distribution are too great.
 what i think i will do is put in the spec that end-user applications
(including the linux kernel and boot software) should assume that the
EEPROM has been made write-only, and that methods for updating it for
firmware-update should be taken into consideration during the hardware
design phase.

 engineering boards would be completely exempt from this inasmuch as
the engineer-types would be doing much riskier things.  and they're a
smaller market.


>>  the hardware's not going to change, so why would the data
>> representing it change?
>
> the device id could be changed. consider people creating custom solutions
> using a generic engineering kit as an example. not only can they wire things
> to the 44 pin DIL, but they may wish to give their project a custom ID.

 yes.  not a problem.

>> > My understanding from past threads on the matter is that currently the
>> > only
>> > specified usage for this by EOMA-68 is a product ID string + device node
>> > tree.
>>  there was some debate about whether device node trees *plural* would
>> be more appropriate - one per "thing".  e.g. "GPIO pin 5" would have
>
> yes, this is an entirely other discussion, namely: “What should the device
> node page(s) format be?"

 ack!

>> > as well as vendor specific additions would be golden.
>>
>>  ah.  right.  knowing partly the answer already [and thank you for
>> agreeing to join the list to discuss this!], i have to ask, for the
>> benefit of the list: what _kind_ of vendor-specific additions?
>> specific examples, general examples, doesn't matter.
>
> encryption keys in hardware.

 then a crypto chip should be used, or a SoC which has TPM, or has a
bootloader area or on-board secure PROM - *anything* but an open
readable EEPROM.

 remember that the difference between the NAND on the CPU Card, the
EEPROM on the I/O board and the NAND on the ATSAM4S as far as security
is concerned is absolutely zero.

 in the case of the flying squirrel, if encryption keys are to be
stored anywhere they can be stored in the on-board NAND of the
ATSAM4S, which has i think 128k available.  if you want me to make it
possible at factory-time to disable NAND-erase (via an internal jumper
or something) then i need to know very soon.  otherwise the NAND could
be reset (factory-erased) by simply pulling a GPIO pin high over
EOMA68 GPIO and the ATSAM4S will sit waiting in USB-upload mode.

if that's disableable then you have a means to upload a program and
have it _stay_ there, with a proper crypto protocol / handshake
implemented in c that would prevent and prohibit access to the
encryption keys until the correct authorisation had been given.

this would be much more secure, would be zero cost in hardware terms
and would also have the benefit of not risking product destruction and
destruction of the efforts to create a mass-volume modular standard.

>>   i recommend having at least one byte saying "capabilities", as the
>> first byte.  then you can read that first byte and go "oh.  bit {say}
>> 5 is set!  that means we use the new-spangly-expanded-data-format"
>> which happens to be that you use 32-bit addressing not 16-bit for
>> example.  8th bit you set to be "escape sequence".
>
> good point; so we’ll put another 4 byte header at the front of the whole
> thing. i had such a thing in my first draft, but dropped it as unnecessary
> overhead .. but a version byte makes lots of sense.

 _capabilities_ byte.  there's a big big difference.

> 4 bytes for the data header so we can fetch it all with a single
> i2c_smbus_read_word_data and have a checksum, etc. so:
>
> Address         Size                Value
> ======          ===                     ====
> 0x00            2                       Capabilities byte
> 0x02            1                       Checksum byte
> 0x03            1                       Reserved
>
> We would leave the capabilities bytes as 0x00 for now, and mark all bits
> reserved.

 ack.

> This would give us 16 ‘capabilities’ to twiddle with in future. We
> have another reserved byte in their for future use and a checksum byte.

 good idea.

> I briefly considered using that reserved byte for a page count, but it only
> saves 2 bytes in total, didn’t seem worth it, especially since that would not
> give us a “total amount of data to read from the eeprom”.
>
> If we really wanted to get fancypants, we could add another 4 byte word that
> is the total size of the EOMA68 paged data block and then read the whole thing
> in one go from the EEPROM. I’m not sure there is really any benefit to this,
> however.

 complexity.

> We can play with this an other options when we try it on actual hardware, of
> course.

 agreed.

>>  then, yes!  you can set one of the bits as "there is a checksum".
>> another way to do this is to have a checksum "page".  hmm, so many
>> possibilities...
>>
>> > Page identifiers would be things like: "0x01 Device ID".
>>
>>  originally i was going to follow the principle of USB class : vendor.
>>  but now that i think about it this is best reserved for an actual
>> in-page piece of information.  so there would be "0x01 Device ID Page
>> Info" then a page with that type would have... oh you describe it
>> below already :)
>
> even the USB standard mandates having all the data described below on the
> device. only the USB standard is really poorly done: 16 bits for all the USB
> manufacturers in the world? 16 bits for all the devices any one manufacturer
> will ever make? meh.

 :)

ok i have to go over the rest later.

l.