Clarify Project Policy on Default Writes to NVRAM

[Christian Marangi (Ansuel)]

Il giorno sab 23 ago 2025 alle ore 08:38 Tom Li via openwrt-devel
<openwrt-devel at lists.openwrt.org> ha scritto:
>
> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.
>
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.
>
>
> ---------- Forwarded message ----------
> From: Tom Li <tomli at tomli.me>
> To: openwrt-devel at lists.openwrt.org
> Cc:
> Bcc:
> Date: Fri, 22 Aug 2025 15:31:00 +0000
> Subject: Clarify Project Policy on Default Writes to NVRAM
> Hi all,
>
> For OpenWrt routers, writing to NVRAM by default can serve useful
> purposes in several contexts:
>
> 1. Saving a /dev/urandom seed file after boot, to prevent early-
> boot entropy starvation in the next boot. This was first discussed
> in 2016 [0], and raised again in 2022. [1]
>
> 2. Saving the last-known system date and time to /etc/dnsmasq.time
> for DNSSEC timestep validation, on every SIGTERM and reboot.
> Discussed in [2].
>
> 3. Saving the current IPv6 prefix on the WAN port (obtained from
> the ISP) to a file. If the router reboots due to power loss, and
> the ISP changes the IPv6 prefix in the next boot, the old prefix
> can be invalidated in a Router Advertisements to prevent IPv6
> outages in the LAN due to stale addresses. This is known as "Flash
> Renumbering Workaround Across Reboot", a recommended feature by
> RFC 9096 to work around broken ISPs. This need is raised in a recent
> odhcpd devolopment discussion [3], and is my motivation of sending
> this mail.
>
> An obvious objection to all of these behaviors is that, writing
> to the filesystem by default can cause unwanted NVRAM wears.
>
> As a result, any project discussion that involves writing to the
> filesystem would quickly become an off-topic one about "whether
> one should write to NVRAM by default" rather than its original
> problem. Although the answer seems to be "No, we shouldn't", but
> those discussions had an extremely limited audience - only a
> few developers (perhaps 3) who happened to work on that specific
> project were involved, their ideas and conclusions are not known
> to others. The next time the same problem is raised in a different
> context, the whole discussion repeats again. For example, in [1],
> Etienne Champetier said that they "would love to have more devs
> comment".
>
> While I was writing this mail, I just found it was also discussed
> on the context of https-dns-proxy [4] in 2024 - dnsmasq config was
> changed on every https-dns-proxy service restart, which was reported
> as a bug.
>
> Therefore, I think it would be a good idea to define a clear OpenWrt
> project policy on default writes to NVRAM in this mailing list, so
> all future developers could refer to the policy.
>
> We need to answer these questions:
>
> 1. In the current OpenWrt Stable Release or Development Build,
> do we have anything that writes to the filesystem by default
> (e.g. do we still have /etc/dnsmasq.time)? If yes, do we have
> a full list of them?
>
> 2. When is it acceptable to write to NVRAM by default? Always
> banned? Or is it conditionally allowed, with a rate limit (based
> on the file's timestep and NTP time, via NTP hotplug)? My
> impression is that rate-limited writes are allowed by the project,
> but this needs clarification.
>
> 3. Should we set a filesystem default-write policy for all OpenWrt
> packages?
>
> 4. In a previous discussion, an alternative solution was suggested
> by John Crispin that "let's add a system.system.write_state_to_
> flash_on_boot=0/1 UCI option, and lock this and the DNSSEC time
> stuff with it, and default it to 0". Should we consider this idea?
>

Some point on this... With NVRAM we intend the flash right? (that is
eMMC, NAND, NOR...)

Because AFAIK we already save the random seed as it's only created
on first boot.

Time and day is not saved as it's not valid anyway as it will lose time
between the reboots.

For IPv6 RFC that is another topic and might be interesting to implement.

Also I think we are pretty liberal on the write as long as we don't apply
broken logic like writing log to flash or other kind of periodic write.