<feed xmlns='http://www.w3.org/2005/Atom'>
<title>netbsd/sys/kern/kern_clock.c, branch trunk</title>
<subtitle>NetBSD fork for lockdoc analysis</subtitle>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/'/>
<entry>
<title>heartbeat(9): New mechanism to check progress of kernel.</title>
<updated>2023-07-07T12:34:49+00:00</updated>
<author>
<name>riastradh</name>
<email>riastradh@NetBSD.org</email>
</author>
<published>2023-07-07T12:34:49+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=de09df2fbee768e9082e19034d75860393b1d8c7'/>
<id>de09df2fbee768e9082e19034d75860393b1d8c7</id>
<content type='text'>
This uses hard interrupts to check progress of low-priority soft
interrupts, and one CPU to check progress of another CPU.

If no progress has been made after a configurable number of seconds
(kern.heartbeat.max_period, default 15), then the system panics --
preferably on the CPU that is stuck so we get a stack trace in dmesg
of where it was stuck, but if the stuckness was detected by another
CPU and the stuck CPU doesn't acknowledge the request to panic within
one second, the detecting CPU panics instead.

This doesn't supplant hardware watchdog timers.  It is possible for
hard interrupts to be stuck on all CPUs for some reason too; in that
case heartbeat(9) has no opportunity to complete.

Downside: heartbeat(9) relies on hardclock to run at a reasonably
consistent rate, which might cause trouble for the glorious tickless
future.  However, it could be adapted to take a parameter for an
approximate number of units that have elapsed since the last call on
the current CPU, rather than treating that as a constant 1.

XXX kernel revbump -- changes struct cpu_info layout</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This uses hard interrupts to check progress of low-priority soft
interrupts, and one CPU to check progress of another CPU.

If no progress has been made after a configurable number of seconds
(kern.heartbeat.max_period, default 15), then the system panics --
preferably on the CPU that is stuck so we get a stack trace in dmesg
of where it was stuck, but if the stuckness was detected by another
CPU and the stuck CPU doesn't acknowledge the request to panic within
one second, the detecting CPU panics instead.

This doesn't supplant hardware watchdog timers.  It is possible for
hard interrupts to be stuck on all CPUs for some reason too; in that
case heartbeat(9) has no opportunity to complete.

Downside: heartbeat(9) relies on hardclock to run at a reasonably
consistent rate, which might cause trouble for the glorious tickless
future.  However, it could be adapted to take a parameter for an
approximate number of units that have elapsed since the last call on
the current CPU, rather than treating that as a constant 1.

XXX kernel revbump -- changes struct cpu_info layout</pre>
</div>
</content>
</entry>
<entry>
<title>entropy(9): Reintroduce netbsd&lt;=9 time-delta estimator for unblocking.</title>
<updated>2023-06-30T21:42:05+00:00</updated>
<author>
<name>riastradh</name>
<email>riastradh@NetBSD.org</email>
</author>
<published>2023-06-30T21:42:05+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=a681d7f6b89654d0d44d03f5b49e1eab83f4019f'/>
<id>a681d7f6b89654d0d44d03f5b49e1eab83f4019f</id>
<content type='text'>
The system will (in a subsequent change) by default block for this
condition before almost all of userland is running (including
/etc/rc.d/sshd key generation).  That way, a never-blocking
getentropy(3) API will never return any data without at least
best-effort entropy like netbsd&lt;=9 did to applications except in
single-user mode (where you have to be careful about everything
anyway) or in the few processes that run before a seed can even be
loaded (where blocking indefinitely, e.g. when generating a stack
protector cookie in libc, could pose a severe availability problem
that can't be configured away, but where the security impact is low).

However, (in another subsequent change) we will continue to use
_only_ HWRNG driver estimates and seed estimates, and _not_
time-delta estimator, for _warning_ about security in motd, daily
security report, etc.  And if HWRNG/seed provides enough entropy
before time-delta estimator does, that will unblock /dev/random too.

The result is:

- Machines with HWRNG or seed won't warn about entropy and will
  essentially never block -- even on first boot without a seed, it
  will take only as long as the fastest HWRNG to unblock.

- Machines with neither HWRNG nor seed:
  . will warn about entropy, giving feedback about security;
    and
  . will avoid returning anything more predictable than netbsd&lt;=9;
    but
  . won't block (much) longer than netbsd&lt;=9 would (and won't block
    again after blocking once, except with kern.entropy.depletion=1 for
    testing).

  (The threshold for unblocking is now somewhat higher than before:
  512 samples that pass the time-delta estimator, rather than 80 as
  it used to be.)

  And, of course, adding a seed (or HWRNG) will prevent both warnings
  and blocking.

The mechanism is:

1. /dev/random will block until _either_

   (a) enough bits of entropy (256) from reliable sources have been
       added to the pool, _or_

   (b) enough samples have been added from any sources (512), passing
       the old time-delta entropy estimator, that the possible
       security benefit doesn't justify holding up availability any
       longer (`best effort'), except on systems with higher security
       requirements like securelevel=2 which can disable non-HWRNG,
       non-seed sources with rndctl_flags in rc.conf(5).

2. dmesg will report `entropy: ready' when 1(a) is satisfied, but if
   1(b) is satisfied first, it will report `entropy: best effort', so
   the concise log messages will reflect the timing and whether in
   any period of time any of the system might be relying on best
   effort entropy.

3. The sysctl knob kern.entropy.needed (and the ioctl RNDGETPOOLSTAT
   variable rndpoolstat_t::added) still reflects the number of bits
   of entropy from reliable sources, so we can still use this to
   suggest regenerating ssh keys.

   This matters on platforms that can only be reached, after flashing
   an installation image, by sshing in over a (private) network, like
   small network appliances or remote virtual machines without
   (interactive) serial consoles.  If we blocked indefinitely at boot
   when generating ssh keys, such platforms would be unusable.  This
   way, platforms are usable, but operators can still be advised at
   login time to regenerate keys as soon as they can actually load
   entropy onto the system, e.g. with rndctl(8) on a seed file copied
   from a local machine over the (private) network.

4. On machines without HWRNG, using a seed file still suppresses
   warnings for users who need more confident security.  But it is no
   longer necessary for availability.

This is a compromise between availability and security:

- The security mechanism of blocking indefinitely on machines without
  HWRNG hurts availability too much, as painful experience over the
  multiple years since I made the mistake of introducing it have
  shown.  (Sorry!)

- The other main alternative, not having a blocking path at all (as I
  pushed for, and as OpenBSD has done for a long time) could
  potentially reduce security vs netbsd&lt;=9, and would run against the
  expectations set by many popular operating systems to the severe
  detriment of public perception of NetBSD security.

Even though we can't _confidently_ assess enough entropy from, e.g.,
sampling interrupt timings, this is the traditional behaviour that
most operating systems provide -- and the result here is a net
nondecrease in security over netbsd&lt;=9, because all paths from the
entropy pool to userland now have at least as high a standard before
returning data as they did in netbsd&lt;=9.

PR kern/55641
PR pkg/55847
PR kern/57185
https://mail-index.netbsd.org/current-users/2020/09/02/msg039470.html
https://mail-index.netbsd.org/current-users/2020/11/21/msg039931.html
https://mail-index.netbsd.org/current-users/2020/12/05/msg040019.html

XXX pullup-10</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The system will (in a subsequent change) by default block for this
condition before almost all of userland is running (including
/etc/rc.d/sshd key generation).  That way, a never-blocking
getentropy(3) API will never return any data without at least
best-effort entropy like netbsd&lt;=9 did to applications except in
single-user mode (where you have to be careful about everything
anyway) or in the few processes that run before a seed can even be
loaded (where blocking indefinitely, e.g. when generating a stack
protector cookie in libc, could pose a severe availability problem
that can't be configured away, but where the security impact is low).

However, (in another subsequent change) we will continue to use
_only_ HWRNG driver estimates and seed estimates, and _not_
time-delta estimator, for _warning_ about security in motd, daily
security report, etc.  And if HWRNG/seed provides enough entropy
before time-delta estimator does, that will unblock /dev/random too.

The result is:

- Machines with HWRNG or seed won't warn about entropy and will
  essentially never block -- even on first boot without a seed, it
  will take only as long as the fastest HWRNG to unblock.

- Machines with neither HWRNG nor seed:
  . will warn about entropy, giving feedback about security;
    and
  . will avoid returning anything more predictable than netbsd&lt;=9;
    but
  . won't block (much) longer than netbsd&lt;=9 would (and won't block
    again after blocking once, except with kern.entropy.depletion=1 for
    testing).

  (The threshold for unblocking is now somewhat higher than before:
  512 samples that pass the time-delta estimator, rather than 80 as
  it used to be.)

  And, of course, adding a seed (or HWRNG) will prevent both warnings
  and blocking.

The mechanism is:

1. /dev/random will block until _either_

   (a) enough bits of entropy (256) from reliable sources have been
       added to the pool, _or_

   (b) enough samples have been added from any sources (512), passing
       the old time-delta entropy estimator, that the possible
       security benefit doesn't justify holding up availability any
       longer (`best effort'), except on systems with higher security
       requirements like securelevel=2 which can disable non-HWRNG,
       non-seed sources with rndctl_flags in rc.conf(5).

2. dmesg will report `entropy: ready' when 1(a) is satisfied, but if
   1(b) is satisfied first, it will report `entropy: best effort', so
   the concise log messages will reflect the timing and whether in
   any period of time any of the system might be relying on best
   effort entropy.

3. The sysctl knob kern.entropy.needed (and the ioctl RNDGETPOOLSTAT
   variable rndpoolstat_t::added) still reflects the number of bits
   of entropy from reliable sources, so we can still use this to
   suggest regenerating ssh keys.

   This matters on platforms that can only be reached, after flashing
   an installation image, by sshing in over a (private) network, like
   small network appliances or remote virtual machines without
   (interactive) serial consoles.  If we blocked indefinitely at boot
   when generating ssh keys, such platforms would be unusable.  This
   way, platforms are usable, but operators can still be advised at
   login time to regenerate keys as soon as they can actually load
   entropy onto the system, e.g. with rndctl(8) on a seed file copied
   from a local machine over the (private) network.

4. On machines without HWRNG, using a seed file still suppresses
   warnings for users who need more confident security.  But it is no
   longer necessary for availability.

This is a compromise between availability and security:

- The security mechanism of blocking indefinitely on machines without
  HWRNG hurts availability too much, as painful experience over the
  multiple years since I made the mistake of introducing it have
  shown.  (Sorry!)

- The other main alternative, not having a blocking path at all (as I
  pushed for, and as OpenBSD has done for a long time) could
  potentially reduce security vs netbsd&lt;=9, and would run against the
  expectations set by many popular operating systems to the severe
  detriment of public perception of NetBSD security.

Even though we can't _confidently_ assess enough entropy from, e.g.,
sampling interrupt timings, this is the traditional behaviour that
most operating systems provide -- and the result here is a net
nondecrease in security over netbsd&lt;=9, because all paths from the
entropy pool to userland now have at least as high a standard before
returning data as they did in netbsd&lt;=9.

PR kern/55641
PR pkg/55847
PR kern/57185
https://mail-index.netbsd.org/current-users/2020/09/02/msg039470.html
https://mail-index.netbsd.org/current-users/2020/11/21/msg039931.html
https://mail-index.netbsd.org/current-users/2020/12/05/msg040019.html

XXX pullup-10</pre>
</div>
</content>
</entry>
<entry>
<title>kern: Delete kernel_ticks from kernel ABI.</title>
<updated>2022-03-19T14:34:47+00:00</updated>
<author>
<name>riastradh</name>
<email>riastradh@NetBSD.org</email>
</author>
<published>2022-03-19T14:34:47+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=5918cbf7dee3991176d00f09cd204bfc4a571f5f'/>
<id>5918cbf7dee3991176d00f09cd204bfc4a571f5f</id>
<content type='text'>
Use getticks() instead.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use getticks() instead.</pre>
</div>
</content>
</entry>
<entry>
<title>clockrnd(9): Use atomic_load_relaxed for struct clockrnd::needed.</title>
<updated>2022-03-18T23:37:14+00:00</updated>
<author>
<name>riastradh</name>
<email>riastradh@NetBSD.org</email>
</author>
<published>2022-03-18T23:37:14+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=d72b00c4429289b7d978a82a5f275a8579359422'/>
<id>d72b00c4429289b7d978a82a5f275a8579359422</id>
<content type='text'>
This may be set concurrently by clockrnd_get, so let's match the
atomic_store_relaxed and avoid the appearance of data races.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This may be set concurrently by clockrnd_get, so let's match the
atomic_store_relaxed and avoid the appearance of data races.</pre>
</div>
</content>
</entry>
<entry>
<title>fix rumpkernel build failure</title>
<updated>2021-08-14T21:17:11+00:00</updated>
<author>
<name>ryo</name>
<email>ryo@NetBSD.org</email>
</author>
<published>2021-08-14T21:17:11+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=60b8ef8d4d9bda37e781887ebe77435dd22ca9f1'/>
<id>60b8ef8d4d9bda37e781887ebe77435dd22ca9f1</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Improved the performance of kernel profiling on MULTIPROCESSOR, and possible to get profiling data for each CPU.</title>
<updated>2021-08-14T17:51:18+00:00</updated>
<author>
<name>ryo</name>
<email>ryo@NetBSD.org</email>
</author>
<published>2021-08-14T17:51:18+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=bc2926d3a87174cce38dd44a3fb55628f6ccb377'/>
<id>bc2926d3a87174cce38dd44a3fb55628f6ccb377</id>
<content type='text'>
In the current implementation, locks are acquired at the entrance of the mcount
internal function, so the higher the number of cores, the more lock conflict
occurs, making profiling performance in a MULTIPROCESSOR environment unusable
and slow. Profiling buffers has been changed to be reserved for each CPU,
improving profiling performance in MP by several to several dozen times.

- Eliminated cpu_simple_lock in mcount internal function, using per-CPU buffers.
- Add ci_gmon member to struct cpu_info of each MP arch.
- Add kern.profiling.percpu node in sysctl tree.
- Add new -c &lt;cpuid&gt; option to kgmon(8) to specify the cpuid, like openbsd.
  For compatibility, if the -c option is not specified, the entire system can be
  operated as before, and the -p option will get the total profiling data for
  all CPUs.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In the current implementation, locks are acquired at the entrance of the mcount
internal function, so the higher the number of cores, the more lock conflict
occurs, making profiling performance in a MULTIPROCESSOR environment unusable
and slow. Profiling buffers has been changed to be reserved for each CPU,
improving profiling performance in MP by several to several dozen times.

- Eliminated cpu_simple_lock in mcount internal function, using per-CPU buffers.
- Add ci_gmon member to struct cpu_info of each MP arch.
- Add kern.profiling.percpu node in sysctl tree.
- Add new -c &lt;cpuid&gt; option to kgmon(8) to specify the cpuid, like openbsd.
  For compatibility, if the -c option is not specified, the entire system can be
  operated as before, and the -p option will get the total profiling data for
  all CPUs.</pre>
</div>
</content>
</entry>
<entry>
<title>entropy: Sample cycle counter or timecounter in hardclock.</title>
<updated>2021-01-16T02:20:00+00:00</updated>
<author>
<name>riastradh</name>
<email>riastradh@NetBSD.org</email>
</author>
<published>2021-01-16T02:20:00+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=e5b3e745fb9175d75b383564c7742420c097d958'/>
<id>e5b3e745fb9175d75b383564c7742420c097d958</id>
<content type='text'>
Only do so when we're short on entropy, in order to minimize
performance impact.

The sampling should stay close to the time of the actual hardclock
timer interrupt, so that the oscillator driving it determines when we
sample the cycle counter or timecounter, which we hope is driven by
an independent oscillator.

If we used a callout, there might be many other influences -- such as
spin lock delays possibly synchronized with this core's cycle counter
-- that could get between the timer interrupt and the sample.

In the glorious tickless future, this should instead be wired up to
the timer interrupt handler, however that manifests in the future
tickless API.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Only do so when we're short on entropy, in order to minimize
performance impact.

The sampling should stay close to the time of the actual hardclock
timer interrupt, so that the oscillator driving it determines when we
sample the cycle counter or timecounter, which we hope is driven by
an independent oscillator.

If we used a callout, there might be many other influences -- such as
spin lock delays possibly synchronized with this core's cycle counter
-- that could get between the timer interrupt and the sample.

In the glorious tickless future, this should instead be wired up to
the timer interrupt handler, however that manifests in the future
tickless API.</pre>
</div>
</content>
</entry>
<entry>
<title>Refactor interval timers to make it possible to support types other than</title>
<updated>2020-12-05T18:17:01+00:00</updated>
<author>
<name>thorpej</name>
<email>thorpej@NetBSD.org</email>
</author>
<published>2020-12-05T18:17:01+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=6c0365dbd5736db555ff5be7b31aabf7711a8102'/>
<id>6c0365dbd5736db555ff5be7b31aabf7711a8102</id>
<content type='text'>
the BSD/POSIX per-process timers:

- "struct ptimer" is split into "struct itimer" (common interval timer
  data) and "struct ptimer" (per-process timer data, which contains a
  "struct itimer").

- Introduce a new "struct itimer_ops" that supplies information about
  the specific kind of interval timer, including it's processing
  queue, the softint handle used to schedule processing, the function
  to call when the timer fires (which adds it to the queue), and an
  optional function to call when the CLOCK_REALTIME clock is changed by
  a call to clock_settime() or settimeofday().

- Rename some fuctions to clearly identify what they're operating on
  (ptimer vs itimer).

- Use kmem(9) to allocate ptimer-related structures, rather than having
  dedicated pools for them.

Welcome to NetBSD 9.99.77.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
the BSD/POSIX per-process timers:

- "struct ptimer" is split into "struct itimer" (common interval timer
  data) and "struct ptimer" (per-process timer data, which contains a
  "struct itimer").

- Introduce a new "struct itimer_ops" that supplies information about
  the specific kind of interval timer, including it's processing
  queue, the softint handle used to schedule processing, the function
  to call when the timer fires (which adds it to the queue), and an
  optional function to call when the CLOCK_REALTIME clock is changed by
  a call to clock_settime() or settimeofday().

- Rename some fuctions to clearly identify what they're operating on
  (ptimer vs itimer).

- Use kmem(9) to allocate ptimer-related structures, rather than having
  dedicated pools for them.

Welcome to NetBSD 9.99.77.</pre>
</div>
</content>
</entry>
<entry>
<title>Call cpu_initclocks() before registering the default timecounter,</title>
<updated>2020-10-11T18:39:09+00:00</updated>
<author>
<name>thorpej</name>
<email>thorpej@NetBSD.org</email>
</author>
<published>2020-10-11T18:39:09+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=c05ce3824d4b33997746f6e0c0642520fc177136'/>
<id>c05ce3824d4b33997746f6e0c0642520fc177136</id>
<content type='text'>
in case it updates hz.  If hz changes, recalculate tick and tickadj.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
in case it updates hz.  If hz changes, recalculate tick and tickadj.</pre>
</div>
</content>
</entry>
<entry>
<title>Run Solaris cyclics from statclock() so dtrace isn't locked out by IPL_SCHED</title>
<updated>2020-05-08T22:10:08+00:00</updated>
<author>
<name>ad</name>
<email>ad@NetBSD.org</email>
</author>
<published>2020-05-08T22:10:08+00:00</published>
<link rel='alternate' type='text/html' href='http://git.infra.scholz.ruhr/netbsd/commit/?id=3dc375ea5363ec27edd7c7ad38139356a800450b'/>
<id>3dc375ea5363ec27edd7c7ad38139356a800450b</id>
<content type='text'>
(assuming the machine has a separate statclock() which almost all don't).</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
(assuming the machine has a separate statclock() which almost all don't).</pre>
</div>
</content>
</entry>
</feed>
