-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate DCU support #79
Comments
@artur-rs Let's take a look on how to integrate the We already have a recipe for it, as it is included in meta-dts: https://github.com/Dasharo/meta-dts/blob/main/meta-dts-distro/recipes-dasharo/dasharo-configuration-utility/dasharo-configuration-utility_git.bb We should consider moving My first suggestion would be to create:
Other suggestions are welcome. This task should start with a proper execution plan. |
We have created the following layers: We have created a spreadsheet to help us to drive the layers' decomposition: https://pad.3mdeb.com/sheet/#/2/sheet/view/roMqhd-jY+4-dM-98AAujCwEXfj-sVQ6FCoWDy8UM+8/ Execution steps:
|
It seems i do not have the access rights to both meta-dasharo and meta-coreboot |
@macpijan I ran |
|
Many of them should be autofixed already after you run this command. Others should be quick to fix via editor global replace feature, or In general, one can also call The fwupd is likely false-positive nad must be excluded, e.g. via codespellx. |
The DCU integration in meta-rte is finalized via these Pull Requests:
This will be ready to be included in the next release of the RTE OS image. |
The feature on firmware side is implemented here: Dasharo/coreboot#605 However please be aware that the current implementation in DCU injects the S/N and UUID into firmware in such a way that it invalidates Vboot signatures and requires re-signing. This means that every user will have to migrate smbios data and re-sign binaries on their devices. It can be done automatically in DTS but it means everyone will be using selfsigned binaries instead of Dasharo-signed binaries. This is not optimal for security and it would not work with Boot Guard, so we do not think this is a reasonable solution. Instead, this feature could be implemented in such a way that S/N and UUID are stored in a separate, unsigned region of the flash, exactly like persistent bootsplash is solved. This would involve changes in firmware but would avoid this problem altogether. DTS and capsule update code would have to be modified to perform UUID and SN migration but that would be safer and simpler than re-signing binaries. It would also work with Boot Guard. |
All right, I am now awaiting those improvements before using this feature. |
The problem you're addressing (if any)
Currently, it is not possible to modify firmware binaries.
Describe the solution you'd like
Being able to modify firmware binaries with the DCU tool from the RTE programmer directly, for example injecting a serial number.
Where is the value to a user, and who might that user be?
The text was updated successfully, but these errors were encountered: