Jekyll2024-03-28T12:48:05+00:00https://www.linaro.org/feed.xmlLinaroLinaro is a collaborative engineering organization consolidating and optimizing open source software and tools for the Arm architecture.How Implementing Security.txt? A Step Towards Enhanced Cybersecurity, a Linaro Best Practice2024-03-20T03:34:22+00:002024-03-20T03:34:22+00:00https://www.linaro.org/blog/how-implementing-security-txt-a-step-towards-enhanced-cybersecurity-a-linaro-best-practice<p>This article aims to inform readers about the significance of “security.txt”, its framework, global adoption, and provides a straightforward implementation guide to encourage its widespread use showing how in Linaro we’ve done it.</p> <h3 id="context"><strong>Context</strong></h3> <p>Maintaining open lines of communication between website administrators and ethical hackers or security researchers is paramount when talking about digital security. This is where “security.txt” plays a pivotal role. Inspired by the simplicity and functionality of “robots.txt” used by search engines to index web pages, “security.txt” is a proposed standard designed to streamline the process of reporting security vulnerabilities.</p> <h3 id="what-is-securitytxt"><strong>What is Security.txt?</strong></h3> <p>Security.txt is a simple text file, strategically placed under the “.well-known” directory of a website’s domain, making it easily accessible for security researchers. Its primary purpose is to provide a standardized way for researchers to report security issues they discover. The file contains contact information and other directives that guide the researcher on how to report vulnerabilities responsibly.</p> <p>For instance, Linaro’s security.txt file can be found at: https://linaro.org/.well-known/security.txt.</p> <h3 id="understanding-rfc9116-and-rfc8615"><strong>Understanding RFC9116 and RFC8615</strong></h3> <p>The implementation of security.txt is guided by two key RFCs (Request for Comments): RFC9116 and RFC8615. RFC9116 outlines the “security.txt” document itself, detailing the specific format and instructions it should contain for effective communication. Meanwhile, RFC8615 establishes the “.well-known” URI, ensuring that security.txt files are placed in a universally recognized location across all websites.</p> <h3 id="implementing-securitytxt-a-step-by-step-guide">Implementing Security.txt: A Step-by-Step Guide</h3> <ol> <li>Create Your Security.txt File: Begin by drafting a text file named “security.txt”. This file should include essential contact information, such as an email address, and any guidelines for reporting vulnerabilities. Optionally, you can also add encryption keys for secure communication and acknowledgments for those who report issues responsibly.</li> <li>Place It Under the “.well-known” Directory: To comply with RFC8615, your security.txt file should be placed within the “.well-known” directory of your website (e.g., https://yourdomain.com/.well-known/security.txt). This standardization ensures that security researchers can easily locate the file.</li> <li>Consider Using ‘Contact:’ and ‘Encryption:’ Directives: At a minimum, your security.txt should include a ‘Contact:’ directive to provide a point of communication. For added security, consider including an ‘Encryption:’ directive with a link to your PGP key, enabling encrypted communications.</li> <li>Publish and Test: After placing your security.txt file on your website, ensure it is accessible via its intended URL. Regularly test and update the file as needed, keeping contact information and directives current.</li> </ol> <h3 id="why-implementing-securitytxt">Why Implementing Security.txt?</h3> <p>Adopting security.txt on your website underscores your commitment to cybersecurity. It not only facilitates a responsible vulnerability disclosure process but also fosters a collaborative relationship between your organization and the cybersecurity community. By providing a clear, standardized method for reporting security issues, you can address vulnerabilities more swiftly and efficiently, safeguarding your digital assets against potential threats.</p> <p>In summary, the implementation of security.txt is a straightforward yet impactful step towards bolstering your website’s security posture. By embracing this proposed standard, you join a global effort to create a safer digital ecosystem for businesses and users alike.</p>joakim.bechThis article aims to inform readers about the significance of “security.txt”, its framework, global adoption, and provides a straightforward implementation guide to encourage its widespread use showing how in Linaro we’ve done it.Linaro Forge: Empowering the Energy Sector at the Rice University Energy HPC Conference2024-02-25T21:54:36+00:002024-02-25T21:54:36+00:00https://www.linaro.org/blog/linaro-forge-empowering-the-energy-sector-at-the-rice-university-energy-hpc-conference<p>The Linaro Forge team is thrilled to announce our continued sponsorship and participation at the Rice University Energy HPC Conference in Houston. For more than a decade, we have been a proud supporter of this paramount event, which stands as the global summit for technical and business leaders in the energy sector. This conference serves as a vital platform for sharing insights, presenting technical findings, and contemplating the future landscape of the energy industry. Linaro’s commitment to this gathering reflects the dedication of the Linaro Forge team to the energy sector and our role in its ongoing evolution.</p> <p>Since our inception, Linaro Forge has been at the forefront of providing high-performance computing (HPC) debugging and performance engineering tools. Our solutions have become indispensable for organizations developing codes for a variety of applications, from reverse time migration to large-scale reservoir simulation. These tools have not only facilitated traditional energy exploration and production but have also adapted to the industry’s expansion into renewable energy sources such as wind, solar, and geothermal development.</p> <p>The shift towards renewable energy has necessitated a broader spectrum of applications to enable sustainable energy development. The Linaro Forge team has eagerly embraced this transition, working closely with our customers to adopt innovative methods. Our collaborations have ranged from supporting large-scale computational fluid dynamics (CFD) for wind energy production to advancing load modeling for solar development. These efforts underscore our commitment to innovation and our contribution to the energy sector’s sustainability and efficiency.</p> <p>As the energy landscape continues to evolve, so do we. The Energy HPC Conference provides an excellent opportunity for us to connect with industry leaders, share our latest advancements, and discuss our vision for the future. We are particularly excited about showcasing our roadmap for upcoming releases and exploring how our tools can further empower the energy sector.</p> <p>We invite you to join us, visit our booth to catch up on the latest developments in Linaro Forge and learn more about how our solutions are driving progress in the energy industry. Whether you’re a longtime partner or new to the field, we look forward to discussing how we can support your endeavors in this dynamic and critical sector.</p> <p>See you in Houston, where innovation meets energy!</p>linaroThe Linaro Forge team is thrilled to announce our continued sponsorship and participation at the Rice University Energy HPC Conference in Houston. For more than a decade, we have been a proud supporter of this paramount event, which stands as the global summit for technical and business leaders in the energy sector. This conference serves as a vital platform for sharing insights, presenting technical findings, and contemplating the future landscape of the energy industry. Linaro’s commitment to this gathering reflects the dedication of the Linaro Forge team to the energy sector and our role in its ongoing evolution.Linaro @ FOSDEM 20242024-02-21T03:11:10+00:002024-02-21T03:11:10+00:00https://www.linaro.org/blog/linaro-fosdem-2024<p>The Université libre de Bruxelles held the event on February 3rd and 4th, and the program was more prosperous than ever. FOSDEM is always considered the best IT conference and it is entirely volunteer driven. Linaro attended the event with eight talks (having submitted about a dozen): a record-breaking presence and acceptance ratio! Beer was constantly flowing at Fosdem, yet there is no indication that Belgian beer is much better this year to draw the attention of so many of the following Linaro open-source contributors.</p> <p><strong>Caleb Connolly</strong> presented <strong>U-Boot for modern Qualcomm phones</strong>, where they discussed how bootloaders are often one of the most significant pain points when booting upstream Linux on Qualcomm devices. Caleb points out how distros which aim to support Qualcomm devices currently have to handle 4 versions of the Android boot image header plus many additional quirks. In this talk, they give a brief introduction of EFI bootloader, how they work, and how U-Boot fits into the picture as a second-stage bootloader. Caleb covered the work they’ve been doing to improve Qualcomm support in upstream U-Boot and how folks can drastically lower the barrier of entry for distro support on Qualcomm phones. Lastly, they discussed the new process for porting a Qualcomm device and SoC to U-Boot and showcased a cool demo booting Linux with EFI runtime support on a Qualcomm phone.</p> <p><a href="https://fosdem.org/2024/events/attachments/fosdem-2024-1716-u-boot-for-modern-qualcomm-phones/slides/22104/fosdem24_aDevbas.pdf">Presentation Slides</a> // <a href="https://ftp.belnet.be/mirror/FOSDEM/video/2024/h1309/fosdem-2024-1716-u-boot-for-modern-qualcomm-phones.av1.webm">Talk Video</a></p> <picture> <source data-srcset="/../generated/assets/images/content/u-boot-for-modern-400-80a991.webp 400w, /../generated/assets/images/content/u-boot-for-modern-800-80a991.webp 800w, /../generated/assets/images/content/u-boot-for-modern-1200-80a991.webp 1200w" type="image/webp" /> <source data-srcset="/../generated/assets/images/content/u-boot-for-modern-400-80a991.png 400w, /../generated/assets/images/content/u-boot-for-modern-800-80a991.png 800w, /../generated/assets/images/content/u-boot-for-modern-1200-80a991.png 1200w" type="image/png" /> <img class="lazyload img-fluid blog_content_image" data-src="/../generated/assets/images/content/u-boot-for-modern-800-80a991.png" alt="Caleb presenting about U-boot in FOSDEM24" /> </picture> <p><strong>Bryan O’Donoghue</strong> talked about a <strong>fully open-source stack for MIPI cameras</strong>. It was a joint talk with Bryan and Hans De Goede from Redhat about supporting MIPI cameras with a fully open libcamera / Linux kernel stack.</p> <p>Linaro has engaged with libcamera to provide a Soft ISP solution for MIPI cameras. Several other organizations are interested in this solution - including Red Hat on both the ARM64 Laptop, x86 Laptop, and embedded IOT Arm side of things.</p> <p>We discussed at a high level what the core problem to be solved is - debayering, 3As in the absence of Hard ISP support, how we engaged with libcamera on design and implementation, the state of the art in CPU ISP and near future extensions to GPU ISP.</p> <picture> <source data-srcset="/../generated/assets/images/content/a-fully-open-source-stack-for-mipi-cameras.-fosdem24-400-32c659.webp 400w, /../generated/assets/images/content/a-fully-open-source-stack-for-mipi-cameras.-fosdem24-800-32c659.webp 800w, /../generated/assets/images/content/a-fully-open-source-stack-for-mipi-cameras.-fosdem24-1200-32c659.webp 1200w" type="image/webp" /> <source data-srcset="/../generated/assets/images/content/a-fully-open-source-stack-for-mipi-cameras.-fosdem24-400-32c659.png 400w, /../generated/assets/images/content/a-fully-open-source-stack-for-mipi-cameras.-fosdem24-800-32c659.png 800w, /../generated/assets/images/content/a-fully-open-source-stack-for-mipi-cameras.-fosdem24-1200-32c659.png 1200w" type="image/png" /> <img class="lazyload img-fluid blog_content_image" data-src="/../generated/assets/images/content/a-fully-open-source-stack-for-mipi-cameras.-fosdem24-800-32c659.png" alt="Bryan talking about open source cameras in FOSDEM24" /> </picture> <p><a href="https://fosdem.org/2024/events/attachments/fosdem-2024-3013-a-fully-open-source-stack-for-mipi-cameras/slides/22223/A_fully_open_source_stack_for_MIPI_cameras_-_FO_dhMg1oP.pdf">Presentation Slides</a> // <a href="https://video.fosdem.org/2024/ud2120/fosdem-2024-3013-a-fully-open-source-stack-for-mipi-cameras.av1.webm">Talk Video</a></p> <p><strong>Neil Armstrong</strong> discussed <strong>Mainline Linux on Qualcomm SoCs, are we here now?</strong> For the last ten years, Qualcomm’s engineers and Linaro’s Qualcomm Landing Team have been working hard to implement Linux mainline support for Qualcomm platforms carefully, and so far, so good as you can judge with the very good Thinkpad X13S support.</p> <p>Neil did a tour of all supported platforms, describing the work Linaro’s Qualcomm Landing Team has achieved and the key features engineers are working on.</p> <p>The Qualcomm SoCs are notoriously very complex and powerful, and implementing clean, correct, maintainable, and extensible support for mainline Linux is particularly hard.</p> <p>Key domains like Power or DSP management were particularly hard to support, with those in good shape multimedia, connectivity, and network features getting enabled, permitting Qualcomm-based devices to offer excellent support while running vanilla (unmodified) Linux kernel!</p> <p>The Thinkpad X13s is an excellent example of such support because, until recently, it was limited to expensive and hard-to-buy Qualcomm Reference platforms.</p> <p>Nevertheless the Qualcomm Reference platforms get as early as possible mainline support, without any concessions on code quality, like the Snapdragon 8 Gen 3 mailing-list patches delivered on marketing announcement day.</p> <p>The talk gave a tour of supported platforms, current and possible future achievements, and integration examples with mobile distributions like PostmarketOS.</p> <picture> <source data-srcset="/../generated/assets/images/content/mainline-linux-on-qualcomm-socs-are-we-here-now--400-1242ea.webp 400w, /../generated/assets/images/content/mainline-linux-on-qualcomm-socs-are-we-here-now--800-1242ea.webp 800w, /../generated/assets/images/content/mainline-linux-on-qualcomm-socs-are-we-here-now--1200-1242ea.webp 1200w" type="image/webp" /> <source data-srcset="/../generated/assets/images/content/mainline-linux-on-qualcomm-socs-are-we-here-now--400-1242ea.png 400w, /../generated/assets/images/content/mainline-linux-on-qualcomm-socs-are-we-here-now--800-1242ea.png 800w, /../generated/assets/images/content/mainline-linux-on-qualcomm-socs-are-we-here-now--1200-1242ea.png 1200w" type="image/png" /> <img class="lazyload img-fluid blog_content_image" data-src="/../generated/assets/images/content/mainline-linux-on-qualcomm-socs-are-we-here-now--800-1242ea.png" alt="Neil talks about mainline linux status on Qualcomm SoCs in FOSDEM24" /> </picture> <p><a href="https://fosdem.org/2024/events/attachments/fosdem-2024-1707-mainline-linux-on-qualcomm-socs-are-we-here-now-/slides/22126/FOSDEM24_-_Mainline_Linux_on_Qualcomm_SoCs_are_cW72KOo.pdf">Presentation Slides</a> // <a href="https://video.fosdem.org/2024/h1309/fosdem-2024-1707-mainline-linux-on-qualcomm-socs-are-we-here-now-.mp4">Talk Video</a></p> <p><strong>Rémi Duraffort</strong> gave a talk about <strong>A simple caching service for your CI</strong>. Kisscache is a simple caching service developed by Linaro for the LKFT (Linux Kernel Functional Testing project at Linaro) to cache test artifacts like kernel, dtb, and root filesystem. While pretty simple, KissCache can cache https URLs without any hacks that proxies like squid will require.</p> <p>Kisscache is intensively used at Linaro to reduce the amount of data downloaded by the CI system while improving reliability with automatic retries. Since its introduction two years ago, KissCache has been able to save 1TB of data transfer and decrease the number of network failures.</p> <p>In this short introduction, I will show you the features that make this service so efficient for LKFT.</p> <p><a href="https://fosdem.org/2024/events/attachments/fosdem-2024-2671-a-simple-caching-service-for-your-ci/slides/22164/FOSDEM_2024_-_A_simple_caching_service_for_your_SULIaEx.pdf">Presentation Slides</a> // <a href="https://video.fosdem.org/2024/h2215/fosdem-2024-2671-a-simple-caching-service-for-your-ci.av1.webm">Talk Video</a></p> <p><strong>Rémi Duraffort</strong>’s second talk featured <strong>Ghosting the hardware</strong>. LAVA, the Linaro Automation Validation Architecture, is now the standard system for testing software (from bootloader to kernel or userspace) on both virtual and real hardware. It’s used by many projects to build large testing systems like kernelci or LKFT (Linux Kernel Function Testing project from Linaro).</p> <p>To build a stable CI system, we have to ensure that LAVA itself does not regress from one version to another.</p> <p>In this talk, Rémi presented how the LAVA team is intensively using mocking to test LAVA on devices that none of the team ever saw.</p> <p><a href="https://fosdem.org/2024/events/attachments/fosdem-2024-2687-ghosting-the-hardware/slides/22554/FOSDEM_2024_-_Ghosting_the_hardware_uFFI7XR.pdf">Presentation Slides</a> // <a href="https://video.fosdem.org/2024/ud2208/fosdem-2024-2687-ghosting-the-hardware.av1.webm">Talk Video</a></p> <p><strong>Thomas Fossati</strong> presented <strong>Increasing Trust and Preserving Privacy: Advancing Remote Attestation</strong>. <br /> Thomas gave a talk in the confidential computing devroom about remote attestation. It was co-presented by Thomas and Ionut Mihalcea from Arm. Hannes Tschofenig was also a co-inspirator, but couldn’t attend the event. This talk was the last one on Sunday night, and we were pretty knackered by then, but it was fun. During the talk, we discussed the history of attestation, from its theoretical beginnings at PARC in the 1980s, through trusted computing to confidential computing, and finally, to its integration into network protocols. Attestation has moved from a niche technology to being widely available in laptops, servers, and IoT devices. We highlighted some of the technical and societal implications of using this technology. On the societal front, we discussed the risks associated with centralization (i.e., the opportunity of monopoly) and privacy concerns. On the technical front, we argued about the need to ensure that integrations of attestation into existing authentication protocols are done securely. Finally, we proposed a model for minimizing risks and maximizing utility based on open standards, open-source software, and formal verification</p> <p><a href="https://fosdem.org/2024/events/attachments/fosdem-2024-2265-increasing-trust-and-preserving-privacy-advancing-remote-attestation/slides/22934/FOSDEM_2024_Increasing_trust_and_preserving_pri_wbCqaZY.pdf">Presentation Slides</a> // <a href="https://video.fosdem.org/2024/h2214/fosdem-2024-2265-increasing-trust-and-preserving-privacy-advancing-remote-attestation.av1.webm">Talk Video</a></p> <p><strong>Dmitry Baryshkov</strong> discussed <strong>Using linux-yocto as a Yocto BSP kernel</strong>. The `linux-yocto` kernel is widely known as a default OpenEmbedded / Yocto kernel, used for QEMU machines and several default Yocto BSPs. For other platforms, it is used quite rarely. Nevertheless, it is a kernel recommended by the Yocto Project Compatible Layer program. This talk was dedicated to switching the <a href="https://github.com/Linaro/meta-qcom">Qualcomm Yocto BSP layer</a> from the Linaro-backed kernel to <a href="https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-kernel/linux/linux-yocto.inc">linux-yocto</a>. The talk provided a step-by-step guide and listed the positive and drawbacks of such conversion. Also it covered the peculiarities of the linux-yocto itself and its config system based on the features files and config snippets.</p> <p><a href="https://fosdem.org/2024/events/attachments/fosdem-2024-3012-using-linux-yocto-as-a-yocto-bsp-kernel/slides/22155/FOSDEM24_-_Using_linux-yocto_as_a_Yocto_BSP_ker_98gsNLb.pdf">Presentation Slides</a> // <a href="https://video.fosdem.org/2024/ud2120/fosdem-2024-3012-using-linux-yocto-as-a-yocto-bsp-kernel.av1.webm">Talk video</a></p> <p><strong>William Breathitt Gray</strong> presented <strong>Synergy in Open Communities</strong>. William talked about synergy in open communities. Synergy is when multiple parties come together to produce something greater than the sum of their parts, and it’s what we will strive for in this talk. When an open community like an open source project grows, external contributions increase.</p> <p>One of the primary benefits of open communities is the assimilation of progress from a broad and diverse pool of talent. However, care must be taken to ensure that the acceptance process is free from social friction, lest arguments bring down and delay the development of the project.<br /> <br /> This lightning talk covers the social issues open community maintainers and external contributors face during the submission of a patch or other change, why conflicts arise between parties, and how to handle complex public disagreements to bring threads of discussions back on topic to focus on the benefit of the project and community.</p> <p><a href="https://fosdem.org/2024/events/attachments/fosdem-2024-3120-synergy-in-open-communities/slides/22102/FOSDEM24_-_Synergy_UXpPS67.pdf">Presentation Slides</a> // <a href="https://ftp.fau.de/fosdem/2024/h2215/fosdem-2024-3120-synergy-in-open-communities.av1.webm">Talk video</a></p> <p>This is just a brief snippet of the talks by Linaro engineers. The slides and videos of these talks are also available. There were many more talks on a wide array of topics, folks are encouraged to look at the slides and videos. It was a pleasure attending the FOSDEM24 amidst the grey sky and long food queues, but the enthusiasm of participants and quality of the topics made it worthwhile.</p>linaroThe Université libre de Bruxelles held the event on February 3rd and 4th, and the program was more prosperous than ever. FOSDEM is always considered the best IT conference and it is entirely volunteer driven. Linaro attended the event with eight talks (having submitted about a dozen): a record-breaking presence and acceptance ratio! Beer was constantly flowing at Fosdem, yet there is no indication that Belgian beer is much better this year to draw the attention of so many of the following Linaro open-source contributors.Long Term Support (LTS) for the Linux Kernel : what’s changing now?2024-02-20T09:50:05+00:002024-02-20T09:50:05+00:00https://www.linaro.org/events/long-term-support-lts-for-the-linux-kernel-what-s-changing-now<p>📆 Date: April 3rd 2024 <br />🕒 Time: 4:30pm GMT <br />🌐 Online Event: Join from anywhere</p> <p>Community LTS Kernel Support Has Been Reduced</p> <p>The Linux Kernel community offers two years of LTS support by default. Is this enough for ODMs, Silicon Vendors and solution providers who ship the Linux Kernel in product and had been expecting six years of support?</p> <p>New Government Mandates Impact Open Source Software</p> <p>Companies need to be aware of new legislation that imposes new obligations on their products. The E.U. Ecodesign Mandate, the E.U. Cyber Resilience Act (CRA), the US Patch Act and others are all advancing a common theme, products must have timely software updates, the latest security fixes must be available and OS updates must be made for extended periods of time. How can companies economically meet these requirements?</p> <p>Linaro LTS Kernel and Firmware Solutions</p> <p>Linaro, has deep and wide Linux Kernel engineering and maintenance expertise. Join Tom Gall (Director Vertical Technologies), Dan Carpenter (LTS Lead Architect) and Bill Fletcher (Solutions Director) as they explore the issues, and lay out how Silicon Vendors, ODMs and other organisations operating in the Arm ecosystem can successfully satisfy customer needs, meet government mandates and achieve their organisational requirements for a high quality Linux Kernel, U-Boot, Trusted Firmware A and OPTEE in support of their product goals.</p> <form action="https://www.eventbrite.co.uk/e/long-term-support-lts-for-the-linux-kernel-whats-changing-now-tickets-856142694847?_gl=1*i9xl9a*_ga*MTk4MzMzODY1My4xNzA5MjIyMDM0*_ga_E12E6FXFVK*MTcwOTYzMDkyMS4zLjEuMTcwOTYzMTI1My4wLjAuMA.."> <button type="submit">Register here</button> </form>linaro📆 Date: April 3rd 2024 🕒 Time: 4:30pm GMT 🌐 Online Event: Join from anywhereWindowsPerf Release 3.3.02024-02-05T02:46:15+00:002024-02-05T02:46:15+00:00https://www.linaro.org/blog/windowsperf-release-3-3-0<p>We are happy to announce the latest WindowsPerf release version <a href="https://gitlab.com/Linaro/WindowsPerf/windowsperf/-/releases/3.3.0">3.3.0</a>. This major release is a continuation of WindowsPerf development effort. For previous release information check <a href="https://www.linaro.org/blog/windowsperf-release-3-0-0">this content</a> out.</p> <p>What’s new? Addition of disassembly analysis to WindowsPerf allows developers to dive deep into the assembly-level details of their WOA aka Windows on Arm code. By examining the disassembled instructions, they can identify bottlenecks, inefficient loops, and potential optimizations.</p> <h1 id="high-lights-from-330-release">High-lights from 3.3.0 release</h1> <h2 id="disassemble-support-for-sampling">Disassemble support for sampling </h2> <p>The disassemble feature in wperf allows you to view the disassembly of a program’s code. This can be useful for understanding how the program works, identifying performance bottlenecks, and optimising the code. New feature has been added for sampling / record. Users can now with help of llvm-objdump emit disassembler for <a href="https://gitlab.com/Linaro/WindowsPerf/windowsperf/-/tree/main/wperf?ref_type=heads#using-the-annotate-option">annotate</a>. To use the disassemble feature, you can run the wperf command with the –disassemble option. Disassemble also implies annotate (–annotate). See <a href="https://gitlab.com/Linaro/WindowsPerf/windowsperf/-/tree/main/wperf?ref_type=heads#using-the-disassemble-option">Using the disassemble option</a> documentation for more details.</p> <h2 id="support-for-double-dash--to-wperf-command-line-parser">Support for double-dash – to wperf command line parser. </h2> <p>Double-dash marks the end of the wperf command line option list. After double-dash, the sampled process name and its verbatim command line options should be placed. From this release we’ve added support for double-dash – to wperf.exe command line parser. Note: This change breaks the current wperf command line format! See <a href="https://gitlab.com/Linaro/WindowsPerf/windowsperf/-/tree/main/wperf?ref_type=heads#wperf-double-dash-support">wperf “–” (double-dash) support</a> documentation for more details.</p> <h2 id="driver-improvements">Driver improvements</h2> <ul> <li> <p>We’ve made significant improvements to WindowsPerf Kernel Driver stability:</p> <ul> <li>Fixed issues with IOCTL input/output buffer misuse.</li> <li>Improvements to hardware resource allocation.</li> </ul> </li> <li>Timeline feature can now output JSON, in addition to CSV output file.</li> <li>We’ve <a href="https://gitlab.com/Linaro/WindowsPerf/windowsperf/-/merge_requests/461">fixed a memory leak</a> inside our PDB / PE file APIs. Users who run e.g. `wperf-lib` based sampling experienced significant memory leaks.</li> <li>We’ve improved how we detect PMU and SPE with the wperf test command. Users can now see in more detail which PMU / SPE hardware is on their ARM64 host.<br /> Note: we do not support SPE yet!</li> </ul> <h1 id="windowsperf-whats-next">WindowsPerf: what’s next </h1> <p>Linaro is planning to have a major release every three months with the next release 4.0.0 coming in late July-August 2024. During the time between the releases, we will be able to implement 2-3 new major features (derived from our <a href="https://gitlab.com/Linaro/WindowsPerf/windowsperf/-/requirements_management/requirements">requirements</a>), improve documentation, extend regression testing and fix issues.</p> <h2 id="what-to-expect-in-the-next-releases">What to expect in the next releases?</h2> <ul> <li>Lock/unlock feature where WindowsPerf will exclusively use PMU resources and gracefully handle (and reject) concurrent `wperf` requests to the driver. This simple improvement will benefit those who run e.g. long lasting timelines and do not want their work to be interrupted by concurrent `wperf` calls.</li> <li>We are working on adding support for Event Tracing for Windows (ETW) to WidnowsPerf. The integration of ETW into WindowsPerf will significantly enhance performance analysis capabilities for ARM64-based systems. WindowsPerf’s ETW integration will align with existing Windows performance analysis tools such as WPR/WPA.</li> </ul> <h1 id="where-to-find-us">Where to find us?</h1> <p>For source code and binary releases please visit our <a href="https://gitlab.com/Linaro/WindowsPerf/windowsperf">WindowsPerf webpage at GitLab</a>. Additional project resources include <a href="https://linaro.atlassian.net/wiki/spaces/WPERF/overview">WindowsPerf Wiki</a> and <a href="https://linaro.atlassian.net/jira/software/c/projects/WPERF/boards/169">WindowsPerf JIRA</a> project board.</p> <p>If you have any questions, issues you would like to raise please visit our <a href="https://gitlab.com/Linaro/WindowsPerf/windowsperf/-/issues">WindowsPerf GitLab issue page</a> and create a new issue with a clear description of the problem you’re facing or issue you want help with.</p> Przemyslaw_WirkusWe are happy to announce the latest WindowsPerf release version 3.3.0. This major release is a continuation of WindowsPerf development effort. For previous release information check this content out.Fosdem 24 is here, and Linaro is present at the event more than ever2024-02-02T00:49:28+00:002024-02-02T00:49:28+00:00https://www.linaro.org/events/fosdem-24-is-here-and-linaro-is-present-at-the-event-more-than-ever<p><br /> The 2024 edition of <a href="https://fosdem.org/2024/">Fosdem</a> is upon us. The <a href="https://fosdem.org/2024/practical/transportation/">Université libre de Bruxelles</a> will host the event again on February 3rd and 4th, and the program is more prosperous than ever. Linaro will attend the event with eight talks (having submitted about a dozen): a record-breaking presence and acceptance ratio! Beer is constantly flowing at Fosdem, yet there is no indication that Belgian beer is much better this year to draw the attention of so many of the following Linaro open-source contributors. Neil Armstrong will open the dance by discussing Linux mainline kernel support for Qualcomm’s SoCs. Over the past years, Qualcomm’s supported platforms have significantly increased, and features such as power management and DSP, historically complex to support, have vastly improved. </p> <p>Yet, what use can you make of a Linux kernel without a proper EFI bootloader? Caleb Connolly will talk about the work they have been doing to improve Qualcomm support in upstream U-Boot and how such work can drastically lower the barrier of entry for distro support on Qualcomm-powered phones, IoT, IIoT, and auto devices.</p> <p>Speaking of phones and consumer devices, what are they without a camera? And what good is a camera for without the decency of a fully open, libcamera-based MIPI stack? Bryan O’Donoghue has done some work in this area, and he’ll be introducing it at Fosdem.</p> <p>At Linaro, we test multiple versions of the Linux kernel running on various ARM SoCs and reference boards. We track upstream closely and thus update the kernel running on such devices frequently, and we can’t afford to throw away artifacts that need no change. And being Linaro a distributed company, can we afford to buy hardware in excess for all engineers collaborating on the same projects? Remi Duraffort will explain in his two talks how he’s put Kisscache to good use to maximize artifact reuse for Linux Kernel Function Testing and how he’s designed LAVA so it can perform testing of software on real devices that are metaphysical (ghosts?!) in nature (spooky Remi!).</p> <p>Remote attestation has historically been a headache for application developers, yet recent developments have made such technology crucial for establishing trust in confidential workloads accessible to most. Thomas Fossati will present this topic, while Dmitry Baryshkov will explain his work to leverage linux-yocto as the default kernel across Qualcomm SoCs enabled by meta-qcom, moving away from a kernel branch dedicated to Qualcomm.</p> <p>Open-source is glorious, and working on open-source projects within the open-source community provides a sense of purpose to many developers worldwide. Yet it’s not easy, and conflicts arise more often than not. Conflicts and disagreements are a vital part of the peer-review process and contribute to the superb quality of open-source software. So long as they are managed! William Gray has readied a lightning talk to look into examples and best practices. I have heard him deliver this talk at Linaro many times, and there’s always something new to learn, even for seasoned open-source developers.</p> <p>And with this, I conclude by wishing everyone a great Fosdem 2024. The Linaro team members look forward to seeing you at their talks and sharing one or two hundred beers with open-source friends coming to Brussels from around the world.</p>linaroThe 2024 edition of Fosdem is upon us. The Université libre de Bruxelles will host the event again on February 3rd and 4th, and the program is more prosperous than ever. Linaro will attend the event with eight talks (having submitted about a dozen): a record-breaking presence and acceptance ratio! Beer is constantly flowing at Fosdem, yet there is no indication that Belgian beer is much better this year to draw the attention of so many of the following Linaro open-source contributors. Neil Armstrong will open the dance by discussing Linux mainline kernel support for Qualcomm’s SoCs. Over the past years, Qualcomm’s supported platforms have significantly increased, and features such as power management and DSP, historically complex to support, have vastly improved. Subkeys in OP-TEE part I2024-01-22T04:48:06+00:002024-01-22T04:48:06+00:00https://www.linaro.org/blog/subkeys-in-op-tee-part-1<h1 id="introduction">Introduction</h1> <p>OP-TEE is a secure world OS implementation, that adheres to the GlobalPlatform specifications [1] [2] and is maintained by Linaro.</p> <p>Trusted Applications (TAs) could initially only be verified with a single public root key so all TAs deployed on a system had to be signed with the same private root key. With multiple vendors being involved in products and wanting to deploy their own TAs, having a single signer doesn’t scale well. In this blog, we will describe how subkeys can be used to address this problem.</p> <h1 id="a-single-root-key-versus-a-subkey-hierarchy">A single root key versus a subkey hierarchy</h1> <p>Subkeys support was introduced in OP-TEE version 3.20.0 (released January 20th, 2023) to provide a public key hierarchy allowing different actors to sign different TAs without sharing a private key.</p> <picture> <source data-srcset="/../generated/assets/images/content/figure-1-signing-tas-with-a-common-root-key--400-fec46b.webp 400w, /../generated/assets/images/content/figure-1-signing-tas-with-a-common-root-key--624-fec46b.webp 624w" type="image/webp" /> <source data-srcset="/../generated/assets/images/content/figure-1-signing-tas-with-a-common-root-key--400-fec46b.png 400w, /../generated/assets/images/content/figure-1-signing-tas-with-a-common-root-key--624-fec46b.png 624w" type="image/png" /> <img class="lazyload img-fluid blog_content_image" data-src="/../generated/assets/images/content/figure-1-signing-tas-with-a-common-root-key--624-fec46b.png" alt="Figure 1: Signing TAs with a common root key" /> </picture> <p><br /> <strong>Figure 1: Signing TAs with a common root key</strong></p> <p>The private key of the root key is needed when signing TA8 in the example in Figure 1. </p> <p>Problem: if the private key of the root key leaks any of the TAs can be updated by someone with access to that key.</p> <picture> <source data-srcset="/../generated/assets/images/content/figure-2-signing-tas-with-a-subkey-400-a1587a.webp 400w, /../generated/assets/images/content/figure-2-signing-tas-with-a-subkey-693-a1587a.webp 693w" type="image/webp" /> <source data-srcset="/../generated/assets/images/content/figure-2-signing-tas-with-a-subkey-400-a1587a.png 400w, /../generated/assets/images/content/figure-2-signing-tas-with-a-subkey-693-a1587a.png 693w" type="image/png" /> <img class="lazyload img-fluid blog_content_image" data-src="/../generated/assets/images/content/figure-2-signing-tas-with-a-subkey-693-a1587a.png" alt="Figure 2: Signing TAs with a subkey" /> </picture> <p><br /> <strong>Figure 2: Signing TAs with a subkey</strong><br /> <br /> Only the private key of the Group 4 subkey is needed when signing TA7 and TA8 in the example in Figure 2. The private keys of the root key and Company B subkey can be kept safe offline. If the private key of the Group 4 subkey leaks, only TAs signed with that subkey can be updated by someone with access to that key. Since only a smaller group of people need access to that key it will be easier to keep it safe compared to the example in Figure 1 where everyone who needs to update a TA must have access to the root key.</p> <h1 id="stay-tuned">Stay tuned</h1> <p>In this blog we did a quick overview of subkeys, in the coming part 2 we will do a deep dive into the details.</p> <ul> <li><a href="https://lists.trustedfirmware.org/mailman3/lists/op-tee.lists.trustedfirmware.org/">Subscribe</a> to the OP-TEE mailing list <a href="mailto:op-tee@lists.trustedfirmware.org">op-tee@lists.trustedfirmware.org</a></li> <li>Join the <a href="https://www.trustedfirmware.org/meetings/">Linaro OP-TEE Contributions (LOC) monthly meeting</a> or check out the project page <a href="https://linaro.atlassian.net/wiki/spaces/LOC/overview">Linaro’s OP-TEE Contributions - Confluence</a></li> <li>Visit the <a href="https://www.trustedfirmware.org/projects/op-tee/">OP-TEE page</a> at trusted firmware.</li> </ul> <p>Thank you for reading this far. If you have any questions or thoughts feel free to create an issue at <a href="https://github.com/OP-TEE/optee_os/issues">https://github.com/OP-TEE/optee_os/issues</a> or to reach out on the mailing list. You’re also welcome to join the LOC meetings.</p> <h1 id="references">References</h1> <p>[1] <a href="https://globalplatform.org/specs-library/tee-client-api-specification/">GlobalPlatform TEE Client API Specification v1.0</a> </p> <p>[2] <a href="https://globalplatform.org/specs-library/tee-internal-core-api-specification/">GlobalPlatform Internal Core API Specification v1.3.1</a></p>jens.wiklanderIntroductionInstalling Fedora with UEFI HTTP boot2024-01-19T03:00:49+00:002024-01-19T03:00:49+00:00https://www.linaro.org/blog/installing-fedora-with-uefi-http-boot<h1 id="introduction">Introduction</h1> <p>U-Boot natively supports PXE boot which uses UDP and TFTP as file transfer protocols. The UEFI specification describes the UEFI HTTP/HTTPs Boot. HTTP/HTTPs boot is a technology that allows devices to boot directly from the resources provided over the network and does not require preparing the physical installation media or setting up local tftp servers. You can find more details about UEFI HTTP Boot <a href="https://www.linaro.org/blog/ledge-blogs-uefi-http-and-https-boot-in-u-boot/">here</a>.</p> <p>Nowadays U-Boot supports downloading files via HTTP using ‘wget’, and mounting ISO images with the ‘blkmap’ command. Let’s see how combining those two UEFI HTTP Boot can be implemented using the UEFI BootManager.</p> <h1 id="turning-on-the-feature">Turning on the feature</h1> <p>UEFI HTTP Boot needs DNS to resolve the http server IP address, WGET to download the file from http server, and ‘blkmap’ to mount the downloaded ISO image. This is achievable in U-Boot via existing commands, but this is cumbersome and can’t be added as part of the device bootflow. With <a href="https://lore.kernel.org/u-boot/20231025062845.3100964-1-masahisa.kojima@linaro.org/">this series</a> applied, UEFI HTTP Boot becomes a standard functionality of the efibootmgr. </p> <p>After applying the parches Kconfig options CONFIG_CMD_DNS, CONFIG_CMD_WGET, CONFIG_BLKMAP and CONFIG_EFI_HTTP_BOOT need to be enabled. With these in place U-Boot can:</p> <ul> <li>Add a boot option containing a URI device path with ‘efidebug’ command </li> <li>Obtain the dns server ip address from ‘serverip’ environment variable</li> <li>Download an .iso image via WGET and store it in the destination address. It’s worth noting that the available memory starting from ‘loadaddr’ must be big enough to store the ISO image. We will be using the Fedora Server 38 ISO image in this blog which is approximately 657MB. </li> <li>Mount the iso image </li> <li>Boot it up and start the installation</li> </ul> <p>We are using the Socionext Developerbox in this blog. A new “efidebug boot add -u” is added by <a href="https://lore.kernel.org/u-boot/20231025062845.3100964-7-masahisa.kojima@linaro.org/">this patch</a> and allows us to add the URI device path boot option.</p> <div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>dhcp setenv loadaddr 90000000 setenv serverip 192.168.1.1 efidebug boot add -u 3 fedora-netinst http://dl.fedoraproject.org/pub/fedora/linux/releases/38/Server/aarch64/iso/Fedora-Server-netinst-aarch64-38-1.6.iso bootmenu </code></pre></div></div> <p>Note: U-Boot does not currently support HTTPS and HTTP redirection, so we need to specify an HTTP server without it. Closest mirror is also available.</p> <h1 id="run-uefi-http-boot">Run UEFI HTTP Boot</h1> <p>When the menu appears on the console we can start the UEFI HTTP Boot by selecting the boot option ‘fedora-netinst’ we just added.</p> <picture> <source data-srcset="/../generated/assets/images/content/uboot-bootmenu-400-fe8d08.webp 400w, /../generated/assets/images/content/uboot-bootmenu-636-fe8d08.webp 636w" type="image/webp" /> <source data-srcset="/../generated/assets/images/content/uboot-bootmenu-400-fe8d08.png 400w, /../generated/assets/images/content/uboot-bootmenu-636-fe8d08.png 636w" type="image/png" /> <img class="lazyload img-fluid blog_content_image" data-src="/../generated/assets/images/content/uboot-bootmenu-636-fe8d08.png" alt="uboot bootmenu" /> </picture> <p>U-Boot will automatically start the download of the Fedora ISO installer.</p> <picture> <source data-srcset="/../generated/assets/images/content/uboot-wget-download-400-9ac7dc.webp 400w, /../generated/assets/images/content/uboot-wget-download-640-9ac7dc.webp 640w" type="image/webp" /> <source data-srcset="/../generated/assets/images/content/uboot-wget-download-400-9ac7dc.png 400w, /../generated/assets/images/content/uboot-wget-download-640-9ac7dc.png 640w" type="image/png" /> <img class="lazyload img-fluid blog_content_image" data-src="/../generated/assets/images/content/uboot-wget-download-640-9ac7dc.png" alt="uboot wget download" /> </picture> <p>After the download completes, the Fedora installer is launched. </p> <picture> <source data-srcset="/../generated/assets/images/content/start-fedora-installation-400-ef347e.webp 400w, /../generated/assets/images/content/start-fedora-installation-643-ef347e.webp 643w" type="image/webp" /> <source data-srcset="/../generated/assets/images/content/start-fedora-installation-400-ef347e.png 400w, /../generated/assets/images/content/start-fedora-installation-643-ef347e.png 643w" type="image/png" /> <img class="lazyload img-fluid blog_content_image" data-src="/../generated/assets/images/content/start-fedora-installation-643-ef347e.png" alt="Start Fedora installation" /> </picture> <p><br /> Since the ramdisk created by U-Boot is not passed to the OS and installer loses the access to it after ExitBootServices, in order to continue the Fedora installation, an extra parameter needs to be defined during boot. Select the “Install Fedora 38” entry, then press ‘e’ to edit the commands (it’s worth noting that the procedure is identical for EDK2).</p> <picture> <source data-srcset="/../generated/assets/images/content/edit-inst.stage2-400-b74239.webp 400w, /../generated/assets/images/content/edit-inst.stage2-639-b74239.webp 639w" type="image/webp" /> <source data-srcset="/../generated/assets/images/content/edit-inst.stage2-400-b74239.png 400w, /../generated/assets/images/content/edit-inst.stage2-639-b74239.png 639w" type="image/png" /> <img class="lazyload img-fluid blog_content_image" data-src="/../generated/assets/images/content/edit-inst.stage2-639-b74239.png" alt="edit inst.stage2" /> </picture> <p><br /> Add ‘inst.stage2’ kernel parameter to point to the appropriate http server. The following http server must be used:</p> <div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>inst.stage2=https://dl.fedoraproject.org/pub/fedora/linux/releases/38/Server/aarch64/os/ </code></pre></div></div> <p>Press F10 to start the installer. Since I am using the box in headless mode (the GPU support has <a href="https://www.96boards.org/documentation/enterprise/developerbox/support/known-issues.html">known issues</a>), installing via VNC is a nice option.</p> <picture> <source data-srcset="/../generated/assets/images/content/vnc-fedora-installation-400-b4491a.webp 400w, /../generated/assets/images/content/vnc-fedora-installation-800-b4491a.webp 800w, /../generated/assets/images/content/vnc-fedora-installation-1026-b4491a.webp 1026w" type="image/webp" /> <source data-srcset="/../generated/assets/images/content/vnc-fedora-installation-400-b4491a.png 400w, /../generated/assets/images/content/vnc-fedora-installation-800-b4491a.png 800w, /../generated/assets/images/content/vnc-fedora-installation-1026-b4491a.png 1026w" type="image/png" /> <img class="lazyload img-fluid blog_content_image" data-src="/../generated/assets/images/content/vnc-fedora-installation-800-b4491a.png" alt="VNC Fedora Installation" /> </picture> <p>It’s worth noting that since U-Boot does not support SetVariable at runtime you’ll get an error while the installer is trying to update the EFI Boot#### variables. This is not fatal, you can just continue the installation and fix up the boot options later.</p> <picture> <source data-srcset="/../generated/assets/images/content/fedora-installation-setvariable-error-400-4ddd9e.webp 400w, /../generated/assets/images/content/fedora-installation-setvariable-error-800-4ddd9e.webp 800w, /../generated/assets/images/content/fedora-installation-setvariable-error-1022-4ddd9e.webp 1022w" type="image/webp" /> <source data-srcset="/../generated/assets/images/content/fedora-installation-setvariable-error-400-4ddd9e.png 400w, /../generated/assets/images/content/fedora-installation-setvariable-error-800-4ddd9e.png 800w, /../generated/assets/images/content/fedora-installation-setvariable-error-1022-4ddd9e.png 1022w" type="image/png" /> <img class="lazyload img-fluid blog_content_image" data-src="/../generated/assets/images/content/fedora-installation-setvariable-error-800-4ddd9e.png" alt="Fedora installation SetVariable error" /> </picture> <p><br /> After the installation completes, reboot the board and manually add the boot option in U-Boot console.</p> <div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>efidebug boot add -b 5 fedora mmc 0:1 EFI/fedora/grubaa64.efi efidebug boot order 5 </code></pre></div></div> <h1 id="future-work">Future work</h1> <p>UEFI HTTP Boot provides a more reliable file transfer mechanism than UDP/TFTP of PXE, we can boot the system without preparing the physical installation media and install the system simultaneously among multiple devices with the official distro download URI without a local server.</p> <p>We intend to upstream the aforementioned patches and try to further automate the installation procedure eliminating the need to add the special kernel command line in GRUB.</p>Masahisa.KojimaIntroductionQualcomm and Linaro Enable Latest Flagship Snapdragon Compute SoC2024-01-04T23:10:33+00:002024-01-04T23:10:33+00:00https://www.linaro.org/blog/qualcomm-and-linaro-enable-latest-flagship-snapdragon-compute-soc<h1 id="running-fully-fledged-debian-desktop-including-gpu-rendering-with-patches-on-top-of-linux-next-on-the-x-elite-x1e80100-platform-even-before-it-has-been-announced">Running fully fledged Debian desktop (including GPU rendering) with patches on top of linux-next on the X Elite (X1E80100) platform even before it has been announced</h1> <p>For many years the Qualcomm Landing Team at Linaro has joined forces with Qualcomm to help deliver launch-day support for new SoCs. This past year we have been developing a kernel that supports the recently-announced Snapdragon X Elite. In previous years we have been able to provide basic boot-to-shell support on launch day. At the X Elite launch, not only did we have these features ready to roll but we already had full Debian desktop working, complete with display, GPU and WiFi.</p> <p>The collaboration between Qualcomm and Linaro engineers, harnessed together, has pushed the boundaries of initial upstream support beyond just basic boot-to-shell. The patches will be driven all the way into the mainline in the coming months. In the meantime, a public <a href="https://git.codelinaro.org/linaro/qcomlt/demos/linux/-/tree/x1e80100">tree</a> based on the most recent linux-next is available. This builds upon the years-long efforts of Linaro engineers making upstream bring-up easier for each new Qualcomm platform.</p> <p>When announced, the <a href="https://docs.qualcomm.com/bundle/publicresource/87-71417-1_REV_C_Snapdragon_X_Elite_Product_Brief.pdf">X1E80100</a> demonstrated very impressive benchmark results. The single- and multi-core results were captured using systems running the kernel and Debian images provided by the team.</p> <h1 id="upstreaming-strategy">Upstreaming strategy</h1> <p>The upstreaming effort was split into two main parts since the development was done jointly by the collaboration between Qualcomm and Linaro engineers. First, an initial series that supports <a href="https://lore.kernel.org/all/?q=x1e80100">boot-to-shell</a> was posted for review right after announcement, making its way into mainline already; other patchsets for the rest of the supported features are already under review. Posting the patches in two parts was also done because the platform was launched near the end of the Linux development cycle (v6.6-rc7). </p> <p>The first series includes the following features:</p> <ul> <li>Qualcomm® Oryon™ CPUs</li> <li>Clocks, interconnects, regulators, power domains and pinctrl providers</li> <li>Low-Speed I/O: I2C, SPI, UART</li> <li>Compute Reference Device (CRD) board support, with coverage of all the drivers above</li> <li>Qualcomm Compute Platform (QCP) board support, also covering the drivers above</li> </ul> <p>At the time of writing, the interconnects, pinctrl and power domains have already been merged.</p> <p>Patches for the remaining features are already under review; they include support for:</p> <ul> <li>CPUFreq support </li> <li>High-Speed peripherals: PCIe Gen3 and Gen4, USB SuperSpeed</li> <li>Embedded DisplayPort support</li> <li>GPU support</li> <li>Qualcomm® Hexagon™ Processor SubSystem (Audio)</li> <li>More Compute Reference Design (CRD) specific support (trackpad, touchscreen, keyboard, battery management, NVMe and WLAN)</li> </ul> <p>Linaro’s Qualcomm Landing Team has prepared a <a href="https://git.codelinaro.org/linaro/qcomlt/demos/linux/-/tree/x1e80100">kernel tree on CodeLinaro</a> that provides all of the support mentioned above.</p> <h1 id="debian-on-snapdragon-x-elite-x1e80100-compute-reference-device">Debian on Snapdragon X Elite (X1E80100) Compute Reference Device</h1> <p>Linaro provides <a href="https://git.codelinaro.org/linaro/qcomlt/demos/debian-12-installer-image">a step-by-step guide</a> on how to prepare the installer media that will take you all the way through to a full Debian system, including GPU and WiFi support. </p> <p>The installer also includes GRUB, which provides dual-boot support out-of-the-box and also allows chainloading other EFI applications, including the Fastboot EFI app. Booting via fastboot protocol helps a lot when it comes to rapid kernel development and testing because it avoids the need to build the deb package and install it manually. Instead, you can boot the kernel image with the devicetree blob and the initramfs (including the modules) provided via a boot image (similar to other mobile platforms).</p> <picture> <source data-srcset="/../generated/assets/images/content/debian-running--400-900177.webp 400w, /../generated/assets/images/content/debian-running--800-900177.webp 800w, /../generated/assets/images/content/debian-running--1200-900177.webp 1200w" type="image/webp" /> <source data-srcset="/../generated/assets/images/content/debian-running--400-900177.png 400w, /../generated/assets/images/content/debian-running--800-900177.png 800w, /../generated/assets/images/content/debian-running--1200-900177.png 1200w" type="image/png" /> <img class="lazyload img-fluid blog_content_image" data-src="/../generated/assets/images/content/debian-running--800-900177.png" alt="Debian running on top of latest linux-next, with GPU rendering, on Snapdragon X Elite (X1E80100) Compute Reference Device" /> </picture> <h1 id="whats-next">What’s next</h1> <p>The upstreaming effort will continue in the coming months and will include more boards/platforms/features based on X1E80100. The engineers from both Qualcomm and Linaro will continue to work closely with upstream maintainers to get all support needed by the X1E80100 accepted upstream. Work is underway to enable audio and camera support as well; these features are planned for inclusion in the Linux v6.9 kernel.</p> <h1 id="want-to-learn-more">Want to learn more?</h1> <p>If you want to follow closely the upstreaming of the X1E80100, you can head to <a href="https://lore.kernel.org/all/?q=x1e80100">https://lore.kernel.org/all/?q=X1E80100</a>.</p> <p>More information about the Snapdragon X Elite (X1E80100) can be found here: <a href="https://docs.qualcomm.com/bundle/publicresource/87-71417-1_REV_C_Snapdragon_X_Elite_Product_Brief.pdf">https://docs.qualcomm.com/bundle/publicresource/87-71417-1_REV_C_Snapdragon_X_Elite_Product_Brief.pdf</a></p> <p>For more information about what Linaro’s Qualcomm Platform Services does and has to offer, please head to <a href="https://www.linaro.org/services/qualcomm-platforms-services/">https://www.linaro.org/services/qualcomm-platforms-services/</a></p>Abel.vesaRunning fully fledged Debian desktop (including GPU rendering) with patches on top of linux-next on the X Elite (X1E80100) platform even before it has been announcedRust device backends for every hypervisor2023-12-14T05:42:53+00:002023-12-14T05:42:53+00:00https://www.linaro.org/blog/rust-device-backends-for-every-hypervisor<p>As part of project <a href="https://linaro.atlassian.net/wiki/spaces/ORKO/overview">Orko</a> we have been busy improving the ecosystem of edge-computing. A fundamental part of that has been the infrastructure work to enable hypervisor agnostic virtio backends. Today we are giving a status update on our work in this area and discuss how the rust-vmm ecosystem helps us with our mission.</p> <h1 id="introduction-to-virtio">Introduction to Virtio</h1> <p>Virtio has standardized how paravirtualized guests talk with host devices. Instead of going down the stack to the very bottom where a device access is trapped and a physical device is faked, we switch at a higher level. Instead of trying to emulate a very specific piece of hardware, virtio provides a protocol for each type of device. The guest can then efficiently issue requests to a device without caring about the details of the backend implementation. This removes the need for hypervisor-specific drivers in the guest. Efficient shared-memory structures also reduce the number of context switches to the hypervisor. Overall this allows virtio to simplify both the guest and the hypervisor side while also providing great performance.</p> <picture> <source data-srcset="/../generated/assets/images/content/virtio_-400-de6616.webp 400w, /../generated/assets/images/content/virtio_-800-de6616.webp 800w, /../generated/assets/images/content/virtio_-1200-de6616.webp 1200w" type="image/webp" /> <source data-srcset="/../generated/assets/images/content/virtio_-400-de6616.png 400w, /../generated/assets/images/content/virtio_-800-de6616.png 800w, /../generated/assets/images/content/virtio_-1200-de6616.png 1200w" type="image/png" /> <img class="lazyload img-fluid blog_content_image" data-src="/../generated/assets/images/content/virtio_-800-de6616.png" alt="Diagram that demonstrates the execution path of a virtio-backend device. By not trapping on a system bus level, some abstraction layers in both host and guest kernel become unnecessary." /> </picture> <p><em>Figure 1: With the guest kernel coordinating, virtio allows to avoid frequent and costly traps on low-level system level. Instead, a generic virtio driver can efficiently transfer buffers to the virtio backend.</em></p> <h1 id="the-missing-edge">The missing edge</h1> <p>While most of today’s virtualization usage happens in traditional data-centers, single chips have become tremendously powerful in recent years. This provides significant computing resources in edge devices. A single chip now has enough head-room to handle multiple tasks. As an example, the automotive industry is challenged by increasingly software-heavy systems and is looking for ways to consolidate functionality onto fewer, more powerful devices. <a href="https://www.soafee.io/">SOAFEE</a> is an interest group that is looking to enable that using cloud-native technology.</p> <p>Compared to traditional cloud setups, software on the edge typically will interface with a wider range of hardware. Storage and networking solutions have a very healthy virtio ecosystem due to the massively virtualized cloud infrastructure. But edge devices may also want to read that temperature sensor over I2C, steer a GPIO pin or run machine learning tasks on a video stream input. Typical solutions for this often involved pass-through of the specific hardware. This ties the VM to a hardware-specific solution which of course goes against the cloud spirit of abstracting away concrete hardware solutions. Linaro has been actively filling this gap by contributing towards virtio standards for protocols like I2C, GPIO or IOMMU.</p> <p>Industrial or automotive use cases also frequently come with different requirements than those found in the cloud. A self-driving vehicle might impose stricter real-time and safety demands compared to a throughput-optimized server. Type-2 hypervisors depend on fairly complex operating system infrastructure to schedule domains. This makes it difficult to verify the freedom from interference of individual domains. Xen, especially in dom0less mode, offers a road towards simplifying that problem a lot. Instead of needing to reason about a full kernel and user-space that control VMs one can consider a much smaller core.</p> <p>There is a problem though… while virtio standardizes the interface between the hypervisor and the guest, the compatibility of backends across hypervisors is less established.</p> <h1 id="reusing-vhost-user-daemons-across-hypervisors">Reusing vhost-user daemons across hypervisors</h1> <p>Today most hypervisors or cloud providers use virtio to some degree. But the actual implementation of the backend typically is hypervisor-specific. The control and data plane of the device were typically split in order to allow the data plane to interface with the guest without costly hypervisor mediation. The vhost protocol describes the coordination between the control and data plane happens. This allows offloading of data plane tasks to the host kernel, but it still requires a fairly tight coupling with the control plane that is tied to the hypervisor. Moving complex handling of untrusted, guest-controlled memory into the kernel may also be undesired from a security perspective.</p> <p>vhost-user was modeled after vhost but allows offloading backend tasks to a user-space daemon. Yet, being replacements for data-plane only kernel modules, most vhost-user daemons still ended up being dependent on hypervisor-specific shims that make it difficult to reuse daemons. For example, QEMU’s vhost-user devices handle configuration and setup in the hypervisor and the backend daemon only does the data plane handling. Support for querying configuration and control data was eventually added to the specification, but the QEMU devices still follow the original vhost architecture where only the actual device emulation was offloaded to a separate process. This makes it hard to reuse these daemons for other hypervisors that lack these frontend stubs. Backends typically are expected to be configured in specific ways that are not particularly documented or standardized, breaking if their matching frontend stub is missing.</p> <p>Ideally, a hypervisor would only need to implement one of the virtio transport mechanisms and simply forward control requests to the backends. We have been busy working on <a href="https://lore.kernel.org/all/20230710153522.3469097-1-alex.bennee@linaro.org/#t">improving that situation</a>. Progress has been made to support truly standalone vhost-user daemons and reduce the amount of boilerplate code in the frontends. The final step is to also query the actual device type from the backend. This would limit the configuration in the hypervisor to a simple list of backend sockets. The hypervisor can then treat every device class the same, regardless of the actual type.</p> <p>We also started demonstrating this concept by proving vhost-device daemons working for both QEMU and Xen. By enabling Xen support for virtiofsd we also proved the concept on an independent, well-established daemon. Adding Xen support to this range of daemons was mostly enabled by adding support for Xen memory mappings to the core rust-vmm libs.</p> <h1 id="the-virtio-rust-ecosystem">The virtio Rust ecosystem</h1> <p>As the name might suggest, rust-vmm is written in Rust. While user-space backends may run as unprivileged users and use sandboxing, virtual devices are still a prime target for attackers. Rust’s type and memory-safety guarantees as well as native speed make it a good choice here. rust-vmm was not first to identify this. crosvm came first as Google’s solution for securing Linux on Chromebooks and Android VMs. Firecracker started as a hypervisor for microVMs and Cloud Hypervisor followed while targeting general purpose VMs.</p> <p>In order to allow collaboration across these projects, rust-vmm was founded. Initially starting off with bits from crosvm, rust-vmm components saw use as building blocks for Firecracker and Cloud Hypervisor. As universal, hypervisor agnostic building blocks, these components also were a perfect match for Linaro’s vision of reusable device backends. Today, we maintain a quickly growing number of backend daemons under the umbrella of the vhost-device repository.</p> <p>As of today, that repository has daemons for GPIO, I2C, random number generators, SCMI, SCSI, VSOCK, sound and video devices. Virtiofsd, while developed outside of the rust-vmm umbrella, also is based on the same rust-vmm libraries as the vhost-device ones.</p> <p>Outside of the rust-vmm ecosystem, crosvm also comes with a few additional virtio backends. However, these backends are built into the KVM-backed crosvm hypervisor and cannot easily be used in other setups. While some rust-vmm components originated in crosvm, rust-vmm exports them as reusable components. This allows hypervisors and vhost-user daemons to use the same building blocks without needing to reinvent the wheel.</p> <p>This layered toolbox architecture helped us when <a href="https://github.com/rust-vmm/vm-memory/pull/241">adding Xen support</a> by abstracting the required memory mapping logic away from the daemon. After adding Xen guest memory maps to vm-memory, Xen support for the entire rust-vmm ecosystem came “for free”. It also paves the way for more secure memory models where access is granted on page granularity instead of the entire guest memory. Eventually this will allow offloading device backends to other virtual machines that may be highly restricted in their access.</p> <picture> <source data-srcset="/../generated/assets/images/content/rust-vmm-400-54046f.webp 400w, /../generated/assets/images/content/rust-vmm-800-54046f.webp 800w, /../generated/assets/images/content/rust-vmm-1200-54046f.webp 1200w" type="image/webp" /> <source data-srcset="/../generated/assets/images/content/rust-vmm-400-54046f.png 400w, /../generated/assets/images/content/rust-vmm-800-54046f.png 800w, /../generated/assets/images/content/rust-vmm-1200-54046f.png 1200w" type="image/png" /> <img class="lazyload img-fluid blog_content_image" data-src="/../generated/assets/images/content/rust-vmm-800-54046f.png" alt="A diagram that illustrates rust-vmm's layers of abstraction. vmm-sys-util and vm-memory serve as the lowest level building blocks. vm-virtio, vhost and vhost then become increasingly more abstract" /> </picture> <p><em>Figure 2: rust-vmm is organized into many crates that abstract individual aspects of virtualization. Of particular interest for us are vm-memory (abstraction of mmap’d guest memory), virtio-queue (tools for handling virtio descriptors) and vhost-user-backend (implementation of the vhost-user protocol). While the number of crates may be overwhelming at start, it allows you to pick and choose the tools needed for the particular task.</em></p> <p>Overall, rust-vmm is maturing into a versatile and highly reusable ecosystem. The flexibility makes it a great choice to demonstrate new virtualization technologies and the rigorously tested Rust code base provides confidence in code and changes.</p> <h1 id="outlook">Outlook</h1> <p>Linaro is working towards showcasing all the newly developed features in a Demo during Connect 2024. We plan to demonstrate SOAFEE use-cases on top of our <a href="https://gitlab.com/Linaro/trusted-reference-stack/trs">Trusted Reference Stack</a>. Our roadmap and current work items can be viewed on our <a href="https://linaro.atlassian.net/wiki/spaces/ORKO/overview">project page</a>. If you are interested in collaborating feel free to say hello on #linaro-virtualization on libera.chat or checkout our other <a href="https://www.linaro.org/blog/tags/?tag=Virtualization">virtualization blog posts</a>.</p>Erik.SchillingAs part of project Orko we have been busy improving the ecosystem of edge-computing. A fundamental part of that has been the infrastructure work to enable hypervisor agnostic virtio backends. Today we are giving a status update on our work in this area and discuss how the rust-vmm ecosystem helps us with our mission.