IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
UEFI provides a "monotonic boot counter" which is supposed to increase on
each reboot. We can include this in our random seed hash logic, which
makes things more robust in case our changes to the ESP end up not
actually being as persistent as we assume. As long as the monotonic boot
counter increases we should be good, as each boot we'll anyway end up
with a new seed that way.
This in fact should also pave the way that we can eventually enable the
random seed logic even on SecureBoot enabled systems. Why that? With
this change the input for the random seed hash is now:
1. the old seed file contents
2. (optionally) some bits from the UEFI RNG
3. (optionally) a per system random "token" stored in an UEFI variable,
initialized at OS install
4. the UEFI monotonic counter
5. a counter integer used by the random seed logic.
We can ignore #5 entirely for security considerations, it's always going
to be a constant series of values determined by the random seed logic.
The #1 file is under control of the attacker. (Since it resides in the
unprotected ESP)
The #2 data is possibly low quality. (it's hard enough to trust the
quality of the Linux RNG, let's not go as far as trusting the UEFI one)
The #3 data should not be under control of the attacker, and should only
exist if explicitly set. Unless you have privileged access to the system
you should not be able to read or set it. (well, within limits of flash
chip security and its connectivity to the firmware)
The #4 data is provided by the firmware, and should not be under control
of the attacker. If it works correctly then it might still be guessable
(i.e. a new system might have the counter close to zero).
Thus: 1+2+5 are guessable/under control of attacker, but 3+4 should not
be. Thus, if 3 is not known to attacker and not guessable, and 4
strictly monotonically increasing then it should be enough to guarantee
that every boot will get a different seed passed in, that should not be
known or guessable by the attacker.
That all said, this patch does not enable the random seed logic on
SecureBoot. That is left for a later patch.
This normally wouldn't happen, but if some of those places were called
with lhs and rhs being the same object, we could unref the last ref first,
and then try to take the ref again. It's easier to be safe, and with the
helper we save some lines too.
We canonicalize repeats that cover the whole range: "0:0:0/1" → "0:0:*". But
we'd also do "0:0:0/1,0" → "0:0:*,0", which we then refuse to parse. Thus,
first go throug the whole chain, and print a '*' and nothing else if any of the
components covers the whole range.
0..3 is not the same as 0..infinity, we need to check both ends of the range.
This logic was added in 3215e35c40, and back then
the field was called .value. .stop was added later and apparently wasn't taken
into account here.
Coverage data shows that we didn't test calendar_spec_next_usec() and
associated functions at all.
The input samples so far were only used until the first NUL. We take advantage
of that by using the part until the second NUL as the starting timestamp,
retaining backwards compatibility for how the first part is used.
calendar_spec_from_string() already calls calendar_spec_normalize(), so
there is no point in calling it from the fuzzer. Once that's removed, there's
just one internal caller and it can be made static.
It has been shown that the autosuspend delay for this device enacted
by modem manager will race with suspend and cause system suspend
failures.
This occurred in ChromiumOS on a chromebook, but there is no reason
it won't happen in regular notebooks with the same WWAN. To avoid
the failure delay autosuspend to a frequency longer than the polling
rate used by modem manager.
Link: https://chromium-review.googlesource.com/c/chromiumos/overlays/board-overlays/+/3635003
Link: 43e76bf1bb/src/mm-iface-modem.c (L1633)
