Are there plans for the Pinebook Pro to support LVFS (Linux Vendor Firmware Service)?

[CuriousTommy]

Hello everyone,

About a week ago, I made a reddit post asking about support for LVFS. I am not sure if the Pine64 developers look at the Reddit threads often, so I decided to make an account here to bring awareness on the issue (plus I didn't get a response when I asked on twitter).

I hope you would consider uploading the firmware files to LVFS. This could make checking and updating firmware stupidly easy. Plus the maintainer of the website is willing to help get this working if you send him an email.

Thomas A.

[hmuller]

@CuriousTommy ,

I just performed a cursory review of the lvfs website. What I did not learn in that review is specifically how lvfs secures the firmware from receipt, to storage, and then to dissemination. In other words, how can the end user be reasonably assured that the firmware being used to update a device is in fact from the vendor and not malware? This question assumes the vendor is not publishing malicious firmware as Asus did in the past.


Can you elaborate on that? In my experience stupidly easy is not always better.

[CuriousTommy]

In other words, how can the end user be reasonably assured that the firmware being used to update a device is in fact from the vendor and not malware? This question assumes the vendor is not publishing malicious firmware as Asus did in the past.

Can you elaborate on that? In my experience stupidly easy is not always better.

I would recommend you contact Richard Hughes if you want specific details on your concerns about LVFS.

But from I understand Richard gets in contact with the Vendor to see if they are interested in providing their frimware to the LVFS. Those frimware files comes from the vendors that want to add it.

Edit: This section confirms it.

[ElektromAn]

I don't know what is the purpose of this site is ...
There is a *well* known channel with lkml and other mailing lists, to send binary blobs.

The only thing is/maybe out of tree kernel drivers, which use *outdated* firmware blobs.
In this case the $vendor is already doing the wrong thing is the first place.

He doesn't upstream the kernel driver.
Please have a look at drivers/staging in *any* linux sources tree.
The code quality is bad, and the code is mostly $vendor code.
With buildin security holes, which can crash your kernel.
Sometimes the community is rewriting the driver to met kernel standards.
But sometimes the driver code is *thrown* out staging, because no one
is working on this code and the $vendor has no need to do this.

All you can read in the git logs

[CuriousTommy]

The only thing is/maybe out of tree kernel drivers, which use *outdated* firmware blobs.
In this case the $vendor is already doing the wrong thing is the first place.

He doesn't upstream the kernel driver.
Please have a look at drivers/staging in *any* linux sources tree.
The code quality is bad, and the code is mostly $vendor code.
With buildin security holes, which can crash your kernel.
Sometimes the community is rewriting the driver to met kernel standards.
But sometimes the driver code is *thrown* out staging, because no one
is working on this code and the $vendor has no need to do this.

All you can read in the git logs

LVFS has nothing to do with kernel drivers. LVFS and fwupd are just utilities that allow people to automatically perform firmware updates on devices that have upgradeable firmware (ex: updating the firmware on the Logitech wireless USB device).

[danielt]

There is some firmware on PBP that would make sense for LVFS but perhaps it is still a little too early...


The trackpad and keyboard controller firmware would be a good candidate because there is a very clear official firmware for it (actually judging by the reboot needed in the middle the "firmware" might actually be "firmwares"). This would make sense as soon as there is confidence that the updater tools are robust on a wide variety of distros.

However the main system firmware (u-boot + proprietary TF-A and preloader) is still undergoing heavy change by a variety of different developers. At present there is not sufficient confidence for an official recommendation w.r.t. the SPI flash (hence the system firmware currently resides in eMMC) which is what makes me think it is a little early to rely on LVFS to maintain everyone's firmware.

[CuriousTommy]

There is some firmware on PBP that would make sense for LVFS but perhaps it is still a little too early...


The trackpad and keyboard controller firmware would be a good candidate because there is a very clear official firmware for it (actually judging by the reboot needed in the middle the "firmware" might actually be "firmwares"). This would make sense as soon as there is confidence that the updater tools are robust on a wide variety of distros.

However the main system firmware (u-boot + proprietary TF-A and preloader) is still undergoing heavy change by a variety of different developers. At present there is not sufficient confidence for an official recommendation w.r.t. the SPI flash (hence the system firmware currently resides in eMMC) which is what makes me think it is a little early to rely on LVFS to maintain everyone's firmware.

Thank you for the explanation. I understand if now is not the right time to support LVFS.

Once the firmware issues get sorted out, I hope you consider emailing the LVFS maintainer.

[hmuller]

@CuriousTommy, after looking into this a little deeper I revise my opinion on LVFS, I have a tendency to resist change unless clear arguments are made for it. I have a few recommendations for you which are given in a spirit of collaboration first. 

If you are to evangelize LVFS successfully, two points you should be able to discuss fluently are one, why does it make sense to introduce a middleman in the firmware update process, and two, what security measures and/or technologies are used throughout the process to ensure that the end user is installing the same firmware the OEM (original equipment manufacturer) intends. Richard Hughes has missed an opportunity to evangelize his own work, by not clearly documenting the second point on his website (although his blog shows he is still working out issues related to security).

Next, developers are probably not the best recipient of this message as they may not have the authority to speak for or make those decisions for the OEM. The decision to adopt LVFS would rest with the project founder @tllim or those he has delegated authority/responsibility to.

@danielt makes the case that system firmware is not ready for LVFS, and I agree on that point. I also agree with him that the keyboard/trackpad device firmware IS a good candidate for LVFS. It is clear by observing the posts in the forums (keyboard/trackpad firmware) that some in the community require a simpler approach to updating firmware.

[yangmusa]

If you are to evangelize LVFS successfully ... why does it make sense to introduce a middleman in the firmware update process

If we assume that everyone will use the Debian version distributed by Pine, then I see why LVFS would seem like an unnecessary third party. However, LVFS is a distro-independent mechanism whereby users with any distro can get firmware updates automatically. E.g. my Dell Latitude gets automatic firmware updates regardless of my running Fedora or Linux Mint (my two main distros for this machine). Similarly, it seems like a lot of Pinebook Pro users are enjoying Manjaro rather than Debian - do they need to boot Debian just to update firmware?