AR4SI mappings folder #52
Conversation
…ocument Signed-off-by: Thomas Fossati <[email protected]>
thomas-fossati
requested review from
setrofim,
yogeshbdeshpande and
SimonFrost-Arm
|
@SimonFrost-Arm @setrofim @yogeshbdeshpande please review |
ar4si/arm-cca.md
Outdated
| |Hardware (and Firmware)||CONTRAINDICATED_HARDWARE (genuine HW/FW but contraindicated)|TRUSTWORTHY_INSTANCE && some sw-component claims are known-bad| | ||
| |||UNRECOGNIZED_HARDWARE (unrecognised HW/FW)|TRUSTWORTHY_INSTANCE && some sw-component claims couldn’t be found| | ||
| |||GENUINE_HARDWARE (genuine HW/FW)|Same as (TRUSTWORTHY_INSTANCE && APPROVED_BOOT)| | ||
| ||Not clear what is the difference between this and CONTRAINDICATED_HARDWARE?|UNSAFE_HARDWARE (genuine HW/SW but known sec vulns)|TBD (see note)| |
There was a problem hiding this comment.
Not clear what is the difference between this and CONTRAINDICATED_HARDWARE?
CONTRAINDICATED == know exploits
UNSAFE == known vulns (but no know exploits confirmed)
?
There was a problem hiding this comment.
Note for self: this needs corresponding signals in the x-refval.
ar4si/arm-cca.md
Outdated
| |||UNAVAIL_CONFIG_ELEMS|N.A.| | ||
| |||UNSAFE_CONFIG|N.A.| | ||
| |||UNSUPPORTABLE_CONFIG|N.A.| | ||
| |Executables|It looks like an “UNRECOGNIZED_BOOT” is missing… but really the problem here is that this claim conflates run-time and boot-time.|APPROVED_BOOT|if RIM and PV (if provided) match| |
There was a problem hiding this comment.
What is the value of Executables field if RIM and PV do not match? Would the value ever be APPROVED_BOOT in paractice, if the value of the field depends on the subsequent evaluation of REM?
I agree, there should really be a spearate claim for "boot"...
There was a problem hiding this comment.
What is the value of Executables field if RIM and PV do not match?
There is none at the moment. UNRECOGNIZED_BOOT would be it - if it existed.
OK, I will raise an issue in the AR4SI repo for that.
Until then, we have the negative codepoints space to use to define our new experimental semantics.
There was a problem hiding this comment.
ar4si/arm-cca.md
Outdated
| |||APPROVED_RUNTIME|if REM match| | ||
| |||CONTRAINDICATED_RUNTIME|If the verifier has a notion of known-bad REM values (alongside known-good) this can be set in case REM matches known-bad values| | ||
| |||UNRECOGNIZED_RUNTIME|If no REM ref-values match evidence| | ||
| ||Not clear how this differs from CONTRAINDICATED_RUNTIME|UNSAFE_RUNTIME|(could be used as an alternative to CONTRAINDICATED_RUNTIME in the warning tier)| |
There was a problem hiding this comment.
As with hardware, know exploit vs know vuln?
| |||CRYPTO_VALIDATION_FAILED|On failures coming from the Platform token verifier (excluding Realm binding, which is captured in the Realm part)| | ||
| |Instance identity||TRUSTWORTHY_INSTANCE|verification using CPAK is successful and Implementation ID is known (implicitly, from the fact that ref-values associated to it exist)| | ||
| |||UNTRUSTWORTHY_INSTANCE|If the verifier has a notion of known-bad CPAK, then verification using CPAK that is successful but CPAK is known-bad can assert this claim.| | ||
| |||UNRECOGNIZED_INSTANCE|No CPAK found corresponding to the Instance ID or Implementation ID is not known (i.e., there are no ref-values associated to it.)| |
There was a problem hiding this comment.
I would add a clarification Glossary in the end to expand fully what it means to be CPAK ..?
There was a problem hiding this comment.
Since we are talking of a single acronym, adding a glossary is a tad overkill :-)
I'll expand CPAK inline.
Signed-off-by: Thomas Fossati <[email protected]>
Starting with CCA