Skip to content
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

Merged
merged 1 commit into from Aug 28, 2018

Conversation

hughsie
Copy link
Member

@hughsie hughsie commented Nov 3, 2017

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.

@hughsie hughsie requested a review from superm1 November 3, 2017 09:32
Copy link
Member

@superm1 superm1 left a 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>
Copy link
Member

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?

Copy link
Member Author

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>
Copy link
Member

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

Copy link
Member Author

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>
Copy link
Member

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.

Copy link
Member Author

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);
}
Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member Author

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);
Copy link
Member

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;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unused AFAICT

Copy link
Member Author

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",
Copy link
Member

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?

Copy link
Member Author

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.
*
Copy link
Member

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).

Copy link
Member Author

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.

Copy link
Member

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>
Copy link
Member

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.

Copy link
Member Author

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

@@ -1,5 +1,6 @@
subdir('dfu')
subdir('ebitdo')
subdir('flashrom')
Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

@hughsie
Copy link
Member Author

hughsie commented Nov 4, 2017

you should add flashrom and bubblewrap to the dependencies.txt

These are runtime deps tho, not BuildRequires...

@superm1
Copy link
Member

superm1 commented Nov 4, 2017

Yeah so debian/control and spec.in will both want the runtime deps included then too

@hughsie
Copy link
Member Author

hughsie commented Nov 5, 2017

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.

@superm1
Copy link
Member

superm1 commented Nov 6, 2017

How do you do a runtime dep in Debian out of interest?
debian/control add it to the depends: or recommends: line of the package that needs the runtime dep or recommend. So here: https://github.com/hughsie/fwupd/blob/master/contrib/debian/control#L78

Since these are "optional", I think it makes sense to mark bubblewrap as recommends. Recommends are installed by default, but they can be removed and let the package still be functional.

Keeping flashrom out for now sounds fine by me. As these machines are prevalent that use it that can be revisited. I think If it's not installed by default though you should make a few changes:

  1. Rather than abort the plugin if not installed, only avoid adding the "updateable" flag.
  2. Output something in the journal (error or info level) about missing flashrom executable in this instance if one of these devices is found.
  3. Add something to the common errors wiki about this error with a fix for common distros (apt install flashrom; dnf install flashrom)

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.

FWUPD_ERROR,
FWUPD_ERROR_NOT_SUPPORTED,
"flashrom is not installed");
return FALSE;
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

@hughsie hughsie merged commit c165542 into master Aug 28, 2018
@hughsie hughsie deleted the wip/hughsie/purism branch August 28, 2018 08:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants