first_app_load.html
5.83 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
<html>
<head>
<title>Requirements for Boot Application Load</title>
</head>
<body>
<h1>
<p align="center">
Requirements for Boot Application Load
</p>
</h1>
The boot application is the initial application loaded by the secure
kernel (SK) when the system comes out of reset. This document defines
the requirements regarding this loading process that impact module
(i.e., external) flash storage of the boot-app eTicket and binary. The
requirements will be summarized first, followed by a set of
specifications for flash and eTicket usage that satisfy the
requirements.
<p>
Requirements:
<ul>
<li> No fundamental knowledge of FS data structures is coded into
the SK. Although the SK will make assumptions regarding external
flash layout to load the boot-app, these will not ultimately
constrain the form of key FS structures.
<li> A robust update of the boot-app by an application running on
the player must be possible. This means that if power is lost
at an inopportune time a workable version of the boot-app
must be loadable by the SK (primarily for future).
<li> The boot-app eTicket must be a standard eTicket with the
exception that is not personalized to a particular player.
</ul>
Specifications supporting requirements:
<ul>
<li> Two copies of the the boot-app eTicket will reside on the first
two good blocks (note discussion <a href=#blocks>below</a>)
that follow the SK flash image. A sequence number will be
written to spare area byte 512 to indicate which version is
most recent. To protect against single bit errors in this byte,
a 2 bit sequence number will be used that is repeated 3 times
within the byte. In addition, the last 2 bits in the byte will
be zero so that an erased block may be considered as an
intended version of the eTicket that was unable to be
completely written (due to power down or other problem).
<li> The boot-app eTicket block will use spare area bytes 512 and
513 to form a 16-bit offset from the next block to the first
block holding boot-app binary data (i.e., an offset of 0
implies the next block after the eTicket block). There is no
per-page ecc protection of this offset, but it is repeated in
every page so there is no need (if only one of the multiple
copies contains a single bit error this is simple to detect).
<li> Boot-app binary blocks will use spare area bytes 512 and 513
to form a 16-bit offset to the next block. These bytes are
encoded as they were for the eTicket block.
<li> The boot-app eTicket contents are typical but the following are
required. First, the BBID field must have all '1' bits. Second,
the bit determining if the "sensitive" section is encrypted
will indicate yes. The SK will not match the BBID field to the
player BBID when this field contains all '1' bits in the
eTicket. Further, when the BBID field is all '1' bits the SK
will decrypt the encrypted portion of the eTicket using a key
stored in internal, secure flash.
</ul>
<p>
Some implications of the specifications are considered below.
<p>
The assumed scheme for updating the boot-app in a robust manner is:
<ol>
<li> write a new version of the boot-app binary to flash
<li> write the eTicket, assigning the next sequence number, by
erasing the block then writing each page from last to
first. The write of the first page in the block (which is
done last) represents the commit operation due to the sequence
number becoming valid. The offset to the boot-app binary now
links this eTicket to the blocks holding the associated
boot-app.
<li> reclaim the blocks holding the old boot-app binary if
this is necessary.
</ol>
As a result of this scheme, the SK only needs to read the spare data
in it's block search to determine which block holds the appropriate
eTicket.
<p>
Also, thise scheme does not initially require we have space for
two copies of the boot-app. This is only the case when we actually
need to update in an environment that could pose trouble. Initially,
we would only waste a single block for a bogus second copy of the
boot-app eTicket. The importance of building this capability into
the SK now is that the SK cannot be updated after the player ships.
We could simplify the boot-app loading by some degree if this
robust update requirement is removed, but the set of specifications
does not appear to be overly complex.
<p>
<a name="blocks">
The flash block-size considered when searching for the boot-app
eTicket must be the maximum value for the erasable block-size of any
flash part we consider using. This is because of the sequencing
between the 2 eTicket blocks. If just after the first copies' block
is erased power was lost, and if the SK was assuming a smaller
blocksize, it would misinterpret a portion of this erased block as the
second eTicket. There are probably schemes to work around this, but
the two most likely block sizes we will encounter are 16KB and
32KB. So, assuming a 32KB bock-size for this purpose is not too
wastefull.
<p>
The eTicket specification for loading the boot-app also provides a
general mechanism for loading personalized apps via the SK. However,
the boot-app will need to setup an appropriate ATB table before it
calls the SK API function to load such an app, because the SK may
assume the contiguous address space and use compatible-mode cartridge
DMAs that automatically load from flash and decrypt. Alternatively, we
could employ to all content the same spare area block chaining as done
for the boot-app, and the SK could use the same code for loading (even
though the ATB version of the code is simpler, the SK still needs the
version described in this document for loading the boot-app).
</body>