flash_layout.html
6.35 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
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>/tmp/n46software.html</title>
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
</head>
<body>
<h2>Flash Layout</h2>
14/02/2003<br>
<br>
The flash layout is shown in the figure below:<br>
<br>
<br>
<img
src="flash_layout.gif"
alt="flash layout image" width="569" height="524"><br>
<br>
The flash is divided into a "system area" and a file system. The system
area contains information used for booting the system and starting the initial
system application. The system area is located at the start of the
flash device starting at block 0. Files (or blobs) of data in the system
area placed at locations that can be computed using simple algorithms that
are independent of the file system. Space is reserved on the flash
for the largest supported system area size. Currently, the system area
contains:<br>
<ul>
<li>Secure Kernel (4 16K blocks starting at address zero)</li>
<li>System App "license 0" which containing all of the licensing information
necessary for the secure kernel to find and boot the system application.
(1 16K block)</li>
<li>System App "license 1", a second set of licensing information to allow
robust updates of the system application using a ping-ponging scheme. (1
16K block)</li>
<li>System Application 0, the blocks of data of the system application.
The system application is the main application that the user interacts
with, to launch games. (<= 256K) The system application is
compressed and occupies less than 256K (16 blocks).</li>
<li>System application 1, this is space for a second copy of the system
application. In the initial release no space is reserved for the application,
but space is reserved for the license</li>
</ul>
The current amount of space reserved in the system area is (4+1+1+16) =
22 blocks + 2 spare blocks (for future bad blocks) = 384K.<br>
<h3>File System</h3>
The remainder of the flash is devoted to the file system. The file
system contains a set of system files containing tickets, certificates, CRLs,
and files containing game applications. The file system supports a
flat namespace, using a simple linked block allocation table, followed by
an inode table. The file system is growable and uses one 16K block
for metadata per 64MB of flash. The metadata blocks are stored contiguously
starting at the opposite end of the flash device. The metadata block
reservation scheme reserves 3 blocks per 64MB of flash (2 for ping-ponging,
one spare for bad block). Each 64MB FAT has room for ~400 files.<br>
<br>
The set of system files is as follows:<br>
<ul>
<li>ticket.sys - all game license and metadata information -- array of
BbTicket structures (2+ blocks) </li>
<li>key.sys - re-encryption key list + state -- a BbRecryptKeyList structure
(1 block) </li>
<li>crl.sys - certificate revocation list for ticket servers -- a BbCRL
structure (1 block) </li>
<li>cert.sys - certificate chain for ticket server communication --
an array of BbCertificate structures (1 block) </li>
<li>id.sys - player id and certificate -- a single BbId item (1 block)
</li>
<li>state.sys - game state saved and restored by system application --
tbd (1 block)</li>
<li>sgnstate.sys - saved state signed by the secure kernel -- tbd (1 block)</li>
<li>xxxxxxxx.gam - game applications (name is content id as 8 hex digits)</li>
</ul>
For a 64MB bbcard, we assume that system files nominally occupy ~8 blocks
(128KB), metadata (2+1) blocks, system area (22+2) blocks, furthermore
we assume approximately 2% bad blocks (80 on 64MB). Therefore there
is approximately 4096 - 80 - 8 - 2 - 22 = 3984 = 62.5MB. This
is the amount of space remaining for game applications and game state. Conservatily
we should assume another 128KB for system use. <br>
<br>
FAT Format:<br>
<br>
version/checksum<br>
block list [8192 bytes]<br>
inode table [8000 bytes]<br>
<br>
Inode:<br>
8.3 name<br>
type (for future use)<br>
4 byte size<br>
24-bit block pointer<br>
<h3>Robustness</h3>
Using ping-ponging, sequence numbers, and checksums, the system software
can provide some degree of robustness in the presence of a failure during
flash memory update. These failures may occur from loss of power or
the user prematurely removing the bbcard. The objectives are to avoid
corrupting files in the file system or the file system metadata, and to try
to maintain a playable card at all times. We assume that failures can
occur at the depot and at the player, but the characteristics are somewhat
different.<br>
<br>
The depot can initialize a card, update the system area, or add and delete
files from the filesystem. From the depot, bbcard initialization is
not robust (if a card has nothing on it, it by definition can't be a robust
operation). File system updates are robust in the sense that metadata
operations are performed atomically, so file additions and deletions are
performed robustly, and each operation succeeds fails. Updates within
a file are generally not robust. Additional system software must implement
robust update algorithms for files where this is required. In general,
the depot should delete files and recreate them (e.g., the ticket file),
warning the customer when a bbcard is removed prematurely. In this
way, the contents of files will never be in doubt, but an undisciplined user
may be left with an unplayable bbcard. However, the depot should be
able to install any missing file when the bbcard is reinserted in the depot.<br>
<br>
System area updates are used to update the system application. If double
buffering is used, they are robust. If we choose to not reserver space
for double buffering, then an undisciplined customer can create a non-playable
bbcard. However, reinserting it in the depot will install the system
app without any loss of information.<br>
<br>
The player performs writes to update the re-encryption key list, and game
state. The system application manipulates these files and must make
extra efforts to avoid corrupting them or losing data (e.g., double buffering
the key file). If we support double buffered system apps, then the
player can also update the system app robustly. <br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>