Re: kern.boottime drift after boot?
On Thu, 12 Oct 2023, Simon Burge wrote: Assuming of course that the boot_id is generated after interrupts are enabled and some jitter has been processed :). That's almost certainly the case: that UUID is only generated when userspace first reads it (and there aren't any kernel-consumers of that UUID that I'm aware of). See: proc_do_uuid(): https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/char/random.c?h=v6.5.7#n1609 The file was put in to support server-farms where you push an update to a bunch of machines, command them to reboot, then check if the machines have actually rebooted for the updates to "take". But, as abs@ just scoped out, it can have other uses too... -RVP
Re: kern.boottime drift after boot?
>> On embedded systems without an RTC, you _could_ get the same UUID in >> rare cases. But I think this would be a bug, because on Linux, any >> kind of jitter-source (interrupt timing, for instance) would perturb >> the generated UUID. > Hopefully! Even though this jitter might not be high entropy, it > should (in theory) be enough to give a differnet UUID each boot. Probably. Depending on how the entropy and RNG are handled, it is likely to be different only with some (relatively high) probability. What probability of collision (ie, of a boot giving the same value as the previous boot) is acceptable here? One in 256? One in 64k? One in 4G? If you're doing "random" generation, it's hard to avoid some chance of collision. If the system can tolerate repeated writes to a piece of its mass storage (disk etc - "disk" for brevity), you could set up something with (say) a 32-bit value saved in a fixed place. Each boot, you read it, save the value somewhere for this boot, and write it back to disk incremented before doing anything else. The value saved is your boot ID. But this depends on having a small piece of disk you can afford to write to once per boot. It also demands custom kernel code, unless NetBSD wants to adopt something of the sort or it's acceptable to have duplicate boot IDs if a boot attempt crashes "too early". If the latter is acceptable (which, based on the fragments of the original post I saw quoted, sounds likely), you could even do it entirely in userland, immediately upon having a writable persistent filesystem available. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: kern.boottime drift after boot?
RVP wrote: > On Wed, 11 Oct 2023, Simon Burge wrote: > > > RVP wrote: > > > >> I think what David's looking for is something akin to Linux's > >> > >> /proc/sys/kernel/random/boot_id > >> > >> something which only changes on every boot but is otherwise stable. > > > > I'm curious how well this boot_id works on Linux for things like a > > embedded system (eg router) that boots from a ram disk and doesn't have > > an RTC. Essentially a similar problem to our long-running entropy > > discussion. > > On embedded systems without an RTC, you _could_ get the same UUID in rare > cases. But I think this would be a bug, because on Linux, any kind of jitter- > source (interrupt timing, for instance) would perturb the generated UUID. Hopefully! Even though this jitter might not be high entropy, it should (in theory) be enough to give a differnet UUID each boot. Assuming of course that the boot_id is generated after interrupts are enabled and some jitter has been processed :). Cheers, Simon.
Re: kern.boottime drift after boot?
On Wed, 11 Oct 2023, Simon Burge wrote: RVP wrote: I think what David's looking for is something akin to Linux's /proc/sys/kernel/random/boot_id something which only changes on every boot but is otherwise stable. I'm curious how well this boot_id works on Linux for things like a embedded system (eg router) that boots from a ram disk and doesn't have an RTC. Essentially a similar problem to our long-running entropy discussion. On embedded systems without an RTC, you _could_ get the same UUID in rare cases. But I think this would be a bug, because on Linux, any kind of jitter- source (interrupt timing, for instance) would perturb the generated UUID. -RVP
Re: kern.boottime drift after boot?
RVP wrote: > I think what David's looking for is something akin to Linux's > > /proc/sys/kernel/random/boot_id > > something which only changes on every boot but is otherwise stable. I'm curious how well this boot_id works on Linux for things like a embedded system (eg router) that boots from a ram disk and doesn't have an RTC. Essentially a similar problem to our long-running entropy discussion. Cheers, Simon.
Re: kern.boottime drift after boot?
On Tue, 10 Oct 2023, Brian Buhrow wrote: Does it always drift backward? And, it looks like it drifted by one second. Does it ever drift by more than one second? kern.boottime can go forwards too and by quite a bit. Go into the BIOS setup, then set the time back by 1 min. Boot into NetBSD and run ntpdate. kern.boottime should now jump forwards by a minute. I think what David's looking for is something akin to Linux's /proc/sys/kernel/random/boot_id something which only changes on every boot but is otherwise stable. -RVP
Re: kern.boottime drift after boot?
On Tue, 10 Oct 2023 at 18:07, Robert Elz wrote: > > Date:Tue, 10 Oct 2023 12:42:48 +0100 > From:David Brownlee > Message-ID: > > > | I have a system which records the output of "sysctl -n kern.boottime" > | as part of a dhcpcd-exit.hook to ensure some processing only occurs > | once per boot. > > Cron's @reboot might help with that, that's its purpose. See crontab(5) (More context) - It's used as a dhcpcd-exit.hook to ensure some services are enabled only after an interface has an IP address, so in this case cron @reboot would not fit. > | kern.boottime (KERN_BOOTTIME) > | A struct timespec structure is returned. This structure > contains > | the time that the system was booted. That time is defined > (for > | this purpose) to be the time at which the kernel first > started > | accumulating clock ticks. > > That's correct, the issue is that the kernel doesn't really know what the > time is, early in the boot sequence, it just takes a guess based either > upon the RTC if the system has one (those tend not to be very accurate), > or the last mod time of the root filesystem (much less accurate) otherwise. > > As Crystal said, as the system time is corrected, the kernel can form a > better idea of what the time actually was when the system booted, based upon > the corrections that are being made to the current time of day. > > kern.boottime always contains the time that the system believes it was > booted, as best it knows what that was. The man page section you qouted > above is correct, and doesn't need updating. The manpage is correct, but incomplete. On reading it without understanding the implementation, there is ambiguity as to whether kern.boottime will be constant for any given boot (unless I've missed something elsewhere in the page). Furthermore it has the unfortunate behaviour of 'usually' appearing to be constant, which leads to easy assumptions, based on lack of clarity. Particularly as it would be easy to have an implementation which did have a constant per boot value, which would be more useful in some ways and less in others (I'm not arguing at this point that we should switch to such an implementation) David
Re: kern.boottime drift after boot?
Date:Tue, 10 Oct 2023 12:42:48 +0100 From:David Brownlee Message-ID: | I have a system which records the output of "sysctl -n kern.boottime" | as part of a dhcpcd-exit.hook to ensure some processing only occurs | once per boot. Cron's @reboot might help with that, that's its purpose. See crontab(5) | kern.boottime (KERN_BOOTTIME) | A struct timespec structure is returned. This structure contains | the time that the system was booted. That time is defined (for | this purpose) to be the time at which the kernel first started | accumulating clock ticks. That's correct, the issue is that the kernel doesn't really know what the time is, early in the boot sequence, it just takes a guess based either upon the RTC if the system has one (those tend not to be very accurate), or the last mod time of the root filesystem (much less accurate) otherwise. As Crystal said, as the system time is corrected, the kernel can form a better idea of what the time actually was when the system booted, based upon the corrections that are being made to the current time of day. kern.boottime always contains the time that the system believes it was booted, as best it knows what that was. The man page section you qouted above is correct, and doesn't need updating. kre
Re: kern.boottime drift after boot?
Hello David. Does it always drift backward? And, it looks like it drifted by one second. Does it ever drift by more than one second? If not, then a work around in your script would be to assume that if boottime is less than 2 seconds from your stored time, then you haven't rebooted. -Brian
Re: kern.boottime drift after boot?
On Tue, Oct 10, 2023 at 12:42:48PM +0100, David Brownlee wrote: > I have a system which records the output of "sysctl -n kern.boottime" > as part of a dhcpcd-exit.hook to ensure some processing only occurs > once per boot. > > Except... it doesn't quite work as the value appears to not be > constant for a given boot. It's adjusted in step with the system clock, see settime1() in kern_time.c.
kern.boottime drift after boot?
I have a system which records the output of "sysctl -n kern.boottime" as part of a dhcpcd-exit.hook to ensure some processing only occurs once per boot. Except... it doesn't quite work as the value appears to not be constant for a given boot. I have one case where the value recorded by dhcpcd-exit.hook called during rc is 1696860044 but the value of sysctl -n kern.boottime is now 1696860043 sysctl(7) states: kern.boottime (KERN_BOOTTIME) A struct timespec structure is returned. This structure contains the time that the system was booted. That time is defined (for this purpose) to be the time at which the kernel first started accumulating clock ticks. I'm assuming it's calculated as some form of offset - maybe it would be better as an absolute value. If not, and it can drift about, then I'll at least update the manpage and look for a different mechanism for my 'once per boot' :) David
