[PATCH] docs: Clarify that the environment revision counter has an end-of-life

[Jan Kiszka]

From: Jan Kiszka <jan.k...@siemens.com>

We do not handle that case the a revision of an environment has reached
UINT32_MAX and was possibly updated by bg_setenv --update to 0. This
will lead to a non-update as the UINT32_MAX revision remains highest.

This could theoretically be address by special handling, but it is
practically not relevant and will therefore remain an ignored corner
case. Now at least a documented one.

Reported-by: Codex Security
Signed-off-by: Jan Kiszka <jan.k...@siemens.com>
---
docs/UPDATE.md | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/docs/UPDATE.md b/docs/UPDATE.md
index 17dd40d..8ca283f 100644
--- a/docs/UPDATE.md
+++ b/docs/UPDATE.md
@@ -5,6 +5,10 @@ The number is defined at compile-time. Each environment has a revision.
`efibootguard` always loads the latest environment data, which is indicated by
the highest revision value.

+*NOTE*: A wrap-around of the 32-bit revision counter is not handled. This case
+is considered irrelevant for practical scenarios (more than 4 billion
+update cycles).
+
The structure of the environment data is as follows:

```c
--
2.47.3