Automated report: NetBSD-current/i386 build success

[NetBSD Test Fixture]

The NetBSD-current/i386 build is working again.

The following commits were made between the last failed build and the
successful build:

2021.04.07.03.45.18 christos src/distrib/sets/lists/base/shl.mi,v 1.916
2021.04.07.03.45.18 christos src/distrib/sets/lists/debug/shl.mi,v 1.273

Logs can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2021.04.html#2021.04.07.03.45.18

Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?

[John Nemeth]

On Apr 6, 13:05, jdba...@consolidated.net wrote:
}
} After updating my mail hub to the latest NetBSD/sparc-9.1_STABLE
} including the OpenSSL update and the fix to silence the "coprocessor
} instruction" console SPAM, I find that my sendmail (mail/sendmail
} v8.15.2nb9) is no-longer relaying mail out of my system.
} 
} It accepts mail from my internal hosts (set up as mostly-null clients)
} and queues it in "/var/spool/mqueue" but never attempts to contact my
} configured SMART_HOST.  There's nothing in any log files that indicates
} any problem, it just doesn't follow through on relaying outbound mail.
} Attempting to forcibly flush the queue with 'sudo sendmail -q' has no
} effect.

 What happens if you do 'sudo sendmail -odi -q -v'.  Also are
you using host status?

}-- End of excerpt from jdba...@consolidated.net

Automated report: NetBSD-current/i386 build failure

[NetBSD Test Fixture]

This is an automatically generated notice of a NetBSD-current/i386
build failure.

The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2021.04.07.02.43.15.

An extract from the build.sh output follows:

--- event.po ---
/tmp/build/2021.04.07.02.43.15-i386/tools/bin/nbctfconvert -g -L VERSION -o 
event.po event.po.o && rm -f event.po.o
/tmp/build/2021.04.07.02.43.15-i386/tools/bin/i486--netbsdelf-objcopy -X  
event.po
6 errors
nbmake[8]: stopped in 
/tmp/build/2021.04.07.02.43.15-i386/src/external/bsd/libevent/lib/libevent
nbmake[7]: stopped in 
/tmp/build/2021.04.07.02.43.15-i386/src/external/bsd/libevent/lib/libevent
nbmake[6]: stopped in 
/tmp/build/2021.04.07.02.43.15-i386/src/external/bsd/libevent/lib
*** Failed target:  dependall-../external/bsd/libevent/lib
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1"; shift; 
case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this="lib/"; 
real="/tmp/build/2021.04.07.02.43.15-i386/src/lib" ;; *) this="lib/${dir}/"; 
real="/tmp/build/2021.04.07.02.43.15-i386/src/lib/${dir}" ;; esac; 
show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd "${real}" 
&& /tmp/build/2021.04.07.02.43.15-i386/tools/bin/nbmake _THISDIR_="${this}" 
"$@" ${target}; }; _makedirtarget ../external/bsd/libevent/lib dependall
*** Error code 2
Stop.
nbmake[5]: stopped in /tmp/build/2021.04.07.02.43.15-i386/src/lib
*** [build_install] Error code 1
nbmake[4]: stopped in /tmp/build/2021.04.07.02.43.15-i386/src/lib
1 error
nbmake[4]: stopped in /tmp/build/2021.04.07.02.43.15-i386/src/lib
nbmake[3]: stopped in /tmp/build/2021.04.07.02.43.15-i386/src
nbmake[2]: stopped in /tmp/build/2021.04.07.02.43.15-i386/src
nbmake[1]: stopped in /tmp/build/2021.04.07.02.43.15-i386/src
nbmake: stopped in /tmp/build/2021.04.07.02.43.15-i386/src
ERROR: Failed to make release

The following commits were made between the last successful build and
the failed build:

2021.04.07.02.43.12 christos 
src/external/bsd/libevent/dist/epolltable-internal.h,v 1.1.1.2
2021.04.07.02.43.12 christos 
src/external/bsd/libevent/dist/event-config.h.cmake,v 1.1.1.1
2021.04.07.02.43.12 christos 
src/external/bsd/libevent/dist/http-internal.h,v 1.1.1.4
2021.04.07.02.43.12 christos 
src/external/bsd/libevent/dist/iocp-internal.h,v 1.1.1.3
2021.04.07.02.43.12 christos src/external/bsd/libevent/dist/mm-internal.h,v 
1.1.1.3
2021.04.07.02.43.13 christos 
src/external/bsd/libevent/dist/CMakeLists.txt,v 1.1.1.1
2021.04.07.02.43.13 christos src/external/bsd/libevent/dist/ChangeLog-1.4,v 
1.1.1.2
2021.04.07.02.43.13 christos src/external/bsd/libevent/dist/ChangeLog-2.0,v 
1.1.1.2
2021.04.07.02.43.13 christos src/external/bsd/libevent/dist/Makefile.am,v 
1.1.1.4
2021.04.07.02.43.13 christos src/external/bsd/libevent/dist/aclocal.m4,v 
1.1.1.4
2021.04.07.02.43.13 christos src/external/bsd/libevent/dist/buffer_iocp.c,v 
1.1.1.3
2021.04.07.02.43.13 christos 
src/external/bsd/libevent/dist/bufferevent_async.c,v 1.1.1.3
2021.04.07.02.43.13 christos 
src/external/bsd/libevent/dist/bufferevent_filter.c,v 1.1.1.3
2021.04.07.02.43.13 christos 
src/external/bsd/libevent/dist/bufferevent_pair.c,v 1.1.1.4
2021.04.07.02.43.13 christos 
src/external/bsd/libevent/dist/bufferevent_sock.c,v 1.1.1.4
2021.04.07.02.43.13 christos src/external/bsd/libevent/dist/config.h.in,v 
1.1.1.4
2021.04.07.02.43.13 christos src/external/bsd/libevent/dist/configure,v 
1.1.1.4
2021.04.07.02.43.13 christos src/external/bsd/libevent/dist/configure.ac,v 
1.1.1.3
2021.04.07.02.43.13 christos src/external/bsd/libevent/dist/doxygen.am,v 
1.1.1.1
2021.04.07.02.43.13 christos 
src/external/bsd/libevent/dist/evconfig-private.h.cmake,v 1.1.1.1
2021.04.07.02.43.13 christos 
src/external/bsd/libevent/dist/evconfig-private.h.in,v 1.1.1.2
2021.04.07.02.43.13 christos 
src/external/bsd/libevent/dist/event_rpcgen.py,v 1.1.1.3
2021.04.07.02.43.13 christos src/external/bsd/libevent/dist/evutil_time.c,v 
1.1.1.2
2021.04.07.02.43.13 christos src/external/bsd/libevent/dist/listener.c,v 
1.1.1.4
2021.04.07.02.43.13 christos 
src/external/bsd/libevent/dist/make-event-config.sed,v 1.1.1.3
2021.04.07.02.43.13 christos src/external/bsd/libevent/dist/poll.c,v 1.1.1.4
2021.04.07.02.43.13 christos src/external/bsd/libevent/dist/signal.c,v 
1.1.1.4
2021.04.07.02.43.13 christos 
src/external/bsd/libevent/dist/time-internal.h,v 1.1.1.2
2021.04.07.02.43.14 christos src/external/bsd/libevent/dist/ChangeLog,v 
1.1.1.5
2021.04.07.02.43.14 christos src/external/bsd/libevent/dist/Makefile.in,v 
1.1.1.4
2021.04.07.02.43.14 christos src/external/bsd/libevent/dist/README.md,v 
1.1.1.1
2021.04.07.02.43.14 christos src/external/bsd/libevent/dist/arc4random.c,v 
1.1.1.4
2021.04.07.02.43.14 christos 

daily CVS update output

[NetBSD source update]

Updating src tree:
P src/bin/ps/Makefile
P src/bin/ps/print.c
P src/external/bsd/elftoolchain/Makefile
U src/external/bsd/elftoolchain/common/Makefile
U src/external/bsd/elftoolchain/common/sys/Makefile
P src/external/bsd/elftoolchain/dist/common/Makefile
U src/external/bsd/elftoolchain/dist/common/sys/Makefile
U src/external/bsd/elftoolchain/dist/common/sys/elfconstants.m4
U src/external/bsd/elftoolchain/dist/common/sys/elfdefinitions.m4
U src/external/bsd/libevent/dist/CMakeLists.txt
P src/external/bsd/libevent/dist/ChangeLog
P src/external/bsd/libevent/dist/ChangeLog-1.4
P src/external/bsd/libevent/dist/ChangeLog-2.0
P src/external/bsd/libevent/dist/Makefile.am
P src/external/bsd/libevent/dist/Makefile.in
U src/external/bsd/libevent/dist/README.md
P src/external/bsd/libevent/dist/aclocal.m4
P src/external/bsd/libevent/dist/arc4random.c
P src/external/bsd/libevent/dist/buffer_iocp.c
P src/external/bsd/libevent/dist/bufferevent_async.c
P src/external/bsd/libevent/dist/bufferevent_filter.c
P src/external/bsd/libevent/dist/bufferevent_openssl.c
P src/external/bsd/libevent/dist/bufferevent_pair.c
P src/external/bsd/libevent/dist/bufferevent_sock.c
P src/external/bsd/libevent/dist/config.h.in
P src/external/bsd/libevent/dist/configure
P src/external/bsd/libevent/dist/configure.ac
P src/external/bsd/libevent/dist/defer-internal.h
U src/external/bsd/libevent/dist/doxygen.am
P src/external/bsd/libevent/dist/epoll.c
P src/external/bsd/libevent/dist/epolltable-internal.h
U src/external/bsd/libevent/dist/evconfig-private.h.cmake
P src/external/bsd/libevent/dist/evconfig-private.h.in
U src/external/bsd/libevent/dist/event-config.h.cmake
P src/external/bsd/libevent/dist/event_iocp.c
P src/external/bsd/libevent/dist/event_rpcgen.py
P src/external/bsd/libevent/dist/evutil_time.c
P src/external/bsd/libevent/dist/http-internal.h
P src/external/bsd/libevent/dist/iocp-internal.h
P src/external/bsd/libevent/dist/listener.c
P src/external/bsd/libevent/dist/make-event-config.sed
P src/external/bsd/libevent/dist/mm-internal.h
P src/external/bsd/libevent/dist/openssl-compat.h
P src/external/bsd/libevent/dist/poll.c
P src/external/bsd/libevent/dist/signal.c
P src/external/bsd/libevent/dist/strlcpy-internal.h
P src/external/bsd/libevent/dist/time-internal.h
P src/external/bsd/libevent/dist/win32select.c
U src/external/bsd/libevent/dist/WIN32-Code/getopt.c
U src/external/bsd/libevent/dist/WIN32-Code/getopt.h
U src/external/bsd/libevent/dist/WIN32-Code/getopt_long.c
P src/external/bsd/libevent/dist/WIN32-Code/nmake/event2/event-config.h
U src/external/bsd/libevent/dist/build-aux/compile
U src/external/bsd/libevent/dist/build-aux/config.guess
U src/external/bsd/libevent/dist/build-aux/config.sub
U src/external/bsd/libevent/dist/build-aux/depcomp
U src/external/bsd/libevent/dist/build-aux/install-sh
U src/external/bsd/libevent/dist/build-aux/ltmain.sh
U src/external/bsd/libevent/dist/build-aux/missing
U src/external/bsd/libevent/dist/build-aux/test-driver
U src/external/bsd/libevent/dist/cmake/AddCompilerFlags.cmake
U src/external/bsd/libevent/dist/cmake/AddEventLibrary.cmake
U src/external/bsd/libevent/dist/cmake/COPYING-CMAKE-SCRIPTS
U src/external/bsd/libevent/dist/cmake/CheckConstExists.cmake
U src/external/bsd/libevent/dist/cmake/CheckFileOffsetBits.c
U src/external/bsd/libevent/dist/cmake/CheckFileOffsetBits.cmake
U src/external/bsd/libevent/dist/cmake/CheckFunctionKeywords.cmake
U src/external/bsd/libevent/dist/cmake/CheckPrototypeDefinition.c.in
U src/external/bsd/libevent/dist/cmake/CheckPrototypeDefinition.cmake
U src/external/bsd/libevent/dist/cmake/CheckWorkingKqueue.cmake
U src/external/bsd/libevent/dist/cmake/CodeCoverage.cmake
U src/external/bsd/libevent/dist/cmake/Copyright.txt
U src/external/bsd/libevent/dist/cmake/LibeventConfig.cmake.in
U src/external/bsd/libevent/dist/cmake/LibeventConfigVersion.cmake.in
U src/external/bsd/libevent/dist/cmake/Macros.cmake
U src/external/bsd/libevent/dist/cmake/Uninstall.cmake.in
U src/external/bsd/libevent/dist/cmake/UseDoxygen.cmake
U src/external/bsd/libevent/dist/cmake/VersionViaGit.cmake
P src/external/bsd/libevent/dist/include/include.am
P src/external/bsd/libevent/dist/include/event2/buffer.h
P src/external/bsd/libevent/dist/include/event2/buffer_compat.h
P src/external/bsd/libevent/dist/include/event2/bufferevent.h
P src/external/bsd/libevent/dist/include/event2/bufferevent_compat.h
P src/external/bsd/libevent/dist/include/event2/dns.h
P src/external/bsd/libevent/dist/include/event2/dns_compat.h
P src/external/bsd/libevent/dist/include/event2/event.h
P src/external/bsd/libevent/dist/include/event2/http.h
P src/external/bsd/libevent/dist/include/event2/http_compat.h
P src/external/bsd/libevent/dist/include/event2/listener.h
P src/external/bsd/libevent/dist/include/event2/rpc_struct.h
P src/external/bsd/libevent/dist/include/event2/visibility.h
U src/external/bsd/libevent/dist/m4/ax_check_funcs_ex.m4
U src/external/bsd/libevent/dist/m4/ax_prog_doxygen.m4
P 

Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?

[jdbaker]

I've had a couple of responses to this with some questions about
my setup.

When last working, the system was running NetBSD/sparc-9.1_STABLE from
about:

  Thu Mar 11 11:44:19 CST 2021 9.1_STABLE

With all packages built from pkgsrc-2020Q4.

There was a hiccup around mid-March when my ISP up-degraded their mail
system without notice and changed the SMTP-AUTH mechanism, so I had to
probe it to find out what was now being accepted.  I added the
appropriate cy2- plugin and mail was again being sent.

I don't know if it was simply coincidental or not, but only after
updating with a netbsd-9 after the OpenSSL pull-up did mail stop
being relayed.  The libcrypto and libssl versions didn't change with
the update/pull-up.

I've now looked at things with 'tcpdump -i  port submission'
and now I see 'sendmail' talking to a machine that is NOT my ISP's
customer-facing outbound MTA--albeit a machine in the same domain as
that which responds when the actual MTA is contacted.  It seems to try
to send stuff--as the files in "/var/spool/mqueue" increase, there's 
more

'tcpdump' output when I run 'sendmail -q', but the mail remains queued
and not sent. No additional messages appear in "/var/log/maillog".

Trying to specify the "SMART_HOST" by IP address doesn't work--it still
contacts the same wrong machine.  Trying to manually probe the wrong
host with 'telnet foo submission' or
'openssl s_client -connect foo:submission' times out.

And I just did a series of DNS queries and there may be something weird
going on.  Forward query for the ISP's MTA returns an IP address, but 
the

reverse query ('dig -x ip-addr') returns the name of the "wrong" machine
and forward query of the "wrong" machine yields a different IP address.

So, what I was seeing in the logs was sendmail talking to the correct
machine, but 'tcpdump' resolving the name to the wrong host and my 
probes

of the wrong host would naturally fail.

My build has finished so I'll update again and see what happens.

--
|/"\ John D. Baker, KN5UKS   NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net  OpenBSDFreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

Re: regarding the changes to kernel entropy gathering

[RVP]

On Tue, 6 Apr 2021, Taylor R Campbell wrote:


Why do you say that?  We do incorporate many sources that are not
well-studied -- every keystroke, for example, and the CPU cycle
counter at the time of the keystroke, affects the output of
/dev/urandom.



Is the output of /dev/random also influenced like this?


What do you mean by `things like timing jitter have been pooh-poohed
in the literature'?  Timing jitter in ring oscillators arising from
thermal noise in the silicon is the main source of entropy in most
on-die hardware RNGs on the market that I'm aware of.  This design is
reasonably well-studied in the literature.



I should've been more precise :(. Back in the beginning of the year
when a related discussion re: initial seeding on devices w/o usable
audio devices got stuck, I said that when all else fails the user
can be asked to mash on the keyboard and jiggle the mouse. To which
nia@ responded that those old-fashioned methods weren't considered
good enough nowadays, and linked to a paper which discussed this.

I had in mind that (and similar stuff) when I wrote what I did--not
well-studied physical processes like jitter derived from comparing
a pair of free-running oscillators.

-RVP

Automated report: NetBSD-current/i386 build success

[NetBSD Test Fixture]

The NetBSD-current/i386 build is working again.

The following commits were made between the last failed build and the
successful build:

2021.04.06.21.10.37 rillig src/tests/usr.bin/xlint/lint1/msg_132.c,v 1.4
2021.04.06.21.10.37 rillig src/tests/usr.bin/xlint/lint1/msg_132.exp,v 1.3
2021.04.06.21.13.04 jkoshy src/lib/Makefile,v 1.289
2021.04.06.21.17.27 rillig src/usr.bin/xlint/lint1/tree.c,v 1.268
2021.04.06.21.17.28 rillig src/tests/usr.bin/xlint/lint1/msg_132.c,v 1.5
2021.04.06.21.17.28 rillig src/tests/usr.bin/xlint/lint1/msg_132.exp,v 1.4

Logs can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2021.04.html#2021.04.06.21.17.28

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

At Tue, 6 Apr 2021 20:21:43 +0200, Martin Husemann  wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> On Tue, Apr 06, 2021 at 10:54:51AM -0700, Greg A. Woods wrote:
> >
> > And the stock implementation has no possibility of ever providing an
> > initial seed at all on its own (unlike previous implementations, and of
> > course unlike what my patch _affords_).
>
> Isn't it as simple as:
>
>   dd bs=32 if=/dev/urandom of=/dev/random

No, that still leaves the question of _when_ to run it.  (And, at least
at the moment, where to put it.  /etc/rc.local?)

Isn't something the following better (assuming you choose your devices
carefully):

echo 'rndctl_flags="-t env;-t disk;-t tty"' >> /etc/rc.conf

That's what my patches fix and allow, and this way you don't have to
guess when you can safely use /dev/urandom as an entropy seed -- the
seeding happens in real time, and only as entropy bits are made
available from those given devices.

That can also be done by sysinst, assuming a reasonably well worded
question can be answered, and that it might only need to be asked if
there are no "rng" type devices already.

Doing this also requires no network access (ever).

It can even be done, ahead of time, for use on immutable systems.

--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgparJTWSICYJ.pgp
Description: OpenPGP Digital Signature

Re: Automated report: NetBSD-current/i386 build failure

[jkoshy]

> This is an automatically generated notice of a NetBSD-current/i386
> build failure.
> 
> The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
> using sources from CVS date 2021.04.06.20.13.43.
...
> *** Failed target:  dependall-../external/bsd/elftoolchain
...
> The following commits were made between the last successful build and
> the failed build:
> 
> 2021.04.06.19.44.24 jkoshy src/external/bsd/elftoolchain/Makefile,v 1.2
> 2021.04.06.20.13.43 jkoshy src/lib/Makefile,v 1.288

Revision 1.288 of src/lib/Makefile seems the culprit, and has been
reverted.

Apologies for the noise.

Regards,
Joseph Koshy

mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?

[jdbaker]

Pardon the poor or utter lack of formatting, I'm having to use
my ISP's webmail system to send this, due to the problem in the
Subject: line.

After updating my mail hub to the latest NetBSD/sparc-9.1_STABLE
including the OpenSSL update and the fix to silence the "coprocessor
instruction" console SPAM, I find that my sendmail (mail/sendmail
v8.15.2nb9) is no-longer relaying mail out of my system.

It accepts mail from my internal hosts (set up as mostly-null clients)
and queues it in "/var/spool/mqueue" but never attempts to contact my
configured SMART_HOST.  There's nothing in any log files that indicates
any problem, it just doesn't follow through on relaying outbound mail.
Attempting to forcibly flush the queue with 'sudo sendmail -q' has no
effect.

The only relevant change between working and not working was the update
of OpenSSL pulled up to netbsd-9.  I'm using packages from pkgsrc
immediately prior to the roll-back of glib2 from 2.68 to 2.66 (just as
a reference of the state of packages).  There were no changes to
"mail/sendmail", "security/cyrus-sasl", or "security/cy2-{login,plain}".

I've cloned my netbsd-9 tree and rolled back the OpenSSL update (only,
prior to 27-Mar-2021 14.35 UTC) and am building the distribution and
sets.  Once I update the mail hub from that, I'll see if sendmail will
go ahead and relay.

Anyone else using "mail/sendmail" and seeing anything similar?  (Since
my ISP's customer-facing outbound MTA requires authentication,
"security/cyrus-sasl" and an appropriate authentication plugin are also
used.)

--
|/"\ John D. Baker, KN5UKS   NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net  OpenBSDFreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

Re: regarding the changes to kernel entropy gathering

[Koning, Paul]

> On Apr 6, 2021, at 2:21 PM, Martin Husemann  wrote:
> 
> 
> [EXTERNAL EMAIL] 
> 
> On Tue, Apr 06, 2021 at 10:54:51AM -0700, Greg A. Woods wrote:
>> Except it seems to be useless in practice without an initial seed,
> 
> Yes.
> 
>> And the stock implementation has no possibility of ever providing an
>> initial seed at all on its own (unlike previous implementations, and of
>> course unlike what my patch _affords_).
> 
> Isn't it as simple as:
> 
>   dd bs=32 if=/dev/urandom of=/dev/random
> 
> ?

That runs the risk of people thinking it adds entropy.  I'd be more comfortable 
with this:

dd bs=32 if=/dev/zero of=/dev/random

because it makes the security implications more obvious.

paul

Automated report: NetBSD-current/i386 build failure

[NetBSD Test Fixture]

This is an automatically generated notice of a NetBSD-current/i386
build failure.

The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2021.04.06.20.13.43.

An extract from the build.sh output follows:

ln -sf libelf.so.2.0 libelf.so.tmp
mv -f libelf.so.tmp libelf.so
nbmake[8]: stopped in 
/tmp/build/2021.04.06.20.13.43-i386/src/external/bsd/elftoolchain/lib/libelf
nbmake[7]: stopped in 
/tmp/build/2021.04.06.20.13.43-i386/src/external/bsd/elftoolchain/lib
nbmake[6]: stopped in 
/tmp/build/2021.04.06.20.13.43-i386/src/external/bsd/elftoolchain
*** Failed target:  dependall-../external/bsd/elftoolchain
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1"; shift; 
case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this="lib/"; 
real="/tmp/build/2021.04.06.20.13.43-i386/src/lib" ;; *) this="lib/${dir}/"; 
real="/tmp/build/2021.04.06.20.13.43-i386/src/lib/${dir}" ;; esac; 
show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd "${real}" 
&& /tmp/build/2021.04.06.20.13.43-i386/tools/bin/nbmake _THISDIR_="${this}" 
"$@" ${target}; }; _makedirtarget ../external/bsd/elftoolchain dependall
*** Error code 2
Stop.
nbmake[5]: stopped in /tmp/build/2021.04.06.20.13.43-i386/src/lib
*** [build_install] Error code 1
nbmake[4]: stopped in /tmp/build/2021.04.06.20.13.43-i386/src/lib
1 error
nbmake[4]: stopped in /tmp/build/2021.04.06.20.13.43-i386/src/lib
nbmake[3]: stopped in /tmp/build/2021.04.06.20.13.43-i386/src
nbmake[2]: stopped in /tmp/build/2021.04.06.20.13.43-i386/src
nbmake[1]: stopped in /tmp/build/2021.04.06.20.13.43-i386/src
nbmake: stopped in /tmp/build/2021.04.06.20.13.43-i386/src
ERROR: Failed to make release

The following commits were made between the last successful build and
the failed build:

2021.04.06.19.44.24 jkoshy src/external/bsd/elftoolchain/Makefile,v 1.2
2021.04.06.20.13.43 jkoshy src/lib/Makefile,v 1.288

Logs can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2021.04.html#2021.04.06.20.13.43

Re: regarding the changes to kernel entropy gathering

[Koning, Paul]

> On Apr 6, 2021, at 1:54 PM, Greg A. Woods  wrote:
> 
> At Mon, 5 Apr 2021 23:18:55 -0400, Thor Lancelot Simon  wrote:
> Subject: Re: regarding the changes to kernel entropy gathering
>> 
>>> dd if=/dev/urandom of=/dev/random bs=32 count=1
>> 
>> It's no better.
> 
> So then I would say that in fact using some less trustworthy source of
> randomness (e.g. environmental sensors (including audio), clock skew,
> disk rotational latency, etc., even network jitter if there is no other
> source) as the initial seed entropy _is_ better, for most situations,
> and perhaps for _ALL_ situations where no hardware-RNG is available or
> possible.  Better in part because it prevents the brain-dead way of
> seeding, but also because it mixes real-world data in an algorithmically
> sound way.

I've pointed out in the past that mixing in more external stuff can't make the 
RNG any worse, assuming it was correctly designed to begin with.  So if you 
still in various external inputs, the worst that can happen is that you get no 
useful added entropy.

In my way of thinking, externals events timestamped with a high resolution 
(microsecond or better) system clock are likely to have at least a small amount 
of entropy.  It's certainly true that external inputs may be observable, but 
the nanosecond timestamp the system puts on the packet isn't predictable from 
the outside (the low order couple of bits, that is).  

paul

Re: cmake hang ... again

[Michael van Elst]

jo...@bec.de (Joerg Sonnenberger) writes:

>On Tue, Apr 06, 2021 at 04:49:58PM -, Michael van Elst wrote:
>> Otherwise I see several infinite loops, a python deadlock in the samba4 build
>> and, new, the kdelibs4 build stalls for kfiltertest_automoc.cpp.

>The samba4 thing can be avoided with MAKE_JOBS_SAFE=no. I don't fully
>understand what happened with that and run out of steam debugging it.

>kdelibs4 stalls sound like the wait list issue. Does gdb attach or
>STOP/CONT help?

Didn't help for kdelibs4.

Re: cmake hang ... again

[Joerg Sonnenberger]

On Tue, Apr 06, 2021 at 04:49:58PM -, Michael van Elst wrote:
> Otherwise I see several infinite loops, a python deadlock in the samba4 build
> and, new, the kdelibs4 build stalls for kfiltertest_automoc.cpp.

The samba4 thing can be avoided with MAKE_JOBS_SAFE=no. I don't fully
understand what happened with that and run out of steam debugging it.

kdelibs4 stalls sound like the wait list issue. Does gdb attach or
STOP/CONT help?

Joerg

Re: cmake hang ... again

[Joerg Sonnenberger]

On Tue, Apr 06, 2021 at 04:26:44PM -, Christos Zoulas wrote:
> In article ,
> Manuel Bouyer   wrote:
> >On Tue, Apr 06, 2021 at 02:24:50PM +0100, Chavdar Ivanov wrote:
> >> Hi,
> >> 
> >> It may or may not be linked to the recent rather enthralling
> >> discussion about the entropy; I don't know. I've asked for ideas in
> >> the past, but couldn't figure out what to do if it hits me again.
> >> 
> >> Usually I run -current on amd64, updating the systems on average 2-3
> >> times a week; I also use pkgsrc-head and again, 2-3 times a month I
> >> cvs update my pkgsrc tree, together with a ' git pull' in wip, and I
> >> run 'pkg_rolling-replace'.
> >> 
> >> Each and every run of pkg_rolling-replace gets me to a seemingly
> >> identical hang in cmake in a single package - misc/kdepim4 , in
> >> apparently the same spot. with similar trace. Attaching to the process
> >
> >I see the same thing in bulk builds, with various kde packages.
> >When I asked I've been told that this was a known issue, but without fix ...
> 
> I've looked for a specific PR for that problem and while we have multiple
> PR/s for jemalloc we don't have one for this issue. Can we open one?
> Does linking with -lgnumalloc avoid the issue?

This is the CV wait list corruption. jemalloc just makes it more likely.

Joerg

Re: regarding the changes to kernel entropy gathering

[Martin Husemann]

On Tue, Apr 06, 2021 at 10:54:51AM -0700, Greg A. Woods wrote:
> Except it seems to be useless in practice without an initial seed,

Yes.

> And the stock implementation has no possibility of ever providing an
> initial seed at all on its own (unlike previous implementations, and of
> course unlike what my patch _affords_).

Isn't it as simple as:

dd bs=32 if=/dev/urandom of=/dev/random

?

This is a one-time admin operation and it has to be an explicit choice.

Of course there are other possibilities to manualy transfer or create a
seed at installation time (and as has been noted, there once was a page
in sysinst that offered various ones, but was shot down due to user
interface complexity and overloading novice users with question they
were not expected to be able to answer).

Martin

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

At Tue, 6 Apr 2021 12:08:54 +, Taylor R Campbell  
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> The main issue that hits people is that the traditional mechanism by
> which the OS reports a potential security problem with entropy is for
> it to make applications silently hang -- and the issue is getting
> worse now that getrandom() is more widely used, e.g. in Python when
> you do `import multiprocessing'.

I think adding a uprintf(9) that the user who started the blocked
process (i.e. not just the admin) has a better chance of directly seeing
would be one step closer, and should be extremely easy.

--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpOxcINx3I65.pgp
Description: OpenPGP Digital Signature

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

At Mon, 5 Apr 2021 23:18:55 -0400, Thor Lancelot Simon  wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> > dd if=/dev/urandom of=/dev/random bs=32 count=1
>
> It's no better.

So then I would say that in fact using some less trustworthy source of
randomness (e.g. environmental sensors (including audio), clock skew,
disk rotational latency, etc., even network jitter if there is no other
source) as the initial seed entropy _is_ better, for most situations,
and perhaps for _ALL_ situations where no hardware-RNG is available or
possible.  Better in part because it prevents the brain-dead way of
seeding, but also because it mixes real-world data in an algorithmically
sound way.

> But what you're missing is that neither does what you
> think.  When rndctl -L runs after the system comes up multiuser, all
> entropy samples that have been added (which are in the per-cpu pools)
> are propagated to the global pool.  Every stream RNG on the system then
> rekeys itself - they are _not_ just using the entropy from the seed on
> disk.  Even if nothing does so earlier, when rndctl -S runs as the system
> shuts down, again all entropy samples that have been added (which, again,
> are accumulating in the per-cpu pools) are propagated to the global pool;
> all the stream RNGs rekey themselves again; then the seed is extracted.

That's all great, and more or less what I've assumed from all the
previous discussion

Except it seems to be useless in practice without an initial seed,

And the stock implementation has no possibility of ever providing an
initial seed at all on its own (unlike previous implementations, and of
course unlike what my patch _affords_).

So, in all practical ways my two patches together (plus perhaps one or
two other related changes to calls to rnd_attach_source() which don't
currently use RND_FLAG_DEFAULT, such as the one in uvm_page.c), leaves
the default system behaving _exactly_ the same way as before, but for
the fact that now "rndctl -e -d blah" actually does something useful and
doesn't lie about what it has done and the kernel doesn't lie about what
it has been told to do, and in fact entropy can be gathered and used on
systems that don't have hardware RNG devices/instructions.

No change in default security as compared to before the patches.
I.e. the patched system still won't "estimate"/"count" any entropy bits
from any untrusted (non-hardware-RNG) devices.

No less secure than any earlier releases (i.e. from before the entropy
re-tooling) if the admin does decide to gather entropy the old way from
untrusted devices.  (with the caveat that device drivers are no more
aggressive about offering entropy bits to be counted than they should be)

No hacks required for systems without hardware-RNGs -- just a simple
config line in /etc/rc.conf.

No lies from, or apparent bugs in, the kernel.

No other changes required.

> It is neither the case that samples added with a 0 entropy estimate go
> nowhere, nor that they do not add entropy to the seed file such that it
> is _not_ "reusing the same entropy on every boot".

This is good, but, again, useless if there's no seed in the first place.

> If you'd like to propagate samples from the per-CPU pool to the global
> pool and force the stream generators to rekey more often, you can
> sysctl -w kern.entropy.consolidate=1 from cron.

So, are you telling me this should seed the global entropy pool from the
collected samples?  That's not exactly how I've understood it so far.

If so this doesn't seem to do anything whatsoever, no matter how often I
call it, or how long between, or how active the system is, etc., etc.,
etc.  kern.entropy.needed never goes down, /dev/random never unblocks.

17:10 [1.804] # sysctl kern.entropy
kern.entropy.collection = 1
kern.entropy.depletion = 0
kern.entropy.consolidate = -23552
kern.entropy.gather = -23552
kern.entropy.needed = 256
kern.entropy.pending = 0
kern.entropy.epoch = 26
17:10 [1.805] # sysctl -w kern.entropy.consolidate=1
kern.entropy.consolidate: 0 -> 1
17:10 [1.806] # sysctl kern.entropy
kern.entropy.collection = 1
kern.entropy.depletion = 0
kern.entropy.consolidate = -23552
kern.entropy.gather = -23552
kern.entropy.needed = 256
kern.entropy.pending = 0
kern.entropy.epoch = 27
17:10 [1.807] # uptime
 4:57PM  up 23 days, 16:42, 2 users, load averages: 0.01, 0.01, 0.00


BTW, there seems to be a bug somewhere too since when I set it the
change is "0 -> 1", but when I view it the value is always some
incomprehensible meaningless negative number.

# sysctl -M kern.entropy
kern.entropy (1.1260): CTLTYPE_NODE, children 7/8, size 96, flags 
0x0, ver=431
kern.entropy.collection (1.1260.1261): CTLTYPE_BOOL, size 1, flags 
0x70, ver=425
kern.entropy.depletion (1.1260.1262): CTLTYPE_BOOL, size 1, flags 
0x70, ver=426
kern.entropy.consolidate (1.1260.1263): CTLTYPE_INT, size 4, flags 
0x70, func=0x8083f151, ver=427
kern.entropy.gather (1.1260.1264): CTLTYPE_INT, size 4, flags 0x70, 

Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?

[Brian Buhrow]

hello.  Have you tried running a ktrace on the sendmail process, and 
its children, to see
where things are getting stuck?  One other test I can think of is to connect to 
your ISP's
smtp port using openssl from the bad sparc machine and see if you can start up 
a ssl session
using the s_client command.  This should tell you whether or not openssl is the 
problem or if
it's somewhere else.  Yet another idea is to verify that DNS resolution is 
working for the the
afflicted host, by using dig and the always useful sendmail -bt interface.  
With these tests in hand, you should have a much better idea of what's actualy 
going on.  

-thanks
-Brian

Re: cmake hang ... again

[Michael van Elst]

bou...@antioche.eu.org (Manuel Bouyer) writes:

>I see the same thing in bulk builds, with various kde packages.
>When I asked I've been told that this was a known issue, but without fix ...

There are several issues that hang builds.

The cmake hang usually responds well to a SIGSTOP followed by a SIGCONT.

Otherwise I see several infinite loops, a python deadlock in the samba4 build
and, new, the kdelibs4 build stalls for kfiltertest_automoc.cpp.

Re: cmake hang ... again

[Christos Zoulas]

In article ,
Manuel Bouyer   wrote:
>On Tue, Apr 06, 2021 at 02:24:50PM +0100, Chavdar Ivanov wrote:
>> Hi,
>> 
>> It may or may not be linked to the recent rather enthralling
>> discussion about the entropy; I don't know. I've asked for ideas in
>> the past, but couldn't figure out what to do if it hits me again.
>> 
>> Usually I run -current on amd64, updating the systems on average 2-3
>> times a week; I also use pkgsrc-head and again, 2-3 times a month I
>> cvs update my pkgsrc tree, together with a ' git pull' in wip, and I
>> run 'pkg_rolling-replace'.
>> 
>> Each and every run of pkg_rolling-replace gets me to a seemingly
>> identical hang in cmake in a single package - misc/kdepim4 , in
>> apparently the same spot. with similar trace. Attaching to the process
>
>I see the same thing in bulk builds, with various kde packages.
>When I asked I've been told that this was a known issue, but without fix ...

I've looked for a specific PR for that problem and while we have multiple
PR/s for jemalloc we don't have one for this issue. Can we open one?
Does linking with -lgnumalloc avoid the issue?

christos

Re: cmake hang ... again

[Manuel Bouyer]

On Tue, Apr 06, 2021 at 02:24:50PM +0100, Chavdar Ivanov wrote:
> Hi,
> 
> It may or may not be linked to the recent rather enthralling
> discussion about the entropy; I don't know. I've asked for ideas in
> the past, but couldn't figure out what to do if it hits me again.
> 
> Usually I run -current on amd64, updating the systems on average 2-3
> times a week; I also use pkgsrc-head and again, 2-3 times a month I
> cvs update my pkgsrc tree, together with a ' git pull' in wip, and I
> run 'pkg_rolling-replace'.
> 
> Each and every run of pkg_rolling-replace gets me to a seemingly
> identical hang in cmake in a single package - misc/kdepim4 , in
> apparently the same spot. with similar trace. Attaching to the process

I see the same thing in bulk builds, with various kde packages.
When I asked I've been told that this was a known issue, but without fix ...

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

cmake hang ... again

[Chavdar Ivanov]

Hi,

It may or may not be linked to the recent rather enthralling
discussion about the entropy; I don't know. I've asked for ideas in
the past, but couldn't figure out what to do if it hits me again.

Usually I run -current on amd64, updating the systems on average 2-3
times a week; I also use pkgsrc-head and again, 2-3 times a month I
cvs update my pkgsrc tree, together with a ' git pull' in wip, and I
run 'pkg_rolling-replace'.

Each and every run of pkg_rolling-replace gets me to a seemingly
identical hang in cmake in a single package - misc/kdepim4 , in
apparently the same spot. with similar trace. Attaching to the process
with gdb and quitting gets cmake to complete without any other action.
I've posted earlier the trace; here is another one, if it may be of
use:

GNU gdb (GDB) 11.0.50.20200914-git
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 7852
Reading symbols from /usr/pkg/bin/cmake...
(No debugging symbols found in /usr/pkg/bin/cmake)
[New LWP 10070 of process 7852]
[New LWP 2296 of process 7852]
[New LWP 23501 of process 7852]
[New LWP 27321 of process 7852]
[New LWP 7527 of process 7852]
[New LWP 13098 of process 7852]
[New LWP 29281 of process 7852]
[New LWP 7852 of process 7852]
Reading symbols from /usr/lib/libexecinfo.so.0...
(No debugging symbols found in /usr/lib/libexecinfo.so.0)
Reading symbols from /usr/lib/libexpat.so.2...
(No debugging symbols found in /usr/lib/libexpat.so.2)
Reading symbols from /usr/lib/libz.so.1...
(No debugging symbols found in /usr/lib/libz.so.1)
Reading symbols from /usr/lib/libarchive.so.4...
(No debugging symbols found in /usr/lib/libarchive.so.4)
Reading symbols from /usr/pkg/lib/libcurl.so.4...
(No debugging symbols found in /usr/pkg/lib/libcurl.so.4)
Reading symbols from /usr/pkg/lib/libuv.so.1...
Reading symbols from /usr/lib/libcrypto.so.14...
(No debugging symbols found in /usr/lib/libcrypto.so.14)
Reading symbols from /usr/lib/libstdc++.so.9...
(No debugging symbols found in /usr/lib/libstdc++.so.9)
Reading symbols from /usr/lib/libm.so.0...
(No debugging symbols found in /usr/lib/libm.so.0)
Reading symbols from /usr/lib/libgcc_s.so.1...
(No debugging symbols found in /usr/lib/libgcc_s.so.1)
Reading symbols from /usr/lib/libpthread.so.1...
(No debugging symbols found in /usr/lib/libpthread.so.1)
Reading symbols from /usr/lib/libc.so.12...
(No debugging symbols found in /usr/lib/libc.so.12)
Reading symbols from /usr/lib/libelf.so.2...
(No debugging symbols found in /usr/lib/libelf.so.2)
Reading symbols from /usr/lib/libbz2.so.1...
(No debugging symbols found in /usr/lib/libbz2.so.1)
Reading symbols from /usr/lib/liblzma.so.2...
(No debugging symbols found in /usr/lib/liblzma.so.2)
Reading symbols from /usr/pkg/lib/libnghttp2.so.14...
(No debugging symbols found in /usr/pkg/lib/libnghttp2.so.14)
Reading symbols from /usr/pkg/lib/libidn2.so.0...
(No debugging symbols found in /usr/pkg/lib/libidn2.so.0)
Reading symbols from /usr/pkg/lib/librtmp.so.0...
(No debugging symbols found in /usr/pkg/lib/librtmp.so.0)
Reading symbols from /usr/pkg/lib/libgnutls.so.30...
(No debugging symbols found in /usr/pkg/lib/libgnutls.so.30)
Reading symbols from /usr/pkg/lib/libp11-kit.so.0...
Reading symbols from /usr/pkg/lib/libffi.so.7...
(No debugging symbols found in /usr/pkg/lib/libffi.so.7)
Reading symbols from /usr/pkg/lib/libunistring.so.2...
(No debugging symbols found in /usr/pkg/lib/libunistring.so.2)
Reading symbols from /usr/pkg/lib/libtasn1.so.6...
(No debugging symbols found in /usr/pkg/lib/libtasn1.so.6)
Reading symbols from /usr/lib/libintl.so.1...
(No debugging symbols found in /usr/lib/libintl.so.1)
Reading symbols from /usr/pkg/lib/libhogweed.so.6...
Reading symbols from /usr/pkg/lib/libgmp.so.10...
(No debugging symbols found in /usr/pkg/lib/libgmp.so.10)
Reading symbols from /usr/pkg/lib/libnettle.so.8...
Reading symbols from /usr/pkg/lib/libssh2.so.1...
(No debugging symbols found in /usr/pkg/lib/libssh2.so.1)
Reading symbols from /usr/lib/libssl.so.14...
(No debugging symbols found in /usr/lib/libssl.so.14)
Reading symbols from /usr/lib/libgssapi.so.11...
(No debugging symbols found in /usr/lib/libgssapi.so.11)
Reading symbols from /usr/lib/libkvm.so.6...
(No debugging symbols found in /usr/lib/libkvm.so.6)
Reading symbols from /lib/libcrypt.so.1...
(No debugging symbols found in 

Re: regarding the changes to kernel entropy gathering

[Taylor R Campbell]

> Date: Mon, 05 Apr 2021 10:58:58 +0700
> From: Robert Elz 
> 
> I understand that some people desire highly secure systems (I'm not
> convinced that anyone running NetBSD can really justify that desire,
> but that's beside the point) and that's fine - make the system be able
> to be as secure as possible, just don't require me to enable it, and
> don't make it impossible or even difficuly to disable it - and allow
> some kind of middle ground, just just "perfectly secure" and "hopeless".

The main issue that hits people is that the traditional mechanism by
which the OS reports a potential security problem with entropy is for
it to make applications silently hang -- and the issue is getting
worse now that getrandom() is more widely used, e.g. in Python when
you do `import multiprocessing'.

Based on experience over the past year with a meaningful criterion for
_detecting_ potential problems, I don't think that's a useful
mechanism for _reporting_ them, which is why I added several other
mechanisms -- a line in the /etc/security report, an `entropy' knob in
/etc/rc.conf to wait or fail to single-user (default: neither) -- and
proposed to remove the blocking behaviour of getrandom() in favour of
focusing on feedback in system integration:

https://mail-index.netbsd.org/tech-userlevel/2021/01/11/msg012807.html

(main discussion after all the noise starts here:
https://mail-index.netbsd.org/tech-userlevel/2021/01/15/msg012846.html)

But I ran out of steam to continue the discussion at the time.

Re: regarding the changes to kernel entropy gathering

[Taylor R Campbell]

> Date: Mon, 5 Apr 2021 01:16:56 + (UTC)
> From: RVP 
> 
> Then, the issue here is one of predictability. NetBSD doesn't want,
> for extremely valid reason, to incorporate any perturbation sources
> which have been pooh-poohed in the technical literature.

Why do you say that?  We do incorporate many sources that are not
well-studied -- every keystroke, for example, and the CPU cycle
counter at the time of the keystroke, affects the output of
/dev/urandom.

We just don't _count_ these sources for the purpose of detecting and
reporting the potential security problem of low entropy, because we
don't have a good model by which we can confidently claim they are
actually unpredictable to an adversary.

> Or, perhaps statistical tests of the raw in-kernel sources will
> demonstrate exactly why things like timing jitter have been
> pooh-poohed in the literature?

What do you mean by `things like timing jitter have been pooh-poohed
in the literature'?  Timing jitter in ring oscillators arising from
thermal noise in the silicon is the main source of entropy in most
on-die hardware RNGs on the market that I'm aware of.  This design is
reasonably well-studied in the literature.

We even try to use something like it by default in NetBSD when nothing
else is available -- we use the periodic hardclock interrupt timer to
sample the CPU cycle counter, in the hope that these clocks are driven
by independent oscillators with some timing jitter.

However, this is a generic mechanism that works on any machine -- and
on some machines, there is no CPU cycle counter so it might fall back
to using the hardclock timer as a substitute, defeating the purpose.
And even if there is a CPU cycle counter, it might be clocked by the
same oscillator as the hardclock timer,   So we conservatively
count the hardclock entropy source as having zero entropy.

Re: regarding the changes to kernel entropy gathering

[nia]

On Mon, Apr 05, 2021 at 01:22:49PM -0700, Greg A. Woods wrote:
> I don't see how.  I don't see any evidence for that happening.
> 
> So, show me how entropy is being collected in my system:
> 
> 16:18 [1.793] # uptime
>  4:19PM  up 22 days, 16:04, 2 users, load averages: 0.00, 0.00, 0.00
> 16:19 [1.794] # sysctl kern.entropy
> kern.entropy.collection = 1
> kern.entropy.depletion = 0
> kern.entropy.consolidate = -23552
> kern.entropy.gather = -23552
> kern.entropy.needed = 256
> kern.entropy.pending = 0
> kern.entropy.epoch = 24
> 16:19 [1.795] # rndctl -l
> Source Bits Type  Flags
> ipmi0-Temp0 env  estimate, collect, v, t, dv, dt

You should update your rndctl to get my recent changes:

$ priv rndctl -l
Source   Estimated bitsSamples Type   Flags
cgd0  04458546 disk   collect, v, t
/dev/random   0  0 ???collect, v
ld0   0118 disk   collect, v, t
wd0   06160391 disk   collect, v, t
acpibat1-discha   0   5908 power  collect, v, t
acpibat1-charge   0   4212 power  collect, v, t
acpibat0-discha   0   1140 power  collect, v, t
acpibat0-charge   0   1698 power  collect, v, t
[...]
seed256  2 ???estimate, collect, v
rdrand/rdseed   512  1 rngestimate, collect, v