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
flashrom: Add a plugin for updating using the flashrom command line tool #295
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a more general comment, you should add flashrom and bubblewrap to the dependencies.txt
for all the distro packages.
<?xml version="1.0" encoding="UTF-8"?> | ||
<!-- Copyright 2017 Richard Hughes <richard@hughsie.com> --> | ||
<component type="firmware"> | ||
<id>com.Flashrom.Laptop.firmware</id> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any particular reason to capitalize Laptop and Flashrom?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just example text really.
</p> | ||
</description> | ||
<provides> | ||
<firmware type="flashed">a0ce5085-2dea-5086-ae72-45810a186ad0</firmware> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A comment on how this GUID was generate would be good
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
|
||
<!-- only newer versions of fwupd know how to write to this hardware --> | ||
<requires> | ||
<id compare="ge" version="0.9.7">org.freedesktop.fwupd</id> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably match 1.x.x as that's when the plugin will merge in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
fu_plugin_set_status (plugin, FWUPD_STATUS_DEVICE_VERIFY); | ||
//FIXME get percentage completion... | ||
g_debug ("got '%s'", line); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Obviously sort this out before merging
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm actually waiting for hardware to know how to parse this; the dummy flashrom driver I've been using doesn't return percentage reports. :/ I've asked on the flashrom mailing list about the creation of a libflashrom which would be much better to use, but such a think might be a long time waiting.
@ximion can I get hold of the flashrom --verbose output please so I know what to parse please. If the Purism guys can get some hardware to me (even just a reconditioned mainboard) then that would make this much easier to test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've guessed at this now, confirmation required of course.
if (g_strcmp0 (line, "Writing flash...") == 0) | ||
fu_plugin_set_status (plugin, FWUPD_STATUS_DEVICE_WRITE); | ||
//FIXME get percentage completion... | ||
g_debug ("got '%s'", line); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
likewise
GError **error) | ||
{ | ||
FuPluginData *data = fu_plugin_get_data (plugin); | ||
g_autofree gchar *flashrom_fn = NULL; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unused AFAICT
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
g_autofree gchar *firmware_fn = NULL; | ||
g_autofree gchar *tmpdir = NULL; | ||
const gchar *argv[] = { | ||
"/xxx/flashrom", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this directly be initialized to data->flashrom_fn
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
src/fu-quirks.h
Outdated
* | ||
* When the system motherboard can be updated using flashrom, this quirk maps | ||
* a hardware ID to a device ID. | ||
* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Flashrom can be used for more than just system motherboards can't it? It might make sense to be more general in this regard. For example add a quirk that represents system motherboard, and then a different one that represents some other random device (not sure what arguments flashrom
uses to represent access to something other than internal:laptop
though).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've never seen flashrom update anything other than the BIOS in the wild -- I know it can do things like network cards, but I'm really pushing vendors to use UEFI for that kind of thing -- flashrom is a last ditch effort really.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK probably fine to keep it this way and if the need arises it can be changed some then.
<custom> | ||
<value key="fwupd::BuilderScript">startup.sh</value> | ||
<value key="fwupd::BuilderOutput">firmware.bin</value> | ||
</custom> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not obvious that these are called coming into the update function. I think you should add something in the readme or at least gtk-doc documentation for the flashrom plugin to indicate that's how this is working.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is already documentation in (the installed) data/builder/README.md but I can add something to the readme.md too
plugins/meson.build
Outdated
@@ -1,5 +1,6 @@ | |||
subdir('dfu') | |||
subdir('ebitdo') | |||
subdir('flashrom') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be good to make this plugin optional by meson config option (but default on). Eg thinking with a RHEL hat on, I'm not sure it's something that should be on RHEL without an explicit ask from a customer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the logic for not including it in RHEL? Perhaps that the flashrom update mechanism is inherently riskier than a UEFI capsule update?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah inherently riskier is exactly what I was getting at. There's no validation of the signature of a payload.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, agree. Is flashing an unsigned system firmware from the LVFS more risky than not applying a security update? My argument would be you remove the layer of hardware validation, and fall back to just the two layers of LVFS+fwupd policy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose and if flashrom the runtime dep isn't installed by deafult yet this is an extremely small surface area.
These are runtime deps tho, not BuildRequires... |
Yeah so debian/control and spec.in will both want the runtime deps included then too |
b88f03f
to
1bf1636
Compare
How do you do a runtime dep in Debian out of interest? Google wasn't much help. For Fedora I've just added bubblewrap, I don't know if a 600Kb dep of flashrom is what we want in general. I suppose if we "support" it in fwupd then we do need to runtime require it. I'd still much rather depend on a libflashrom-dev although that might be some waiting. |
Since these are "optional", I think it makes sense to mark Keeping
In ubuntu land there will be some paper work with getting the various deps installed by default (in the regular public image), but I'll sort that out. |
1bf1636
to
1cbfa7f
Compare
1cbfa7f
to
cc5a8ed
Compare
cc5a8ed
to
8ab897b
Compare
8ab897b
to
ae31dfb
Compare
ae31dfb
to
9d5d1e1
Compare
9d5d1e1
to
95c2a59
Compare
e9183b7
to
88db1d4
Compare
FWUPD_ERROR, | ||
FWUPD_ERROR_NOT_SUPPORTED, | ||
"flashrom is not installed"); | ||
return FALSE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we've been switching over to marking devices not updatable and setting UpdateError
, I think this is a good candidate to do the same rather than fail plugin startup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree. I'm still not sure if I want to merge this plugin or wait for libflashrom to happen. It doesn't seem like the latter is coming any time soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I say update for that change merge it now, and if libflashrom
happens, clean up later, bump up the dependency.
88db1d4
to
8d0c3c0
Compare
8d0c3c0
to
e52c489
Compare
This reworks the old
purism
plugin to be a generic flashrom mechanism that can be used by any vendor by dropping in a quirks file.