Piotr Król

Piotr Król

Piotr Król is Founder and Embedded Systems Consultant at 3mdeb - licensed provider of coreboot consulting services. He received M. Sc. in Computer Systems Networking and Telecommunication from Gdańsk University of Technology. Piotr worked as Storage Controllers Validation Engineer and BIOS Software Engineer in Intel Technology Poland for over 7 years. After leaving Intel he
created his own consulting business focused on Embedded Firmware (coreboot, UEFI/EDK2/BIOS, trainings and security) and Embedded Linux (Yocto, Linux Device Drivers, Qt/C++/Go/Python applications) . He is passionate about building firmware that enables advanced hardware features and follows best security practices. His team maintains PC Engines platforms in coreboot and actively
work on and contribute to Open Source Firmware. Feel free to contact Piotr if you have any questions about related topic.

How to enable AMD IOMMU in coreboot

The idea for this talk born from fascination about the philosophy behind QubesOS, OpenXT and ViryaOS. The underlying technology for those OSes is Xen. Xen is a well-known project under the Linux Foundation umbrella, but what is most interesting in it from open source firmware perspective are high-end virtualization features
like:

  • DMA protection
  • PCI pass-through
  • Interrupt remapping
  • SR-IOV
  • TPM and vTPM
  • others

With automotive market hypervisors slowly move into embedded space, what means underlying firmware will have to expose right infrastructure to provide initial configuration and security.

Most features have to be configured and exposed in a well-defined way by firmware. IOMMU is the system component that some of the mentioned features rely on.

As maintainers of PC Engines apuX platforms, we decided to work on AMD IOMMU enabling to create right infrastructure for hypervisors and operating systems.

In this presentation we want to:

  • explain features of AMD IOMMU
  • present recommended methods of AMD IOMMU enabling
  • demonstrate current status of our work
  • discuss future user needs and implementation plans

Remote Testing Environment (RTE) workshop

As PC Engines firmware maintainers and aspiring IBV, we face lots of different issues with development. Critical bugs and regressions are our biggest enemies. Narrowing down serious problem requires a lot of repetitive work. The typical process looks like that:

  1. modify & build firmware with a potential fix
  2. flash affected firmware version
  3. boot system
  4. verify if the bug still exists

This can take more than 10min and requires human attention not to make a mistake. If you work hours on one issue, this can be boring and at some point, you will make mistakes which can affect results. Automation of point 1 is already done by coreboot-sdk. It also can involve user-developed scripts. Points 2-4 can be automated using RTE.

Another issue is that platforms and quality firmware developers are spread around the world and we would like to have reasonable access to key features that help in remote development. Because of that, we created RTE.

Remote Testing Environment is an open hardware hat designed for Orange Pi Zero board to work with hardware remotely. It takes advantage of using Linux system and open source frameworks such as Robot Framework to let user conveniently develop firmware, test software and/or hardware. With RTE, your everyday work routines become much faster and easier to maintain from places not related to current setup location. Those include flashing firmware, controlling GPIOs and power management for Device Under Test. RTE is released under CERN Open Hardware
License.

RTE applications:

  • Remote access / control (hardware functionality)
  • Remote industrial application debugging
  • Compatibility testing
  • Platform enabling
  • Performance optimization
  • Automation validation
  • Manufacturing procedures support

Agenda

In this workshop, we want to present how RTE can be used with open source firmware and help R&D and Q&A teams to achieve their goals.

RTE workshop main points:

  1. RTE features set.
  2. Connecting RTE to real hardware (e.g. PC Engines apu2 or MinnowBoard
    Dual/Quad).
  • validation setup - run a simple test in RobotFramework
  1. Comparison of simple procedures:
  • firmware flashing (main goal)
  • present power control possibilities (direct GPIO and Legacy interface)
  1. Development workflow with RTE based on the simple bug.
  2. Questionnaire and RTE giveaway.

Additional information

  • Level: Intermediate
  • Workshop will be interactive with examples
  • There will be a draw between participants, 3mdeb gives away 3 full RTE
    platforms (worth 85 USD each)
  • We are not sure we can handle more than 8 attendees
  • Please, check out our GitHub
    repository.

BITS and CHIPSEC as coreboot payloads

In this presentation, we would like to present how BITS and CHIPSEC can be utilized on top of coreboot enabled platform to verify the quality of underlying firmware.

Firmware security is mostly about validation and formal development processes. To achieve some level of confidence about firmware implementation quality various tools were developed, of which most notable are CHIPSEC and BITS.

BITS (BIOS Implementation Test Suite) consist of a GRUB2 bootloader extended with runtime Python support.

CHIPSEC is a Platform Security Assessment Framework which mostly focuses on platform configuration but can also be used for other purposes (e.g. verification of Spectre mitigation presence).

We would like to present what issues firmware developers may face and what we were able to achieve at this ground using BITS and CHIPSEC for validation of PC Engines apu2 and MinnowBoard Turbot platform. We want to present what modifications are required to integrated Python code along with CHIPSEC and BITS scripts. We also would like to demonstrate practical usage of mentioned frameworks by showing short demo.

< Go Back