Fusing instructions #1195
Fusing instructions #1195
Conversation
Signed-off-by: Filip Gołaś <filip.golas@3mdeb.com>
Signed-off-by: Filip Gołaś <filip.golas@3mdeb.com>
Signed-off-by: Filip Gołaś <filip.golas@3mdeb.com>
philipanda
force-pushed
the
fusing_instructions
branch
from
3cd1589 to
b9ee56f
Compare
|
The pre-commit has wreaked havoc on the lists in the file. |
Signed-off-by: Filip Gołaś <filip.golas@3mdeb.com>
philipanda
force-pushed
the
fusing_instructions
branch
from
c1393e7 to
069cba9
Compare
| This operation is irreversible and can seriously hinder the devices | ||
| usability for the sake of security. Make sure you understand the |
There was a problem hiding this comment.
and can seriously hinder the devices
usability
What exactly? Which aspects of usability could be affected after fusing?
There was a problem hiding this comment.
Refer to Glossary / Dasharo TrustRoot
for more details.
The details are already described there should anyone be interested in more details like what functionality could be hindered
| version: 2022-08-31_cbff21b | ||
| ``` | ||
| ## Fusing the device vendor keys |
There was a problem hiding this comment.
I am confused by this title. Users don’t fuse the keys; they fuse the device.
A better alternative could be: "Fusing the device to enable Dasharo TrustRoot”
There was a problem hiding this comment.
Where is this vocabulary defined?
I believe both versions would be colloquial, as if we would be precise, we should say that we are blowing the fuses that allow write access to the keys saved in the CPU.
I don't think one version is better than the other, but knowing that there are many more fuses unrelated to Intel Boot Guard or Dasharo TrustRoot available in most CPUs, I'd say that fusing the device is more confusing. Please prove me wrong if that's not the case.
There was a problem hiding this comment.
We have named this option in DTS, which you are describing in the documentation, “Fuse Platform.” To be consistent, I think it is best to keep this naming and add the title: “Fuse Platform to enable Dasharo TrustRoot.”
There was a problem hiding this comment.
I see, if it's just about consistency with DTS then it makes sense, I'll change it
There was a problem hiding this comment.
I see, if it's just about consistency with DTS then it makes sense, I'll change it
| To perform fusing procedure: | ||
| 1. Make sure a power supply is connected to the device if it is battery powered | ||
| 2. Make sure the device has Dasharo firmware and the support for Dasharo |
There was a problem hiding this comment.
How can users check this? At the very least, we should have a link to the supported hardware page
There was a problem hiding this comment.
There is none at this moment
There was a problem hiding this comment.
There is none at this moment
What does “none” refer to?
There was a problem hiding this comment.
It refers to the lack of such list as far as I can tell.
We have some similar lists in the docs and they often become outdated, like it was the case with Firmware Update Mode and Capsule Updates some time ago.
In this case it could be better to make sure the option to "Fuse Platform" only shows on supported devices or depend on the feature to inform in a user friendly way about the lack of support for given device.
There was a problem hiding this comment.
It refers to the lack of such list as far as I can tell.
We have some similar lists in the docs and they often become outdated, like it was the case with Firmware Update Mode and Capsule Updates some time ago.
In this case it could be better to make sure the option to "Fuse Platform" only shows on supported devices or depend on the feature to inform in a user friendly way about the lack of support for given device.
There was a problem hiding this comment.
Made a script that generates the list of trustroot support based on DTS configs - if DTS supports fusing, then it appears on the list #1197 (comment)
Could be used in a CI of some sort.
It should be trivial to extend that to capsule updates
There was a problem hiding this comment.
Would you like a table like that to be created somewhere?
Or maybe automate it straight away?
There was a problem hiding this comment.
We have a page with supported hardware: https://docs.dasharo.com/variants/overview/
There was a problem hiding this comment.
That's a table of the Dasharo supported hardware as a whole, not the hardware that supports the feature of Dasharo TrustRoot.
Some information about feature support can be found in test matrices of some devices (https://docs.dasharo.com/variants/dell_optiplex/test-matrix/), some in those tables for some features (https://docs.dasharo.com/kb/firmware-update-mode/#supported-devices, https://docs.dasharo.com/guides/capsule-update/#supported-devices), some are not documented at all as we don't have a well defined list of "features" Dasharo/open-source-firmware-validation#886
Should a list like that, be created, all of those places could be replaced with more solid source. It is deeply connected with the fact that if we define such list, the test cases we run on the devices could potentially be determined automatically.
Creating such list of features and defining how the features and tests depend, cause and exclude each other would be a major stretch and require some good planning, but is definitely possible. It's just a complex logic equation that if well defined in some human readable format could be processed by a computer.
| The decision to fuse the keys requires the user to explicitly opt-in. | ||
| Updating the firmware will never fuse the device on its own. | ||
| To perform fusing procedure: |
There was a problem hiding this comment.
| To perform fusing procedure: | |
| To perform the fusing procedure: |
No description provided.