 Hello, my name is Norbert Kaminski and today I will tell you about porting FWPD to the BSD operating systems. That means keeping your hardware safe with up-to-date firmware. Let's start with Agenda. At the beginning I will tell you Hemi, then I will tell you some words about FreeMDep and place where I work. Then I will go to some overall information about FWPD. I will show you architecture of FWPD. I will say some words about Linux Vendor Firmware service and then I will go to porting FWPD to the BSD. I will show you how we create continuous integration for FWPD in the FreeBSD. At the end of my presentation I will tell you about FWPD features. At the end of my presentation there will be space for some questions and answers. Okay, so who am I? My name is Norbert Kaminski, I'm an Embedded System Engineer at FreeMDep. I'm an open source contributor mostly in FWPD and the actual layers like MetaPC and DynS in my scope of interest are Firmware Upgrade Tools, Virtualization and Firmware Security and you can catch me under these links. Okay, who is FreeMDep? We are Corbwood Lines Service Providers since 2016. We are Corbwood Project Leadership Participants. We are UFI Adopters since 2018 and we are Official Consultants for FWPD LVFS Project and also we are Open Source Firmware Enthusiasts and Evangelists. Okay, so why we are doing this port? Why we are doing FWPD for BSD? From one side our clients were asking us if there is easy and secure way to upgrade the Firmware in the BSDs. From the other way the community were asking us if there is possibility to port FWPD to the BSD and we've connected this community needs and our clients needs and we've created the project FWPD for BSDs and that project is founded by an all-net foundation. So some words about FWPD. As you can know, updated Firmware makes devices vulnerable to the different attacks but there are a few problems when you want to upgrade your Firmware on your device. You need to know exactly what device is connected to your PC and you need to know if there are possible updates for this device and what version do you need. And here comes the FWPD project which can query the supported hardware for current Firmware version and also it can deploy the new Firmware version to the device. And we've got all the LVFS that is a secure web service which delivers the new Firmware to our PC and OMS can upload the Firmware to the LVFS and sign it to make it secure and to give client or customer or just user sureness that Firmware is secure. And our mission is to port the FWPD to VBSDs to make the Firmware update process easier for VBSD community. Okay, here we've got FWPD LVFS architecture. It could be split into three layers. We've got internal layer, session layer and system layer. In the internal layer we've got LVFS where the Firmware is stored and we've got content delivery network which delivers the Firmware to the session layer. In this session layer here lives FWPD manager which handles all the process of the Firmware update. The LVFS delivers the information about the possible updates and Firmware information and FWPD manager contacts with FWPD daemon which uses a plugin to query the devices and no information about current devices connected to your PC and a version of Firmware that is running on these devices. So typical update process looks like this. We are just sending a comment to the FWPD manager. FWPD manager is checking what devices are connected. Then it's checking if there is information about possible updates in the LVFS. If there are possible updates it's downloading with the content delivery network a Firmware and it's checking the signatures GPG and PKS7 and checksum. If everything is as expected the Firmware is unpacked and sent to the FWPD daemon and FWPD daemon is deploying the Firmware to our devices. Okay so now we've got Linux vendor Firmware service. Let's talk much more about it. As you can see we've got here Linux and we have to think about change of this name because it's not only the Linux it's starting to be BSD as well. But let's talk more about service not about the name. The LVFS is a secure web service that is used by the OME to provide Firmware updates. The LVFS is providing metadata about possible updates to the FWPD manager and the Firmware is packed into a cabinet archives. Cabinet archives contains the Firmware binary and information about the update and it also have jcat file which is used to verify if Firmware update is secure. jcat file contains signature PKS7 and GPG and also it has information about SHA256 checksum. And if everything is correct we can update our device. The only one who is signing the Firmware is manufacturer so we are not trusting the FWPD. We are trusting the manufacturer who is deploying the Firmware. Okay so let's talk about BSD and compilation of FWPD on BSDs. On this slide I will focus on the packaging systems. We focused on four BSD operating systems, Dragonfly BSD, FreeBSD, NetBSD and OpenBSD. Initially we wanted to create one package source package for all operating system. Following the documentation of package source it declared support for each operating system but after the concept works we met dependency hell and we've decided to create four different packages using the native package managers of operating system. So what we need to do to create the port of FWPD for BSDs? At first we need to create the port of FWPD dependencies. We've got GUSB library which is GLEAP wrapper for LeapUSB. We've got LeapJCut which is library that contains the tools to verify our Firmware. We've got XMLB library which adds the support for additional commands that is need to use with XML in FWPD and we've got an FiBoot library which is used to UFI Firmware update proposals. Okay so we've got all dependencies which we need then we go to FWPD code. So we need to change the Linux related parts of code that was mostly adding the if-deaths to the code but some parts, specific parts of codes need to be changed into the way into BSD way. Okay and the last step of adaptation was adaptation of the FWPD plugins to the BSD needs. I will tell you more about this on the future slides. Okay so current status of work. We've created FWPD packages for all four operating systems and free BSD package is now currently during the upstream process and the rest of the packages will be upstream in the near future. Our initial goal was to develop the FWPD functionalities in the free BSD and our next steps will be testing FWPD functionalities and solving the problems in drag-on-fly BSD, open BSD and not BSD as well. Okay so we began our development with creation of continuous integration. At the beginning of our development we've just used the GitHub action free BSD virtual machine. Continuous integration let us develop new changes to the current FWPD code with the confidence that we do not break anything in the build process. So we've used as I said GitHub action to this propose and we've created the job and now I will show you the demo. Okay so as you can see we've got GitHub CI and now we are downloading the free BSD virtual box VM. VM is loading and after VM yeah as you can see we've got now loaded VM and now we are installing the dependencies for now is installing the dependencies for a virtual machine. Okay now we've got FWPD repository from the current comment and now we are installing the FWPD dependencies. Some of FWPD dependencies need to be built from vSource because they are not already in the upstream so you'll see that in a moment. Also we are updating the package to the latest repository to just have the latest the fresh and the fresh most fresh ports. Okay and now we are cloning the ports to the free BSD VM. We are cloning this because we need to have our fork of the ports because as I said we are currently in the upstream process. As you can see now we are building the dependencies of the FWPD. As I said some dependencies are not in the upstream so we are building it from the source. We've got lib jcat, we've got lib xmlb and now the FWPD is installed for the first time. We are compiling FWPD twice because for the first time we are creating the package info file which contains information about every file that is installed in this comment. Then we are clearing the build and we are building the package once again to have all files in the package that could be uploaded to the GitHub. I will fast forward that. Now you will see the clearing of now you will see the cloning of the build process. As you can see we are setting the package.polis file and once again we are compiling the FWPD. Let's fast forward that. And now we are creating the package and then we'll check if the package is installing properly and if it is it will be uploaded to the GitHub. You can see make install, everything works fine, the binary artifact is uploaded. Let's go back to the presentation. Okay, so now I will tell you some words about the FWPD functionalities. I will start with gathering the information about possible updates. So to update the device we need to know exactly what hardware is connected to our PC and if there are possible updates. For this proposal we are using three FWPD comments, get device which lists devices connected to our PC, refresh which downloads the metadata info from the LVFS and get updates which lists possible updates for devices connected to our PC. So there was a problem with updating FWPD metadata info about possible updates. It was caused by memfd create which was not available in FreeBSD 12.2 but it is already added in FreeBSD 13.0. We've changed that and now FWPD is checking if the function is available, if not it emulates in-file memory file by unlinked temporary file. Here is the patch which changes this. Okay, as you can see now we've got FWPD manager get device. That's the comment which lists devices connected to VPC and supported by VFWPD and it lists current version, it give us some summary information about a device and it give us information about install duration. The most important thing is GUI IDs which give us information what exact device is it and GUI IDs are used by the FWPD plugins to make sure that this device is a specific device which could be updated with some firmware that is given from the OM. That is generated differently from FWPD plugin to FWPD plugin. For example GUI IDs in UFI are read from the S30 in for the USB devices it's generated from the USB information given by the manufacturer. Okay, the next thing is FWPD manager refresh. As you can see it fetch metadata about possible updates from the content delivery network and also it fetch signature which is used to check if metadata that was downloaded is trustworthy and if metadata is downloaded successfully it shows if there are supported device and if there are possible updates. Okay, now we've got FWPD manager get updates. As you can see it lists device as it does FWPD manager get device and it also lists possible updates. Okay, so now we can go to the updating USB devices. So our first step in the updating devices was updating USB devices. We want to enable updates for color hack that is color image that is our test device which we use to develop every update for USB device and we've encountered a problem with FreeBSD Leap USB which prevented USB devices from returning to operating system after reboot. FWPD uses the LeapG USB library which is G-Leap wrapper around Leap USB. The usual follow flow of an update is as follow. The first step is issuing the comment to the device to enter putloader mode and in the case of color hack 2 that is a custom HID based flashing mode then we are writing an update to the device and if it's successful we are going back to the running mode, runtime mode to the operating system and our problem occurred after the first step. Okay, so we were unable to reattach the device to the host after issuing the comment to reset the device to get back to the normal operation and operating system does not recognize this device and it could not reattach it. It just stay as gone because LeapG USB uses Leap USB Synchronos API. FWPD would close the device after an update before all events had been processed. Even processing such event Leap USB would detach the device is gone and mark it with a device is gone flag and this meant that on all future requests Leap like USB would fail with like USB error, no device error. So we fixed that by clearing device gone flag in the case the device was open after reattach to allow a new transaction. And now we've got to the next demo. So we are updating Colorhack and we are logging to the FreeBSD. The FWPD is asking us if we want to update the device. We are saying yes. The update is downloaded and it's decompressed, verified and installed. As we can see in the end everything works fine. The firmware is updated. So let's go back to the presentation. The second firmware update that we want to provide was UFI Device Firmware Update from our perspective and perspective of security. This UFI updates were crucial to implementing and this functionality was our priority for FreeBSD. So there were a couple parts that had to be implemented to make it work. We need to add the UFI S30 table support that was like in FreeBSD. Also FreeBSD FIVAR backend for FWPD needed to be implemented. The FIVAR support on Linux is implemented via SSFS interface while FreeBSD has a C AP and that needs to be implemented to FWPD. Also BSD we need to add BSD support in FWPD and also adding support for UFI Update Capsule Plugin in FWPD for FreeBSD. Okay so what is UFI S30? S30 is an FI system resource table which is a standard interface for FIMER updates available since UFI 2.5 it exposes among data information about the currently installed FIMER version and status of the last update attempt. It's used by the FWPD for detection, matching and giving information about available updates. Support for this table was missing in FreeBSD and we've added with in this the patch. Okay so FWPD applies FIMER updates by installing a small FI binary along with the update capsule into ASP and setting the FI bootnext variable to point it. So the machine reboots and launches the FE binary which then calls update capsule which tells the UFI to apply the capsule and the actual flashing is handled by the UFI implementation itself. This requires FIVAR support and FreeBSD has a different programmatic AP so this support needed to be added in FWPD. Furthermore since FreeBSD has a disk management AP that differs slightly from the Linux standards this supports also need to be added. Okay and now we've got UFI demo so as before we are logging to the FreeBSD and we are updating our FIMER. Once again the FWPD is asking us if we want to update the FIMER. We are using the once again we are downloading the FIMER. The FIMER is installed by the UFI capsule and as you can see the capsule is downloaded. The FIVAR bootnext is set and at the end of the process FWPD is asking us if we want to restart now. So let's back to the presentation. If we click yes we are just rebooting and we can see the update process which is handled by the UFI implementation and if everything is working properly we can see that FIMER update is successful and the UFI will reboot us to the operating system. Okay so thank you for your time and for your attention. If you want to contact us you can reach us under these links. I also like to send many thanks to our engineers who make FWPD for BSD possible especially for Mihal, Sergi and Pavel and it's time for the questions. Thank you so much. There are a couple questions on the shared notices but I would like to ask a question first. You said you were working on package source packages but I haven't found any have you upstreamed them yet? We've got the package source package in our fork. I can link that. Just give me a second. It should be in our fork on FWPD on GitHub. Okay, it's it's it. Yeah, have the FWPD package source. Here it is and it's not like here. VAP. Okay we've got it and have the FWPD BSD. Okay it's a little bit VAP, but you can look at that. Okay. And that's a few comments. Yes. Okay. I linked that in public chat. What was the main reason for dependency hell when trying to package on FWPD on package source? We will use package source for NetBSD because it's native for NetBSD. But when I was trying to install the package source on OpenBSD and DragonflyBSD, there were problems with the dependencies that needs to be built from the source. And some dependencies do not build as expected, and that give us so much more work to fix that dependencies than just using the native package manager. And that was the main reason to use native for native package managers, and not only the package source. Okay, short notes. How high is the risk to break brick hardware using FWPD on FreeBSD at this stage? Okay, so if you're using the UFI updates, there is a low risk to break your hardware because you're only downloading the archives that are deployed by the manufacturer. All the flashing work is done by the, all the flashing work is done by the UFI. It's a very cheap test device that one can be used to test safely and repeatedly. We are using Colorhug. That's a Richard Hughes device, which is maintainer of the, who is maintainer of the FWPD. I have no idea how much it costs, but I will link you this device. Okay, that's open source, open source hardware, which could be, I'm not sure if it's available in this say, but you can just build it yourself. Okay. Website seems to be, okay, what is the status for other BSDs? I will answer first to this question. The status for other BSDs. Currently, we are building the FWPD on every BSD operating system. The other functionalities of FWPD are not tested on the Dragonfly OpenBSD and NetBSD. We are aware of that of differences between free BSD and other BSDs. So the main problem with UFI updates is that SRT support needs to be provided for every operating system, and we need to upstream the driver that will enable the stables in the Dragonfly BSD, OpenBSD and NetBSD. For the USB updates, it should be so much easier, and we just need to make some proof of concept work and just try to flash our devices and just look if they are working correctly. They may happen some problems like a USB problem in free BSD that may need to be solved by us or by us and community. That's the current status for the rest of BSDs. Okay, I will go back to the question of chip device. I will check that and I will give you somehow information about this. The easiest way to check if you have such device is just looking at LVFS and just trying to Google devices that you have. Okay, yeah. So here is the LVFS service and you can just search Firmware for your devices and just try to search some Firmware for your device. Is there a QT-based front-end yet? No, there is no QT-based front-end and I guess that is a question from Pro Bono. Is any information collected and sent to the server telemetry? Which information about user devices collected and what is shared with the Firmware vendor? Yes, there are information that are sent to the server telemetry. Okay, every user which is downloading the Firmware from the LVFS is sending the information about that he has this device and that information is just, that information do not are not connected with specific users. So we are just sending the information that you have this device and it could not be connected with you. The vendor got the information if the update was successful and vendor has information about which version have you run and which version you update and it could be used to just set the stable version because when you are updating your Firmware if everything is working fine. So the vendor can set this Firmware version as stable. When do you expect to land packages for FreeBSD 12 and 13? We are currently in the upstream in the upstream process. So it will be, I could not give you a precise date but we want to do it until the end of the Coofree. Firmware downgrades are possible. Yes, Firmware downgrades are possible. Okay, and I guess we've got our older devices without UFI able to use FWPD to update biases. Yes, they are available to update the biases. It all depends by the bias it runs. For example, the Corbwood bias is updated with a plugin called Flashroom that use Flashroom tool to update the bias but currently we are not guaranteed that this Flashroom plugin will work with FreeBSD and other BSDs. We are now focusing only on the USB devices and UFI updates. We'll have FWPD work with known x86 architectures assuming there is Firmware updates available. Yes, it will work. Okay, do we have any more questions? I think the discovery support... There's a question about support for non x86 architectures, did you... Yes, there was something. Okay, have you had any experience success with RAID controller Firmware? No, we did not try to update the RAID controllers Firmware but I guess if you have some questions you can always create an issue at FWPD FWPD on GitHub. Let me link that. Here are the maintainers which got much more experience than me in FWPD. They can answer most of your questions. I guess there are some possible updates for RAID controllers in the LVFS but I cannot precisely answer your question. Thank you very much for your time and for your attention.