Bug#916036: Install fwupd on a default installation

[Philipp Kern]

Hi Mario,

first of all thanks for your pointers!

On 27/12/2018 20:28, mario.limoncie...@dell.com wrote:

Just the fact that the update claims that the hardware only accepts
signed updates or something else? :)


At a minimum a claim.


I will note - although slightly off-topic to the discussion at hand -
that it would be useful to people to be able to run their own repository
of updates and control the rollouts (and staging percentages)
themselves. I'm not actually suggesting that Debian would need to run
their own, but it'd be a useful service to the users who don't want to
send telemetry to the Linux Foundation - and furthermore have a
significant deployment where it's worth canarying the updates.


Entirely doable.  LVFS can be set up locally with the firmware that is 
interesting
uploaded to that "instance".  This will mean setting up a GPG key pair and 
signing
the firmware with that instance as well.

On fwupd clients a "remote" needs to be registered for that instance with the 
public
key and instance location.


So I suppose mirroring would entail fetching the firmware.xml.gz from 
LVFS' CDN and then downloading and rewriting the release locations - 
plus dealing with signing the metadata. That seems fairly straightforward.


If there would be a way to check the provenance of an updater package 
(i.e. not just rely on arbitrary vendor authentication on the backend), 
that'd still be nice.


(Plus percentage-based rollouts, but that's just yet another feature 
request. :)



FYI: Telemetry related to the update is entirely optional and "opt-in" after 
you've
performed an update.
Thanks, I found a note on [1] and if it's indeed per remote, it should 
be fairly easy to manage.



Fair enough. Do you have a pointer for examples of such updates?
Unfortunately I updated my own Dell dock recently from Windows, so I
can't easily check. Mostly I'm interested if it's a proprietary binary
run on the host. That's its own can of worms. (Which technically is true
for the EFI update too, but it's staged from outside of Linux on
boot-up.)


Executing proprietary binaries distributed in the CAB file is against fwupd
philosophy and prohibited.  All code for the plugin that executes in Linux and
is distributed with fwupd must be open source.

fwupd only pulls "payloads" from the CAB files.

Regarding the examples I called out:
You can review the fwupd tree in the plugins/ directory to see the
* thunderbolt/ plugin which uses the kernel Thunderbolt interface
* dell-dock/ plugin which uses kernel USB interfaces
* dell/ plugin which uses a EFI binary for TPM and dock updates
* ebitdo/ plugin which uses kernel USB interfaces
* rts54hid/ rts54hub/ plugins which use kernel USB interfaces

There are many more, you can look more closely at your leisure.

The matching binaries that are on LVFS.
Here's some examples:
Thunderbolt: https://fwupd.org/lvfs/device/4eeb9d07-a96c-56d6-92d3-4a23ee7a6e4a
MST: https://fwupd.org/lvfs/device/be025b25-ca5c-546c-97c6-ee2160ba489d
8bitdo: https://fwupd.org/lvfs/device/8baed357-638e-5b54-b582-0476bf7d6348
TPM: https://fwupd.org/lvfs/device/e58a5f6d-ba78-5f0f-a35f-612f97ca8c9a


I cannot tell you how happy this makes me. This is awesome. Thank you 
(and everyone else who contributed to this effort) for doing the right 
thing! And obviously kudos to Dell for staffing this.


The plugin library seems to be on [2] and there's a sizable set of them. 
Even an AMT updater. :o


Kind regards and thanks
Philipp Kern

[1] 
https://blogs.gnome.org/hughsie/2018/01/10/phoning-home-after-updating-firmware/

[2] https://github.com/hughsie/fwupd/tree/master/plugins

Bug#916036: Install fwupd on a default installation

[Mario.Limonciello]

> Just the fact that the update claims that the hardware only accepts
> signed updates or something else? :)

At a minimum a claim.

> I will note - although slightly off-topic to the discussion at hand -
> that it would be useful to people to be able to run their own repository
> of updates and control the rollouts (and staging percentages)
> themselves. I'm not actually suggesting that Debian would need to run
> their own, but it'd be a useful service to the users who don't want to
> send telemetry to the Linux Foundation - and furthermore have a
> significant deployment where it's worth canarying the updates.

Entirely doable.  LVFS can be set up locally with the firmware that is 
interesting
uploaded to that "instance".  This will mean setting up a GPG key pair and 
signing
the firmware with that instance as well.

On fwupd clients a "remote" needs to be registered for that instance with the 
public
key and instance location.

FYI: Telemetry related to the update is entirely optional and "opt-in" after 
you've
performed an update.

> Fair enough. Do you have a pointer for examples of such updates?
> Unfortunately I updated my own Dell dock recently from Windows, so I
>can't easily check. Mostly I'm interested if it's a proprietary binary
>run on the host. That's its own can of worms. (Which technically is true
>for the EFI update too, but it's staged from outside of Linux on
>boot-up.)

Executing proprietary binaries distributed in the CAB file is against fwupd
philosophy and prohibited.  All code for the plugin that executes in Linux and
is distributed with fwupd must be open source.

fwupd only pulls "payloads" from the CAB files.

Regarding the examples I called out:
You can review the fwupd tree in the plugins/ directory to see the
* thunderbolt/ plugin which uses the kernel Thunderbolt interface
* dell-dock/ plugin which uses kernel USB interfaces
* dell/ plugin which uses a EFI binary for TPM and dock updates
* ebitdo/ plugin which uses kernel USB interfaces
* rts54hid/ rts54hub/ plugins which use kernel USB interfaces

There are many more, you can look more closely at your leisure.

The matching binaries that are on LVFS.
Here's some examples:
Thunderbolt: https://fwupd.org/lvfs/device/4eeb9d07-a96c-56d6-92d3-4a23ee7a6e4a
MST: https://fwupd.org/lvfs/device/be025b25-ca5c-546c-97c6-ee2160ba489d
8bitdo: https://fwupd.org/lvfs/device/8baed357-638e-5b54-b582-0476bf7d6348
TPM: https://fwupd.org/lvfs/device/e58a5f6d-ba78-5f0f-a35f-612f97ca8c9a

Bug#916036: Install fwupd on a default installation

[Philipp Kern]

Hey Mario,

On 2018-12-27 03:52, mario.limoncie...@dell.com wrote:

Something I think worth mentioning is that LVFS is being transitioned
to being run
and managed by the Linux Foundation.


yeah, that's great news.

Interestingly enough the vendor signs a blob (CAB file) and LVFS 
throws

it away and re-signs the blob with its own key. But then again I think
the base assumption is that the contained firmware images are 
themselves

signed as well and the BIOS does a check before ingesting them.


Speaking on behalf of one of the biggest distributors of firmware on 
LVFS (Dell)

I can say that all of the firmware images are signed by Dell PKI
infrastructure and
will not flash on the system if modified.

LVFS is currently in the process of plumbing this information through 
to the U/I

as well.


Just the fact that the update claims that the hardware only accepts 
signed updates or something else? :)



Obviously you end up with the usual concerns like the repository being
able to hold back updates from certain clients. The website's code is
supposedly available on https://github.com/hughsie/lvfs-website/ 
though
and I suppose a transparency effort could solve that particular 
problem,

too.


LVFS is able to prevent distributing updates in two situations:

1) when there are known bad SW combinations (say vendor knew bug
existed in fwupd
1.0.x but was fixed in 1.1.x - set minimum version for the update to be 
1.1.x).

or need to update device XYZ before device ABC.

2) rate limiting of updates
To stage rollouts and monitor optional feedback in the event of a 
problem.


I will note - although slightly off-topic to the discussion at hand - 
that it would be useful to people to be able to run their own repository 
of updates and control the rollouts (and staging percentages) 
themselves. I'm not actually suggesting that Debian would need to run 
their own, but it'd be a useful service to the users who don't want to 
send telemetry to the Linux Foundation - and furthermore have a 
significant deployment where it's worth canarying the updates.



Oh yes. Not just that, also finding the right image to apply and then
figuring out how the hell to apply it is a solved problem with 
EFI-based

fwupdate.


Please keep in mind it's much much more than EFI updates now too.
There are updates
that can apply "in Debian" without a reboot for things like
Thunderbolt controllers, docks,
MST hubs, and various USB devices.


Fair enough. Do you have a pointer for examples of such updates? 
Unfortunately I updated my own Dell dock recently from Windows, so I 
can't easily check. Mostly I'm interested if it's a proprietary binary 
run on the host. That's its own can of worms. (Which technically is true 
for the EFI update too, but it's staged from outside of Linux on 
boot-up.)


Kind regards and thanks
Philipp Kern

Bug#916036: Install fwupd on a default installation

[Mario.Limonciello]

Something I think worth mentioning is that LVFS is being transitioned to being 
run
and managed by the Linux Foundation.

>Interestingly enough the vendor signs a blob (CAB file) and LVFS throws
> it away and re-signs the blob with its own key. But then again I think
> the base assumption is that the contained firmware images are themselves
> signed as well and the BIOS does a check before ingesting them.

Speaking on behalf of one of the biggest distributors of firmware on LVFS (Dell)
I can say that all of the firmware images are signed by Dell PKI infrastructure 
and
will not flash on the system if modified.

LVFS is currently in the process of plumbing this information through to the U/I
as well.

> Obviously you end up with the usual concerns like the repository being
> able to hold back updates from certain clients. The website's code is
> supposedly available on https://github.com/hughsie/lvfs-website/ though
> and I suppose a transparency effort could solve that particular problem,
> too.

LVFS is able to prevent distributing updates in two situations:

1) when there are known bad SW combinations (say vendor knew bug existed in 
fwupd
1.0.x but was fixed in 1.1.x - set minimum version for the update to be 1.1.x).
or need to update device XYZ before device ABC.

2) rate limiting of updates
To stage rollouts and monitor optional feedback in the event of a problem.

> Oh yes. Not just that, also finding the right image to apply and then
> figuring out how the hell to apply it is a solved problem with EFI-based
> fwupdate.

Please keep in mind it's much much more than EFI updates now too.  There are 
updates
that can apply "in Debian" without a reboot for things like Thunderbolt 
controllers, docks, 
MST hubs, and various USB devices.

Bug#916036: Install fwupd on a default installation

[Philipp Kern]

On 26/12/2018 22:32, Steve McIntyre wrote:

On Wed, Dec 26, 2018 at 10:27:35PM +0100, Cyril Brulebois wrote:

Steve McIntyre  (2018-12-26):

Philipp Kern  (2018-12-26):

I'm not sure, though, if there is some philosophical objection here in
that fwupd downloads non-free blobs and/or that Debian does not actually
ship the blobs themselves.


FWIW both parts seem unacceptable to me, esp. in a default installation.


They're not all necessarily non-free, but it's a useful service for
people to make safe firmware updates easy.


How do we know those blobs are safe, and that they won't change all of a
sudden if they aren't hosted on Debian infrastructure?


We *don't* directly, but they blobs are signed and placed online by
the vendors. LVFS (the online backend) is a good Free
Software-friendly service.


Interestingly enough the vendor signs a blob (CAB file) and LVFS throws 
it away and re-signs the blob with its own key. But then again I think 
the base assumption is that the contained firmware images are themselves 
signed as well and the BIOS does a check before ingesting them.


Obviously you end up with the usual concerns like the repository being 
able to hold back updates from certain clients. The website's code is 
supposedly available on https://github.com/hughsie/lvfs-website/ though 
and I suppose a transparency effort could solve that particular problem, 
too.



This is a major step forwards from the old Windows-only ot "boot a DOS
floppy" style of firmware updates.


Oh yes. Not just that, also finding the right image to apply and then 
figuring out how the hell to apply it is a solved problem with EFI-based 
fwupdate.


Kind regards
Philipp Kern

Bug#916036: Install fwupd on a default installation

[Jeremy Bicha]

On Wed, Dec 26, 2018 at 3:09 PM Philipp Kern  wrote:
> I'd have another - and I hope stronger - argument to upgrade the
> dependency from suggests to recommends: gnome-software is actually
> displaying an error when fwupd is not present on the bus (see attached
> screenshot).

I believe I was the one that requested that Paul van Tillburg file
this bug. I intend to make the requested change (have gnome-software
recommend fwupd) soon and I wanted there to be a bug for tracking.

I would have made the change by now except that I forgot to do it sooner.

Thanks,
Jeremy Bicha

Bug#916036: Install fwupd on a default installation

[Luca Boccassi]

On Wed, 2018-12-26 at 21:32 +, Steve McIntyre wrote:
> On Wed, Dec 26, 2018 at 10:27:35PM +0100, Cyril Brulebois wrote:
> > Steve McIntyre  (2018-12-26):
> > > > Philipp Kern  (2018-12-26):
> > > > > I'm not sure, though, if there is some philosophical
> > > > > objection here in
> > > > > that fwupd downloads non-free blobs and/or that Debian does
> > > > > not actually
> > > > > ship the blobs themselves.
> > > > 
> > > > FWIW both parts seem unacceptable to me, esp. in a default
> > > > installation.
> > > 
> > > They're not all necessarily non-free, but it's a useful service
> > > for
> > > people to make safe firmware updates easy.
> > 
> > How do we know those blobs are safe, and that they won't change all
> > of a
> > sudden if they aren't hosted on Debian infrastructure?
> 
> We *don't* directly, but they blobs are signed and placed online by
> the vendors. LVFS (the online backend) is a good Free
> Software-friendly service.
> 
> This is a major step forwards from the old Windows-only ot "boot a
> DOS
> floppy" style of firmware updates.

To add my 2c to that, we also don't know that the firmware that is
installed on the machine at the factory is secure - but we know it's
outdated, and we know that security-related new versions are common
enough to be worth worrying about.

-- 
Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part

Bug#916036: Install fwupd on a default installation

[Steve McIntyre]

On Wed, Dec 26, 2018 at 10:27:35PM +0100, Cyril Brulebois wrote:
>Steve McIntyre  (2018-12-26):
>> >Philipp Kern  (2018-12-26):
>> >> I'm not sure, though, if there is some philosophical objection here in
>> >> that fwupd downloads non-free blobs and/or that Debian does not actually
>> >> ship the blobs themselves.
>> >
>> >FWIW both parts seem unacceptable to me, esp. in a default installation.
>> 
>> They're not all necessarily non-free, but it's a useful service for
>> people to make safe firmware updates easy.
>
>How do we know those blobs are safe, and that they won't change all of a
>sudden if they aren't hosted on Debian infrastructure?

We *don't* directly, but they blobs are signed and placed online by
the vendors. LVFS (the online backend) is a good Free
Software-friendly service.

This is a major step forwards from the old Windows-only ot "boot a DOS
floppy" style of firmware updates.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt

Bug#916036: Install fwupd on a default installation

[Cyril Brulebois]

Steve McIntyre  (2018-12-26):
> >Philipp Kern  (2018-12-26):
> >> I'm not sure, though, if there is some philosophical objection here in
> >> that fwupd downloads non-free blobs and/or that Debian does not actually
> >> ship the blobs themselves.
> >
> >FWIW both parts seem unacceptable to me, esp. in a default installation.
> 
> They're not all necessarily non-free, but it's a useful service for
> people to make safe firmware updates easy.

How do we know those blobs are safe, and that they won't change all of a
sudden if they aren't hosted on Debian infrastructure?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#916036: Install fwupd on a default installation

[Steve McIntyre]

On Wed, Dec 26, 2018 at 09:48:15PM +0100, Cyril Brulebois wrote:
>Hi,
>
>Philipp Kern  (2018-12-26):
>> I'm not sure, though, if there is some philosophical objection here in
>> that fwupd downloads non-free blobs and/or that Debian does not actually
>> ship the blobs themselves.
>
>FWIW both parts seem unacceptable to me, esp. in a default installation.

They're not all necessarily non-free, but it's a useful service for
people to make safe firmware updates easy.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane

Bug#916036: Install fwupd on a default installation

[Cyril Brulebois]

Hi,

Philipp Kern  (2018-12-26):
> I'm not sure, though, if there is some philosophical objection here in
> that fwupd downloads non-free blobs and/or that Debian does not actually
> ship the blobs themselves.

FWIW both parts seem unacceptable to me, esp. in a default installation.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#916036: Install fwupd on a default installation

[Philipp Kern]

severity 916036 normal
thanks

Hi,

I'd have another - and I hope stronger - argument to upgrade the 
dependency from suggests to recommends: gnome-software is actually 
displaying an error when fwupd is not present on the bus (see attached 
screenshot).


But yes, I also second that we really should install this by default. 
I'm not sure if this could (or should) live in discover and how 
important the UI bits present in gnome-software are for this. But BIOS 
update management is becoming more important and now that large vendors 
actually publish their updates in LVFS, we should make these available 
to our users by default as well.


I'm not sure, though, if there is some philosophical objection here in 
that fwupd downloads non-free blobs and/or that Debian does not actually 
ship the blobs themselves.


Kind regards and thanks
Philipp Kern