launch.html
4.68 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
135
136
137
138
139
140
<html>
<head>
<title>Launch Testing</title>
</head>
<body>
<center>
<h1>Launch Testing</h1>
</center>
<h2>Overview</h2>
The goal is to test aspects of launch not covered by other tests
(crl, re-encryption, play limits, ...). This mainly insures all failure modes
during launch are properly handled, so no content may be launched
when the ticket and/or content has an error.
<p>
SW and HW rights are set for an app during launch, so rights testing is
covered here as well.
<h2>SK API Usage</h2>
skLaunchSetup() <br>
skLaunch() <br>
<p>
note: requires sysapp-side library to actually copy content, between
the above calls, according to content-embedded metadata (errata).
<h2>Codepath Analysis</h2>
<h3>general cert chain verification (skLaunchSetup()):</h3>
fail if chainType coded in verifyCertChain() call does not
agree with naming for each member of the chain (per our convention).
this applies to content pub chains and transaction (ticket)
server chains.
<p>
fail if any cert issuer is non-root yet next in chain is NULL.
<p>
fail if any sig in chain is bad.
<p>
though we require the 64 byte strings to be zero padded past the
informative portion, we should test with random garbage instead
of zero-padding???
<h3>app launch (skLaunchSetup(), skLaunch()):</h3>
(skLaunchSetup())
<p>
there are a number of pointer checks <b>that are not tested yet.</b>
these are for the keylist, crls (but these should be tested by crl
tests), ticketBundle and ptrs it includes for the ticket and cert
chains. the cert chains themselves have each ptr expected to be used
sanity checked as well.
<p>
if re-encryption has not previously been completed, launch attempt
should fail (both no started and started but stopped prematurely
need testing). THIS CASE TESTED BY RE-ENCRYPTION TESTS.
<p>
(assume re-encryption complete or not required for remainder)
<p>
fail if "general cert chain verification", above, indicated failure
for cmd or ticket chains.
<p>
fail if ticket bbid does not match v2 value.
<p>
fail if ticket sig is invalid.
<p>
currently fail if eccGenAesKey() or aes_SwDecrypt() fail, but we
probably do not need to check errors on these.
<p>
fail if bad sig on decrypted cmd.
<p>
(skLaunch())
<p>
should test badd input addr (any addr not within first 3M
is problematic since the sysapp may be overwritten). testing is
for "normal" ptr value check in sk.
<p>
access rights are setup. must vary rights to insure bits are used
appropriately.
<p>
if app does not require re-encryption, hash cmdh.size bytes in dram,
starting from addr arg to skLaunch(). if doesn't match cmdh value, fail.
insure hash irrelevant for re-encypted apps.
<h3>sysapp:</h3>
fail if double-bit error on loading sysapp ticket bundle (where block
marked good). NOT TESTED - was tested in boot-code tests, and code is
the same.
<p>
fail if flash module removed during load. <b>Pramila tested by altering sk
to produce delay, and removing card. With unmodified code, nearly impossible
to produce, but no test specifically written for this purpose.</b>
<p>
fail if cmdh cert chain (content pub) doesn't verify.
<p>
fail if sig on cmd (encrypted) fails.
<p>
loadaddr is obtained from sysapp rom header (n64-style). it currently
isn't checked, but a sanity check should be added and the failure
if insane tested. the actual test is part of the rights testing, since
NULL is passed in to produce an immediate failure.
<p>
fail if hash over entire rom fails (4KB rom header no loaded to dram).
<h2>Testing</h2>
<h3>Rights</h3>
The SW/HW access rights are tested by the app in directory
bbapps/sktest/rights. The testapp build and publishing is described in
the README file. For a given rights setting all hw and sw rights bits
are tested. A test on a bit passes if the expected access occurs, so
the test should be published and run with a few different sets of rights
bits to insure both access is denied and granted according to the rights
bits.
<h3>Launch Failure Modes</h3>
The failure mode testing is done by the app in directory
bbapps/sktest/launch. A
<a href="README_launch.txt">README</a> (a snapshot is copied here for
convenience)
file in that directory describes the strategy and publishing for each
test case. For normal app loading via skapi calls, load all published
apps, cert.sys and ticket.sys to the bbcard. The tests are all carried out
by launching the app named sktest_launch (cid 0x00020000).
<p>
For the sysapp case, each sysapp/tik pair must be loaded and the bb must
be re-powered to insure the sysapp will not come up. Note that in this case
a second bbcard is required to enable bringing up the bb to load the next
sysapp/tik combo to be tested.
</body>
</html>