<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Updates on Rootcommit WIP</title>
    <link>https://rootcommit.l0g.eu/tags/updates/</link>
    <description>Recent content in Updates on Rootcommit WIP</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 15 Apr 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://rootcommit.l0g.eu/tags/updates/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>U-Boot: protect sensitive environment variables</title>
      <link>https://rootcommit.l0g.eu/2026/u-boot-protect-sensitive-environment-variables/</link>
      <pubDate>Wed, 15 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://rootcommit.l0g.eu/2026/u-boot-protect-sensitive-environment-variables/</guid>
      <description>&lt;p&gt;This is a follow-up from our &lt;a href=&#34;https://rootcommit.l0g.eu/2026/accessing-u-boot-env-from-c/&#34;&gt;Accessing the U-Boot environment from a C program&lt;/a&gt; blog post.&lt;/p&gt;&#xA;&lt;h3 id=&#34;need-to-protect-the-environment&#34;&gt;🌳Need to protect the environment&lt;/h3&gt;&#xA;&lt;p&gt;When you&amp;rsquo;re trying to harden an embedded Linux device to make it more resistant to attacks, one key part to secure is the bootloader, because that&amp;rsquo;s the part that boots the operating system. Even you implement a &lt;strong&gt;secure boot&lt;/strong&gt; chain, if an attacker manages to interrupt the boot process and get access to the bootloader shell, this attacker would be able to load and run her/his own payload on the device.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Accessing the U-Boot environment from a C program</title>
      <link>https://rootcommit.l0g.eu/2026/accessing-u-boot-env-from-c/</link>
      <pubDate>Wed, 08 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://rootcommit.l0g.eu/2026/accessing-u-boot-env-from-c/</guid>
      <description>&lt;h3 id=&#34;need-to-modify-the-u-boot-environment-from-linux&#34;&gt;Need to modify the U-Boot environment from Linux&lt;/h3&gt;&#xA;&lt;!-- raw HTML omitted --&gt;&#xA;&lt;p&gt;&lt;img src=&#34;../images/update-and-recovery.excalidraw-scaled.png&#34; alt=&#34;Update and Recovery Management with SWUpdate and U-Boot&#34;&gt;&lt;/p&gt;&#xA;&lt;!-- raw HTML omitted --&gt;&#xA;&lt;p&gt;A/B update and recovery workflow implemented for a Root Commit customer&lt;/p&gt;&#xA;&lt;!-- raw HTML omitted --&gt;&#xA;&lt;!-- raw HTML omitted --&gt;&#xA;&lt;p&gt;There are multiple reasons for wanting to modify U-Boot variables from Linux, one of them being to implement &lt;a href=&#34;https://bootlin.com/pub/conferences/2022/elce/opdenacker-implementing-A-B-system-updates-with-u-boot/opdenacker-implementing-A-B-system-updates-with-u-boot.pdf&#34;&gt;A/B update mechanisms&lt;/a&gt;. Typically, after you&amp;rsquo;ve flashed a device with a new version, you&amp;rsquo;ll set the &lt;code&gt;upgrade_available&lt;/code&gt; U-Boot variable to &lt;code&gt;1&lt;/code&gt;, reboot, and let U-Boot try to boot the new version.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
