HomeSort by: relevance | last modified time | path
    Searched hist:1.219 (Results 1 - 25 of 481) sorted by relevancy

1 2 3 4 5 6 7 8 91011>>

  /src/usr.bin/midirecord/
Makefile 1.1.2.2 Mon Jan 12 10:22:22 UTC 2015 martin Pull up following revision(s) (requested by mrg in ticket #409):
usr.bin/midirecord/Makefile: revision 1.1
usr.bin/midirecord/midirecord.1: revision 1.1-1.3
usr.bin/midirecord/midirecord.c: revision 1.1-1.6
usr.bin/Makefile: revision 1.219
distrib/sets/lists/base/mi: revision 1.1093
distrib/sets/lists/man/mi: revision 1.1492
distrib/sets/lists/debug/mi: revision 1.98
Add midirecord.

midirecord.1 1.3.2.2 Mon Jan 12 10:22:22 UTC 2015 martin Pull up following revision(s) (requested by mrg in ticket #409):
usr.bin/midirecord/Makefile: revision 1.1
usr.bin/midirecord/midirecord.1: revision 1.1-1.3
usr.bin/midirecord/midirecord.c: revision 1.1-1.6
usr.bin/Makefile: revision 1.219
distrib/sets/lists/base/mi: revision 1.1093
distrib/sets/lists/man/mi: revision 1.1492
distrib/sets/lists/debug/mi: revision 1.98
Add midirecord.

midirecord.c 1.6.2.2 Mon Jan 12 10:22:22 UTC 2015 martin Pull up following revision(s) (requested by mrg in ticket #409):
usr.bin/midirecord/Makefile: revision 1.1
usr.bin/midirecord/midirecord.1: revision 1.1-1.3
usr.bin/midirecord/midirecord.c: revision 1.1-1.6
usr.bin/Makefile: revision 1.219
distrib/sets/lists/base/mi: revision 1.1093
distrib/sets/lists/man/mi: revision 1.1492
distrib/sets/lists/debug/mi: revision 1.98
Add midirecord.

  /src/tests/lib/libc/sys/
t_kevent.c 1.1.6.1 Sat Nov 24 21:40:08 UTC 2012 jdc Pull up revisions:
src/sys/kern/kern_event.c revision 1.79
src/sys/kern/kern_descrip.c revision 1.219
src/lib/libc/sys/kqueue.2 revision 1.33
src/tests/lib/libc/sys/t_kevent.c revision 1.2-1.5
(requested by christos in ticket #716).

- initialize kn_id
- in close, invalidate f_data and f_type early to prevent accidental re-use
- add a DIAGNOSTIC for when we use unsupported fd's and a KASSERT for f_event
being NULL.

Return EOPNOTSUPP for fnullop_kqfilter to prevent registration of unsupported
fds. XXX: We should really fix the fd's to be supported in the future.
Unsupported fd's have a NULL f_event, so registering crashes the kernel with
a NULL function dereference of f_event.

mention that kevent returns now EOPNOTSUPP.

Move the references to PRs from code comments to the test description. Once
ATF has the ability to output the metadata in the HTML reports, it should be
easy to traverse between releng and gnats -reports via links.

Add a (skipped for now) test case for PR 46463

adapt to new reality

Add a test for adding an event to an unsupported fd.

1.1.2.1 Sat Nov 24 21:40:03 UTC 2012 jdc Pull up revisions:
src/sys/kern/kern_event.c revision 1.79
src/sys/kern/kern_descrip.c revision 1.219
src/lib/libc/sys/kqueue.2 revision 1.33
src/tests/lib/libc/sys/t_kevent.c revision 1.2-1.5
(requested by christos in ticket #716).

- initialize kn_id
- in close, invalidate f_data and f_type early to prevent accidental re-use
- add a DIAGNOSTIC for when we use unsupported fd's and a KASSERT for f_event
being NULL.

Return EOPNOTSUPP for fnullop_kqfilter to prevent registration of unsupported
fds. XXX: We should really fix the fd's to be supported in the future.
Unsupported fd's have a NULL f_event, so registering crashes the kernel with
a NULL function dereference of f_event.

mention that kevent returns now EOPNOTSUPP.

Move the references to PRs from code comments to the test description. Once
ATF has the ability to output the metadata in the HTML reports, it should be
easy to traverse between releng and gnats -reports via links.

Add a (skipped for now) test case for PR 46463

adapt to new reality

Add a test for adding an event to an unsupported fd.

  /src/sys/arch/sparc/dev/
apcreg.h 1.1.2.2 Wed Jan 27 21:17:55 UTC 2010 sborrill Pull up the following revisions(s) (requested by bouyer in ticket #1248):
sys/arch/sparc/conf/GENERIC: revision 1.219
sys/arch/sparc/conf/files.sparc: revision 1.149
sys/arch/sparc/dev/apc.c: revision 1.1
sys/arch/sparc/dev/apcreg.h: revision 1.1
sys/dev/DEVNAMES: revision 1.255

Add apc(4), a driver for the Aurora Personality Chip (APC) found
on SPARCstation-4/5, and emulated by qemu to idle the simulator
when the CPU is idle. Infos about the registers from the linux driver.
Not enabled by default because it can cause some Sparc systems to
hang (so says the linux driver).
Only the CPU idle part implemented at this time; fan speed and
Convenience power outlet management to be added.
Tested on qemu.

apc.c 1.1.2.2 Wed Jan 27 21:17:55 UTC 2010 sborrill Pull up the following revisions(s) (requested by bouyer in ticket #1248):
sys/arch/sparc/conf/GENERIC: revision 1.219
sys/arch/sparc/conf/files.sparc: revision 1.149
sys/arch/sparc/dev/apc.c: revision 1.1
sys/arch/sparc/dev/apcreg.h: revision 1.1
sys/dev/DEVNAMES: revision 1.255

Add apc(4), a driver for the Aurora Personality Chip (APC) found
on SPARCstation-4/5, and emulated by qemu to idle the simulator
when the CPU is idle. Infos about the registers from the linux driver.
Not enabled by default because it can cause some Sparc systems to
hang (so says the linux driver).
Only the CPU idle part implemented at this time; fan speed and
Convenience power outlet management to be added.
Tested on qemu.

  /src/sys/modules/acpivmgenid/
Makefile 1.1.2.2 Wed Oct 09 13:25:12 UTC 2024 martin Pull up following revision(s) (requested by riastradh in ticket #939):

distrib/sets/lists/debug/module.md.amd64: revision 1.18
sys/modules/Makefile: revision 1.292
lib/libc/gen/arc4random.c: revision 1.34
lib/libc/gen/arc4random.c: revision 1.35
lib/libc/gen/arc4random.c: revision 1.36
lib/libc/gen/arc4random.c: revision 1.37
sys/kern/kern_entropy.c: revision 1.70
lib/libc/gen/arc4random.c: revision 1.38
sys/kern/kern_entropy.c: revision 1.71
lib/libc/gen/getentropy.3: revision 1.8
distrib/sets/lists/modules/md.amd64: revision 1.103
share/man/man4/rnd.4: revision 1.42
share/man/man4/rnd.4: revision 1.44
lib/libc/include/arc4random.h: revision 1.1
distrib/sets/lists/man/mi: revision 1.1786
sys/arch/i386/conf/GENERIC: revision 1.1258
sys/modules/acpivmgenid/acpivmgenid.ioconf: revision 1.1
sys/arch/amd64/conf/ALL: revision 1.190
distrib/sets/lists/debug/mi: revision 1.446
sys/arch/i386/conf/ALL: revision 1.521
lib/libc/gen/Makefile.inc: revision 1.219
distrib/sets/lists/debug/module.md.i386: revision 1.12
sys/dev/acpi/acpi_vmgenid.c: revision 1.1
sys/dev/acpi/acpi_vmgenid.c: revision 1.2
lib/libc/include/reentrant.h: revision 1.22
sys/arch/evbarm/conf/GENERIC64: revision 1.219
share/man/man4/Makefile: revision 1.735
distrib/sets/lists/modules/md.i386: revision 1.100
distrib/sets/lists/tests/mi: revision 1.1334
lib/libc/gen/arc4random.3: revision 1.22
sys/dev/acpi/files.acpi: revision 1.133
lib/libc/gen/arc4random.3: revision 1.23
tests/lib/libc/gen/t_arc4random.c: revision 1.1
sys/sys/entropy.h: revision 1.6
sys/arch/amd64/conf/GENERIC: revision 1.614
sys/modules/acpivmgenid/Makefile: revision 1.1
share/man/man4/acpivmgenid.4: revision 1.1
lib/libc/gen/Makefile.inc: revision 1.220
tests/lib/libc/gen/Makefile: revision 1.56
share/man/man4/acpivmgenid.4: revision 1.2
share/man/man4/acpivmgenid.4: revision 1.3

(all via patch)

Catch up with all the lint warnings since exit on warning was disabled.

Disable 'missing header declaration' and 'nested extern' warnings for now.
acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Factor out subroutines to reset and gather entropy.
`Reset' means we keep the data in the pool, but assume it had zero
entropy. `Gather' means we request samples from all on-demand
sources and wait for the synchronous ones to complete.

No functional change intended, other than to expose new symbols --
just preparation to expose these to acpivmgenid(4), so it can use
these when the VM host notifies us that we, the guest, have been
cloned.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Reset and gather entropy on VM clone notification.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Reseed if system entropy epoch changes.
This can happen, for example, if the system is a VM instance, and the
VM is cloned.

This incurs the cost of a system call on every arc4random call, which
is unfortunate, but
1. we don't currently have a (machine-independent) mechanism for
exposing a read-only page to userland shared by the kernel to
enable a cheaper access path to the entropy epoch; and
2. the algorithm here -- a simple application of ChaCha -- is likely
also a bottleneck and could be much cheaper by
(a) using sys/crypto/chacha for machine-dependent vectorized
ChaCha code, and
(b) filling a buffer (somewhere between a cipher block and a page)
in a batch at a time, instead of running ChaCha to generate
only 32 bytes at a time.
So although this might be a performance hit, the security benefit is
worthwhile and we have a clear path to do better than reversing the
performance hit later.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Nix BUGS that have been squashed.
Reference kern.entropy.epoch for the remaining bug (which is a
performance issue, not a security issue).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Allow unprivileged reads of sysctl kern.entropy.epoch.

Applications need this in order to know when to reseed. (We should
also expose it through a page shared read-only with userland for
cheaper access, but until we do, let's let applications get at it
through sysctl.)
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random.c: Fix test program.

This isn't wired up anywhere, but let's reduce the bitrot. It was
helpful in reminding me that kern.entropy.epoch was, for reasons I
can't remember, restricted to privileged access.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

amd64, evbarm, i386: Add acpivmgenid(4) to GENERIC.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

rnd(4): Document kern.entropy.epoch is unprivileged and elaborate.
Cross-reference acpivmgenid(4).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Note that arc4random respects kern.entropy.epoch.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork
Add debug info for new acpivmgenid module

arc4random(3): Add automatic tests.

This verifies that:
- arc4random zeroes its state and reseeds itself on fork
- arc4random reseeds itself on entropy consolidation (e.g., VM clone)
- arc4random falls back to global state if it can't allocate local
state because address space limits cause mmap to fail

NOTE: This adds a new libc symbol __arc4random_global, but it's in
the reserved namespace and only used by t_arc4random, so no libc
minor bump.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

getentropy(3): Note intent to reseed on VM clone, and caveats.

Tidy markup and pacify some mandoc -Tlint complaints while here.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

Bump dates on man pages recently updated to mention VM clones.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Pacify some of lint's complaints.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random: suppress another lint warning

distrib/sets/lists/debug/module.md.i386: revision 1.12
sys/dev/acpi/acpi_vmgenid.c: revision 1.1
sys/dev/acpi/acpi_vmgenid.c: revision 1.2
lib/libc/include/reentrant.h: revision 1.22
sys/arch/evbarm/conf/GENERIC64: revision 1.219
share/man/man4/Makefile: revision 1.735
distrib/sets/lists/modules/md.i386: revision 1.100
distrib/sets/lists/tests/mi: revision 1.1334
lib/libc/gen/arc4random.3: revision 1.22
sys/dev/acpi/files.acpi: revision 1.133
lib/libc/gen/arc4random.3: revision 1.23
tests/lib/libc/gen/t_arc4random.c: revision 1.1
sys/sys/entropy.h: revision 1.6
sys/arch/amd64/conf/GENERIC: revision 1.614
sys/modules/acpivmgenid/Makefile: revision 1.1
share/man/man4/acpivmgenid.4: revision 1.1
lib/libc/gen/Makefile.inc: revision 1.220
tests/lib/libc/gen/Makefile: revision 1.56
share/man/man4/acpivmgenid.4: revision 1.2
share/man/man4/acpivmgenid.4: revision 1.3

(all via patch)

Catch up with all the lint warnings since exit on warning was disabled.

Disable 'missing header declaration' and 'nested extern' warnings for now.
acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Factor out subroutines to reset and gather entropy.
`Reset' means we keep the data in the pool, but assume it had zero
entropy. `Gather' means we request samples from all on-demand
sources and wait for the synchronous ones to complete.

No functional change intended, other than to expose new symbols --
just preparation to expose these to acpivmgenid(4), so it can use
these when the VM host notifies us that we, the guest, have been
cloned.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Reset and gather entropy on VM clone notification.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Reseed if system entropy epoch changes.
This can happen, for example, if the system is a VM instance, and the
VM is cloned.

This incurs the cost of a system call on every arc4random call, which
is unfortunate, but
1. we don't currently have a (machine-independent) mechanism for
exposing a read-only page to userland shared by the kernel to
enable a cheaper access path to the entropy epoch; and
2. the algorithm here -- a simple application of ChaCha -- is likely
also a bottleneck and could be much cheaper by
(a) using sys/crypto/chacha for machine-dependent vectorized
ChaCha code, and
(b) filling a buffer (somewhere between a cipher block and a page)
in a batch at a time, instead of running ChaCha to generate
only 32 bytes at a time.
So although this might be a performance hit, the security benefit is
worthwhile and we have a clear path to do better than reversing the
performance hit later.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Nix BUGS that have been squashed.
Reference kern.entropy.epoch for the remaining bug (which is a
performance issue, not a security issue).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Allow unprivileged reads of sysctl kern.entropy.epoch.

Applications need this in order to know when to reseed. (We should
also expose it through a page shared read-only with userland for
cheaper access, but until we do, let's let applications get at it
through sysctl.)
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random.c: Fix test program.

This isn't wired up anywhere, but let's reduce the bitrot. It was
helpful in reminding me that kern.entropy.epoch was, for reasons I
can't remember, restricted to privileged access.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

amd64, evbarm, i386: Add acpivmgenid(4) to GENERIC.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

rnd(4): Document kern.entropy.epoch is unprivileged and elaborate.
Cross-reference acpivmgenid(4).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Note that arc4random respects kern.entropy.epoch.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork
Add debug info for new acpivmgenid module

arc4random(3): Add automatic tests.

This verifies that:
- arc4random zeroes its state and reseeds itself on fork
- arc4random reseeds itself on entropy consolidation (e.g., VM clone)
- arc4random falls back to global state if it can't allocate local
state because address space limits cause mmap to fail

NOTE: This adds a new libc symbol __arc4random_global, but it's in
the reserved namespace and only used by t_arc4random, so no libc
minor bump.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

getentropy(3): Note intent to reseed on VM clone, and caveats.

Tidy markup and pacify some mandoc -Tlint complaints while here.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

Bump dates on man pages recently updated to mention VM clones.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Pacify some of lint's complaints.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random: suppress another lint warning
acpivmgenid.ioconf 1.1.2.2 Wed Oct 09 13:25:12 UTC 2024 martin Pull up following revision(s) (requested by riastradh in ticket #939):

distrib/sets/lists/debug/module.md.amd64: revision 1.18
sys/modules/Makefile: revision 1.292
lib/libc/gen/arc4random.c: revision 1.34
lib/libc/gen/arc4random.c: revision 1.35
lib/libc/gen/arc4random.c: revision 1.36
lib/libc/gen/arc4random.c: revision 1.37
sys/kern/kern_entropy.c: revision 1.70
lib/libc/gen/arc4random.c: revision 1.38
sys/kern/kern_entropy.c: revision 1.71
lib/libc/gen/getentropy.3: revision 1.8
distrib/sets/lists/modules/md.amd64: revision 1.103
share/man/man4/rnd.4: revision 1.42
share/man/man4/rnd.4: revision 1.44
lib/libc/include/arc4random.h: revision 1.1
distrib/sets/lists/man/mi: revision 1.1786
sys/arch/i386/conf/GENERIC: revision 1.1258
sys/modules/acpivmgenid/acpivmgenid.ioconf: revision 1.1
sys/arch/amd64/conf/ALL: revision 1.190
distrib/sets/lists/debug/mi: revision 1.446
sys/arch/i386/conf/ALL: revision 1.521
lib/libc/gen/Makefile.inc: revision 1.219
distrib/sets/lists/debug/module.md.i386: revision 1.12
sys/dev/acpi/acpi_vmgenid.c: revision 1.1
sys/dev/acpi/acpi_vmgenid.c: revision 1.2
lib/libc/include/reentrant.h: revision 1.22
sys/arch/evbarm/conf/GENERIC64: revision 1.219
share/man/man4/Makefile: revision 1.735
distrib/sets/lists/modules/md.i386: revision 1.100
distrib/sets/lists/tests/mi: revision 1.1334
lib/libc/gen/arc4random.3: revision 1.22
sys/dev/acpi/files.acpi: revision 1.133
lib/libc/gen/arc4random.3: revision 1.23
tests/lib/libc/gen/t_arc4random.c: revision 1.1
sys/sys/entropy.h: revision 1.6
sys/arch/amd64/conf/GENERIC: revision 1.614
sys/modules/acpivmgenid/Makefile: revision 1.1
share/man/man4/acpivmgenid.4: revision 1.1
lib/libc/gen/Makefile.inc: revision 1.220
tests/lib/libc/gen/Makefile: revision 1.56
share/man/man4/acpivmgenid.4: revision 1.2
share/man/man4/acpivmgenid.4: revision 1.3

(all via patch)

Catch up with all the lint warnings since exit on warning was disabled.

Disable 'missing header declaration' and 'nested extern' warnings for now.
acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Factor out subroutines to reset and gather entropy.
`Reset' means we keep the data in the pool, but assume it had zero
entropy. `Gather' means we request samples from all on-demand
sources and wait for the synchronous ones to complete.

No functional change intended, other than to expose new symbols --
just preparation to expose these to acpivmgenid(4), so it can use
these when the VM host notifies us that we, the guest, have been
cloned.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Reset and gather entropy on VM clone notification.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Reseed if system entropy epoch changes.
This can happen, for example, if the system is a VM instance, and the
VM is cloned.

This incurs the cost of a system call on every arc4random call, which
is unfortunate, but
1. we don't currently have a (machine-independent) mechanism for
exposing a read-only page to userland shared by the kernel to
enable a cheaper access path to the entropy epoch; and
2. the algorithm here -- a simple application of ChaCha -- is likely
also a bottleneck and could be much cheaper by
(a) using sys/crypto/chacha for machine-dependent vectorized
ChaCha code, and
(b) filling a buffer (somewhere between a cipher block and a page)
in a batch at a time, instead of running ChaCha to generate
only 32 bytes at a time.
So although this might be a performance hit, the security benefit is
worthwhile and we have a clear path to do better than reversing the
performance hit later.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Nix BUGS that have been squashed.
Reference kern.entropy.epoch for the remaining bug (which is a
performance issue, not a security issue).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Allow unprivileged reads of sysctl kern.entropy.epoch.

Applications need this in order to know when to reseed. (We should
also expose it through a page shared read-only with userland for
cheaper access, but until we do, let's let applications get at it
through sysctl.)
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random.c: Fix test program.

This isn't wired up anywhere, but let's reduce the bitrot. It was
helpful in reminding me that kern.entropy.epoch was, for reasons I
can't remember, restricted to privileged access.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

amd64, evbarm, i386: Add acpivmgenid(4) to GENERIC.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

rnd(4): Document kern.entropy.epoch is unprivileged and elaborate.
Cross-reference acpivmgenid(4).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Note that arc4random respects kern.entropy.epoch.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork
Add debug info for new acpivmgenid module

arc4random(3): Add automatic tests.

This verifies that:
- arc4random zeroes its state and reseeds itself on fork
- arc4random reseeds itself on entropy consolidation (e.g., VM clone)
- arc4random falls back to global state if it can't allocate local
state because address space limits cause mmap to fail

NOTE: This adds a new libc symbol __arc4random_global, but it's in
the reserved namespace and only used by t_arc4random, so no libc
minor bump.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

getentropy(3): Note intent to reseed on VM clone, and caveats.

Tidy markup and pacify some mandoc -Tlint complaints while here.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

Bump dates on man pages recently updated to mention VM clones.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Pacify some of lint's complaints.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random: suppress another lint warning


distrib/sets/lists/debug/module.md.i386: revision 1.12
sys/dev/acpi/acpi_vmgenid.c: revision 1.1
sys/dev/acpi/acpi_vmgenid.c: revision 1.2
lib/libc/include/reentrant.h: revision 1.22
sys/arch/evbarm/conf/GENERIC64: revision 1.219
share/man/man4/Makefile: revision 1.735
distrib/sets/lists/modules/md.i386: revision 1.100
distrib/sets/lists/tests/mi: revision 1.1334
lib/libc/gen/arc4random.3: revision 1.22
sys/dev/acpi/files.acpi: revision 1.133
lib/libc/gen/arc4random.3: revision 1.23
tests/lib/libc/gen/t_arc4random.c: revision 1.1
sys/sys/entropy.h: revision 1.6
sys/arch/amd64/conf/GENERIC: revision 1.614
sys/modules/acpivmgenid/Makefile: revision 1.1
share/man/man4/acpivmgenid.4: revision 1.1
lib/libc/gen/Makefile.inc: revision 1.220
tests/lib/libc/gen/Makefile: revision 1.56
share/man/man4/acpivmgenid.4: revision 1.2
share/man/man4/acpivmgenid.4: revision 1.3

(all via patch)

Catch up with all the lint warnings since exit on warning was disabled.

Disable 'missing header declaration' and 'nested extern' warnings for now.
acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Factor out subroutines to reset and gather entropy.
`Reset' means we keep the data in the pool, but assume it had zero
entropy. `Gather' means we request samples from all on-demand
sources and wait for the synchronous ones to complete.

No functional change intended, other than to expose new symbols --
just preparation to expose these to acpivmgenid(4), so it can use
these when the VM host notifies us that we, the guest, have been
cloned.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Reset and gather entropy on VM clone notification.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Reseed if system entropy epoch changes.
This can happen, for example, if the system is a VM instance, and the
VM is cloned.

This incurs the cost of a system call on every arc4random call, which
is unfortunate, but
1. we don't currently have a (machine-independent) mechanism for
exposing a read-only page to userland shared by the kernel to
enable a cheaper access path to the entropy epoch; and
2. the algorithm here -- a simple application of ChaCha -- is likely
also a bottleneck and could be much cheaper by
(a) using sys/crypto/chacha for machine-dependent vectorized
ChaCha code, and
(b) filling a buffer (somewhere between a cipher block and a page)
in a batch at a time, instead of running ChaCha to generate
only 32 bytes at a time.
So although this might be a performance hit, the security benefit is
worthwhile and we have a clear path to do better than reversing the
performance hit later.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Nix BUGS that have been squashed.
Reference kern.entropy.epoch for the remaining bug (which is a
performance issue, not a security issue).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Allow unprivileged reads of sysctl kern.entropy.epoch.

Applications need this in order to know when to reseed. (We should
also expose it through a page shared read-only with userland for
cheaper access, but until we do, let's let applications get at it
through sysctl.)
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random.c: Fix test program.

This isn't wired up anywhere, but let's reduce the bitrot. It was
helpful in reminding me that kern.entropy.epoch was, for reasons I
can't remember, restricted to privileged access.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

amd64, evbarm, i386: Add acpivmgenid(4) to GENERIC.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

rnd(4): Document kern.entropy.epoch is unprivileged and elaborate.
Cross-reference acpivmgenid(4).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Note that arc4random respects kern.entropy.epoch.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork
Add debug info for new acpivmgenid module

arc4random(3): Add automatic tests.

This verifies that:
- arc4random zeroes its state and reseeds itself on fork
- arc4random reseeds itself on entropy consolidation (e.g., VM clone)
- arc4random falls back to global state if it can't allocate local
state because address space limits cause mmap to fail

NOTE: This adds a new libc symbol __arc4random_global, but it's in
the reserved namespace and only used by t_arc4random, so no libc
minor bump.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

getentropy(3): Note intent to reseed on VM clone, and caveats.

Tidy markup and pacify some mandoc -Tlint complaints while here.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

Bump dates on man pages recently updated to mention VM clones.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Pacify some of lint's complaints.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random: suppress another lint warning

  /src/lib/libc/include/
arc4random.h 1.1.2.2 Wed Oct 09 13:25:11 UTC 2024 martin Pull up following revision(s) (requested by riastradh in ticket #939):

distrib/sets/lists/debug/module.md.amd64: revision 1.18
sys/modules/Makefile: revision 1.292
lib/libc/gen/arc4random.c: revision 1.34
lib/libc/gen/arc4random.c: revision 1.35
lib/libc/gen/arc4random.c: revision 1.36
lib/libc/gen/arc4random.c: revision 1.37
sys/kern/kern_entropy.c: revision 1.70
lib/libc/gen/arc4random.c: revision 1.38
sys/kern/kern_entropy.c: revision 1.71
lib/libc/gen/getentropy.3: revision 1.8
distrib/sets/lists/modules/md.amd64: revision 1.103
share/man/man4/rnd.4: revision 1.42
share/man/man4/rnd.4: revision 1.44
lib/libc/include/arc4random.h: revision 1.1
distrib/sets/lists/man/mi: revision 1.1786
sys/arch/i386/conf/GENERIC: revision 1.1258
sys/modules/acpivmgenid/acpivmgenid.ioconf: revision 1.1
sys/arch/amd64/conf/ALL: revision 1.190
distrib/sets/lists/debug/mi: revision 1.446
sys/arch/i386/conf/ALL: revision 1.521
lib/libc/gen/Makefile.inc: revision 1.219
distrib/sets/lists/debug/module.md.i386: revision 1.12
sys/dev/acpi/acpi_vmgenid.c: revision 1.1
sys/dev/acpi/acpi_vmgenid.c: revision 1.2
lib/libc/include/reentrant.h: revision 1.22
sys/arch/evbarm/conf/GENERIC64: revision 1.219
share/man/man4/Makefile: revision 1.735
distrib/sets/lists/modules/md.i386: revision 1.100
distrib/sets/lists/tests/mi: revision 1.1334
lib/libc/gen/arc4random.3: revision 1.22
sys/dev/acpi/files.acpi: revision 1.133
lib/libc/gen/arc4random.3: revision 1.23
tests/lib/libc/gen/t_arc4random.c: revision 1.1
sys/sys/entropy.h: revision 1.6
sys/arch/amd64/conf/GENERIC: revision 1.614
sys/modules/acpivmgenid/Makefile: revision 1.1
share/man/man4/acpivmgenid.4: revision 1.1
lib/libc/gen/Makefile.inc: revision 1.220
tests/lib/libc/gen/Makefile: revision 1.56
share/man/man4/acpivmgenid.4: revision 1.2
share/man/man4/acpivmgenid.4: revision 1.3

(all via patch)

Catch up with all the lint warnings since exit on warning was disabled.

Disable 'missing header declaration' and 'nested extern' warnings for now.
acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Factor out subroutines to reset and gather entropy.
`Reset' means we keep the data in the pool, but assume it had zero
entropy. `Gather' means we request samples from all on-demand
sources and wait for the synchronous ones to complete.

No functional change intended, other than to expose new symbols --
just preparation to expose these to acpivmgenid(4), so it can use
these when the VM host notifies us that we, the guest, have been
cloned.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Reset and gather entropy on VM clone notification.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Reseed if system entropy epoch changes.
This can happen, for example, if the system is a VM instance, and the
VM is cloned.

This incurs the cost of a system call on every arc4random call, which
is unfortunate, but
1. we don't currently have a (machine-independent) mechanism for
exposing a read-only page to userland shared by the kernel to
enable a cheaper access path to the entropy epoch; and
2. the algorithm here -- a simple application of ChaCha -- is likely
also a bottleneck and could be much cheaper by
(a) using sys/crypto/chacha for machine-dependent vectorized
ChaCha code, and
(b) filling a buffer (somewhere between a cipher block and a page)
in a batch at a time, instead of running ChaCha to generate
only 32 bytes at a time.
So although this might be a performance hit, the security benefit is
worthwhile and we have a clear path to do better than reversing the
performance hit later.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Nix BUGS that have been squashed.
Reference kern.entropy.epoch for the remaining bug (which is a
performance issue, not a security issue).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Allow unprivileged reads of sysctl kern.entropy.epoch.

Applications need this in order to know when to reseed. (We should
also expose it through a page shared read-only with userland for
cheaper access, but until we do, let's let applications get at it
through sysctl.)
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random.c: Fix test program.

This isn't wired up anywhere, but let's reduce the bitrot. It was
helpful in reminding me that kern.entropy.epoch was, for reasons I
can't remember, restricted to privileged access.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

amd64, evbarm, i386: Add acpivmgenid(4) to GENERIC.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

rnd(4): Document kern.entropy.epoch is unprivileged and elaborate.
Cross-reference acpivmgenid(4).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Note that arc4random respects kern.entropy.epoch.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork
Add debug info for new acpivmgenid module

arc4random(3): Add automatic tests.

This verifies that:
- arc4random zeroes its state and reseeds itself on fork
- arc4random reseeds itself on entropy consolidation (e.g., VM clone)
- arc4random falls back to global state if it can't allocate local
state because address space limits cause mmap to fail

NOTE: This adds a new libc symbol __arc4random_global, but it's in
the reserved namespace and only used by t_arc4random, so no libc
minor bump.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

getentropy(3): Note intent to reseed on VM clone, and caveats.

Tidy markup and pacify some mandoc -Tlint complaints while here.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

Bump dates on man pages recently updated to mention VM clones.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Pacify some of lint's complaints.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random: suppress another lint warning


distrib/sets/lists/debug/module.md.i386: revision 1.12
sys/dev/acpi/acpi_vmgenid.c: revision 1.1
sys/dev/acpi/acpi_vmgenid.c: revision 1.2
lib/libc/include/reentrant.h: revision 1.22
sys/arch/evbarm/conf/GENERIC64: revision 1.219
share/man/man4/Makefile: revision 1.735
distrib/sets/lists/modules/md.i386: revision 1.100
distrib/sets/lists/tests/mi: revision 1.1334
lib/libc/gen/arc4random.3: revision 1.22
sys/dev/acpi/files.acpi: revision 1.133
lib/libc/gen/arc4random.3: revision 1.23
tests/lib/libc/gen/t_arc4random.c: revision 1.1
sys/sys/entropy.h: revision 1.6
sys/arch/amd64/conf/GENERIC: revision 1.614
sys/modules/acpivmgenid/Makefile: revision 1.1
share/man/man4/acpivmgenid.4: revision 1.1
lib/libc/gen/Makefile.inc: revision 1.220
tests/lib/libc/gen/Makefile: revision 1.56
share/man/man4/acpivmgenid.4: revision 1.2
share/man/man4/acpivmgenid.4: revision 1.3

(all via patch)

Catch up with all the lint warnings since exit on warning was disabled.

Disable 'missing header declaration' and 'nested extern' warnings for now.
acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Factor out subroutines to reset and gather entropy.
`Reset' means we keep the data in the pool, but assume it had zero
entropy. `Gather' means we request samples from all on-demand
sources and wait for the synchronous ones to complete.

No functional change intended, other than to expose new symbols --
just preparation to expose these to acpivmgenid(4), so it can use
these when the VM host notifies us that we, the guest, have been
cloned.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Reset and gather entropy on VM clone notification.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Reseed if system entropy epoch changes.
This can happen, for example, if the system is a VM instance, and the
VM is cloned.

This incurs the cost of a system call on every arc4random call, which
is unfortunate, but
1. we don't currently have a (machine-independent) mechanism for
exposing a read-only page to userland shared by the kernel to
enable a cheaper access path to the entropy epoch; and
2. the algorithm here -- a simple application of ChaCha -- is likely
also a bottleneck and could be much cheaper by
(a) using sys/crypto/chacha for machine-dependent vectorized
ChaCha code, and
(b) filling a buffer (somewhere between a cipher block and a page)
in a batch at a time, instead of running ChaCha to generate
only 32 bytes at a time.
So although this might be a performance hit, the security benefit is
worthwhile and we have a clear path to do better than reversing the
performance hit later.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Nix BUGS that have been squashed.
Reference kern.entropy.epoch for the remaining bug (which is a
performance issue, not a security issue).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Allow unprivileged reads of sysctl kern.entropy.epoch.

Applications need this in order to know when to reseed. (We should
also expose it through a page shared read-only with userland for
cheaper access, but until we do, let's let applications get at it
through sysctl.)
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random.c: Fix test program.

This isn't wired up anywhere, but let's reduce the bitrot. It was
helpful in reminding me that kern.entropy.epoch was, for reasons I
can't remember, restricted to privileged access.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

amd64, evbarm, i386: Add acpivmgenid(4) to GENERIC.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

rnd(4): Document kern.entropy.epoch is unprivileged and elaborate.
Cross-reference acpivmgenid(4).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Note that arc4random respects kern.entropy.epoch.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork
Add debug info for new acpivmgenid module

arc4random(3): Add automatic tests.

This verifies that:
- arc4random zeroes its state and reseeds itself on fork
- arc4random reseeds itself on entropy consolidation (e.g., VM clone)
- arc4random falls back to global state if it can't allocate local
state because address space limits cause mmap to fail

NOTE: This adds a new libc symbol __arc4random_global, but it's in
the reserved namespace and only used by t_arc4random, so no libc
minor bump.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

getentropy(3): Note intent to reseed on VM clone, and caveats.

Tidy markup and pacify some mandoc -Tlint complaints while here.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

Bump dates on man pages recently updated to mention VM clones.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Pacify some of lint's complaints.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random: suppress another lint warning

  /src/share/man/man4/
acpivmgenid.4 1.3.2.2 Wed Oct 09 13:25:11 UTC 2024 martin Pull up following revision(s) (requested by riastradh in ticket #939):

distrib/sets/lists/debug/module.md.amd64: revision 1.18
sys/modules/Makefile: revision 1.292
lib/libc/gen/arc4random.c: revision 1.34
lib/libc/gen/arc4random.c: revision 1.35
lib/libc/gen/arc4random.c: revision 1.36
lib/libc/gen/arc4random.c: revision 1.37
sys/kern/kern_entropy.c: revision 1.70
lib/libc/gen/arc4random.c: revision 1.38
sys/kern/kern_entropy.c: revision 1.71
lib/libc/gen/getentropy.3: revision 1.8
distrib/sets/lists/modules/md.amd64: revision 1.103
share/man/man4/rnd.4: revision 1.42
share/man/man4/rnd.4: revision 1.44
lib/libc/include/arc4random.h: revision 1.1
distrib/sets/lists/man/mi: revision 1.1786
sys/arch/i386/conf/GENERIC: revision 1.1258
sys/modules/acpivmgenid/acpivmgenid.ioconf: revision 1.1
sys/arch/amd64/conf/ALL: revision 1.190
distrib/sets/lists/debug/mi: revision 1.446
sys/arch/i386/conf/ALL: revision 1.521
lib/libc/gen/Makefile.inc: revision 1.219
distrib/sets/lists/debug/module.md.i386: revision 1.12
sys/dev/acpi/acpi_vmgenid.c: revision 1.1
sys/dev/acpi/acpi_vmgenid.c: revision 1.2
lib/libc/include/reentrant.h: revision 1.22
sys/arch/evbarm/conf/GENERIC64: revision 1.219
share/man/man4/Makefile: revision 1.735
distrib/sets/lists/modules/md.i386: revision 1.100
distrib/sets/lists/tests/mi: revision 1.1334
lib/libc/gen/arc4random.3: revision 1.22
sys/dev/acpi/files.acpi: revision 1.133
lib/libc/gen/arc4random.3: revision 1.23
tests/lib/libc/gen/t_arc4random.c: revision 1.1
sys/sys/entropy.h: revision 1.6
sys/arch/amd64/conf/GENERIC: revision 1.614
sys/modules/acpivmgenid/Makefile: revision 1.1
share/man/man4/acpivmgenid.4: revision 1.1
lib/libc/gen/Makefile.inc: revision 1.220
tests/lib/libc/gen/Makefile: revision 1.56
share/man/man4/acpivmgenid.4: revision 1.2
share/man/man4/acpivmgenid.4: revision 1.3

(all via patch)

Catch up with all the lint warnings since exit on warning was disabled.

Disable 'missing header declaration' and 'nested extern' warnings for now.
acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Factor out subroutines to reset and gather entropy.
`Reset' means we keep the data in the pool, but assume it had zero
entropy. `Gather' means we request samples from all on-demand
sources and wait for the synchronous ones to complete.

No functional change intended, other than to expose new symbols --
just preparation to expose these to acpivmgenid(4), so it can use
these when the VM host notifies us that we, the guest, have been
cloned.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Reset and gather entropy on VM clone notification.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Reseed if system entropy epoch changes.
This can happen, for example, if the system is a VM instance, and the
VM is cloned.

This incurs the cost of a system call on every arc4random call, which
is unfortunate, but
1. we don't currently have a (machine-independent) mechanism for
exposing a read-only page to userland shared by the kernel to
enable a cheaper access path to the entropy epoch; and
2. the algorithm here -- a simple application of ChaCha -- is likely
also a bottleneck and could be much cheaper by
(a) using sys/crypto/chacha for machine-dependent vectorized
ChaCha code, and
(b) filling a buffer (somewhere between a cipher block and a page)
in a batch at a time, instead of running ChaCha to generate
only 32 bytes at a time.
So although this might be a performance hit, the security benefit is
worthwhile and we have a clear path to do better than reversing the
performance hit later.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Nix BUGS that have been squashed.
Reference kern.entropy.epoch for the remaining bug (which is a
performance issue, not a security issue).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Allow unprivileged reads of sysctl kern.entropy.epoch.

Applications need this in order to know when to reseed. (We should
also expose it through a page shared read-only with userland for
cheaper access, but until we do, let's let applications get at it
through sysctl.)
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random.c: Fix test program.

This isn't wired up anywhere, but let's reduce the bitrot. It was
helpful in reminding me that kern.entropy.epoch was, for reasons I
can't remember, restricted to privileged access.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

amd64, evbarm, i386: Add acpivmgenid(4) to GENERIC.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

rnd(4): Document kern.entropy.epoch is unprivileged and elaborate.
Cross-reference acpivmgenid(4).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Note that arc4random respects kern.entropy.epoch.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork
Add debug info for new acpivmgenid module

arc4random(3): Add automatic tests.

This verifies that:
- arc4random zeroes its state and reseeds itself on fork
- arc4random reseeds itself on entropy consolidation (e.g., VM clone)
- arc4random falls back to global state if it can't allocate local
state because address space limits cause mmap to fail

NOTE: This adds a new libc symbol __arc4random_global, but it's in
the reserved namespace and only used by t_arc4random, so no libc
minor bump.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

getentropy(3): Note intent to reseed on VM clone, and caveats.

Tidy markup and pacify some mandoc -Tlint complaints while here.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

Bump dates on man pages recently updated to mention VM clones.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Pacify some of lint's complaints.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random: suppress another lint warning


distrib/sets/lists/debug/module.md.i386: revision 1.12
sys/dev/acpi/acpi_vmgenid.c: revision 1.1
sys/dev/acpi/acpi_vmgenid.c: revision 1.2
lib/libc/include/reentrant.h: revision 1.22
sys/arch/evbarm/conf/GENERIC64: revision 1.219
share/man/man4/Makefile: revision 1.735
distrib/sets/lists/modules/md.i386: revision 1.100
distrib/sets/lists/tests/mi: revision 1.1334
lib/libc/gen/arc4random.3: revision 1.22
sys/dev/acpi/files.acpi: revision 1.133
lib/libc/gen/arc4random.3: revision 1.23
tests/lib/libc/gen/t_arc4random.c: revision 1.1
sys/sys/entropy.h: revision 1.6
sys/arch/amd64/conf/GENERIC: revision 1.614
sys/modules/acpivmgenid/Makefile: revision 1.1
share/man/man4/acpivmgenid.4: revision 1.1
lib/libc/gen/Makefile.inc: revision 1.220
tests/lib/libc/gen/Makefile: revision 1.56
share/man/man4/acpivmgenid.4: revision 1.2
share/man/man4/acpivmgenid.4: revision 1.3

(all via patch)

Catch up with all the lint warnings since exit on warning was disabled.

Disable 'missing header declaration' and 'nested extern' warnings for now.
acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Factor out subroutines to reset and gather entropy.
`Reset' means we keep the data in the pool, but assume it had zero
entropy. `Gather' means we request samples from all on-demand
sources and wait for the synchronous ones to complete.

No functional change intended, other than to expose new symbols --
just preparation to expose these to acpivmgenid(4), so it can use
these when the VM host notifies us that we, the guest, have been
cloned.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Reset and gather entropy on VM clone notification.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Reseed if system entropy epoch changes.
This can happen, for example, if the system is a VM instance, and the
VM is cloned.

This incurs the cost of a system call on every arc4random call, which
is unfortunate, but
1. we don't currently have a (machine-independent) mechanism for
exposing a read-only page to userland shared by the kernel to
enable a cheaper access path to the entropy epoch; and
2. the algorithm here -- a simple application of ChaCha -- is likely
also a bottleneck and could be much cheaper by
(a) using sys/crypto/chacha for machine-dependent vectorized
ChaCha code, and
(b) filling a buffer (somewhere between a cipher block and a page)
in a batch at a time, instead of running ChaCha to generate
only 32 bytes at a time.
So although this might be a performance hit, the security benefit is
worthwhile and we have a clear path to do better than reversing the
performance hit later.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Nix BUGS that have been squashed.
Reference kern.entropy.epoch for the remaining bug (which is a
performance issue, not a security issue).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Allow unprivileged reads of sysctl kern.entropy.epoch.

Applications need this in order to know when to reseed. (We should
also expose it through a page shared read-only with userland for
cheaper access, but until we do, let's let applications get at it
through sysctl.)
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random.c: Fix test program.

This isn't wired up anywhere, but let's reduce the bitrot. It was
helpful in reminding me that kern.entropy.epoch was, for reasons I
can't remember, restricted to privileged access.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

amd64, evbarm, i386: Add acpivmgenid(4) to GENERIC.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

rnd(4): Document kern.entropy.epoch is unprivileged and elaborate.
Cross-reference acpivmgenid(4).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Note that arc4random respects kern.entropy.epoch.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork
Add debug info for new acpivmgenid module

arc4random(3): Add automatic tests.

This verifies that:
- arc4random zeroes its state and reseeds itself on fork
- arc4random reseeds itself on entropy consolidation (e.g., VM clone)
- arc4random falls back to global state if it can't allocate local
state because address space limits cause mmap to fail

NOTE: This adds a new libc symbol __arc4random_global, but it's in
the reserved namespace and only used by t_arc4random, so no libc
minor bump.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

getentropy(3): Note intent to reseed on VM clone, and caveats.

Tidy markup and pacify some mandoc -Tlint complaints while here.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

Bump dates on man pages recently updated to mention VM clones.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Pacify some of lint's complaints.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random: suppress another lint warning

  /src/share/man/man8/man8.x86/
dosboot.8 1.3.22.1 Sat May 13 13:26:56 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #159):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28
share/man/man8/man8.x86/boot.8: revision 1.29
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.


Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.


Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

1.3.14.1 Sat May 13 11:45:53 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #1632):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28 (via patch)
share/man/man8/man8.x86/boot.8: revision 1.29 (via patch)
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.

Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.

Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

pxeboot.8 1.4.14.1 Sat May 13 11:45:53 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #1632):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28 (via patch)
share/man/man8/man8.x86/boot.8: revision 1.29 (via patch)
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.

Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.

Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

1.5.6.1 Sat May 13 13:26:56 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #159):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28
share/man/man8/man8.x86/boot.8: revision 1.29
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.


Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.


Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

  /src/sys/arch/i386/stand/efiboot/bootia32/
startprog32.S 1.2.52.1 Sat May 13 13:26:57 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #159):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28
share/man/man8/man8.x86/boot.8: revision 1.29
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.


Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.


Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

1.2.26.1 Sat May 13 11:45:53 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #1632):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28 (via patch)
share/man/man8/man8.x86/boot.8: revision 1.29 (via patch)
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.

Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.

Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

  /src/sys/arch/i386/stand/efiboot/bootx64/
startprog64.S 1.3.50.1 Sat May 13 13:26:57 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #159):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28
share/man/man8/man8.x86/boot.8: revision 1.29
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.


Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.


Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

1.3.24.1 Sat May 13 11:45:53 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #1632):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28 (via patch)
share/man/man8/man8.x86/boot.8: revision 1.29 (via patch)
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.

Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.

Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

  /src/sys/arch/i386/stand/efiboot/
version 1.1.26.2 Sat May 13 11:45:53 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #1632):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28 (via patch)
share/man/man8/man8.x86/boot.8: revision 1.29 (via patch)
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.

Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.

Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

1.2.26.1 Sat May 13 13:26:56 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #159):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28
share/man/man8/man8.x86/boot.8: revision 1.29
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.


Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.


Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

  /src/sys/dev/acpi/
acpi_vmgenid.c 1.3.2.2 Wed Oct 09 13:25:12 UTC 2024 martin Pull up following revision(s) (requested by riastradh in ticket #939):

distrib/sets/lists/debug/module.md.amd64: revision 1.18
sys/modules/Makefile: revision 1.292
lib/libc/gen/arc4random.c: revision 1.34
lib/libc/gen/arc4random.c: revision 1.35
lib/libc/gen/arc4random.c: revision 1.36
lib/libc/gen/arc4random.c: revision 1.37
sys/kern/kern_entropy.c: revision 1.70
lib/libc/gen/arc4random.c: revision 1.38
sys/kern/kern_entropy.c: revision 1.71
lib/libc/gen/getentropy.3: revision 1.8
distrib/sets/lists/modules/md.amd64: revision 1.103
share/man/man4/rnd.4: revision 1.42
share/man/man4/rnd.4: revision 1.44
lib/libc/include/arc4random.h: revision 1.1
distrib/sets/lists/man/mi: revision 1.1786
sys/arch/i386/conf/GENERIC: revision 1.1258
sys/modules/acpivmgenid/acpivmgenid.ioconf: revision 1.1
sys/arch/amd64/conf/ALL: revision 1.190
distrib/sets/lists/debug/mi: revision 1.446
sys/arch/i386/conf/ALL: revision 1.521
lib/libc/gen/Makefile.inc: revision 1.219
distrib/sets/lists/debug/module.md.i386: revision 1.12
sys/dev/acpi/acpi_vmgenid.c: revision 1.1
sys/dev/acpi/acpi_vmgenid.c: revision 1.2
lib/libc/include/reentrant.h: revision 1.22
sys/arch/evbarm/conf/GENERIC64: revision 1.219
share/man/man4/Makefile: revision 1.735
distrib/sets/lists/modules/md.i386: revision 1.100
distrib/sets/lists/tests/mi: revision 1.1334
lib/libc/gen/arc4random.3: revision 1.22
sys/dev/acpi/files.acpi: revision 1.133
lib/libc/gen/arc4random.3: revision 1.23
tests/lib/libc/gen/t_arc4random.c: revision 1.1
sys/sys/entropy.h: revision 1.6
sys/arch/amd64/conf/GENERIC: revision 1.614
sys/modules/acpivmgenid/Makefile: revision 1.1
share/man/man4/acpivmgenid.4: revision 1.1
lib/libc/gen/Makefile.inc: revision 1.220
tests/lib/libc/gen/Makefile: revision 1.56
share/man/man4/acpivmgenid.4: revision 1.2
share/man/man4/acpivmgenid.4: revision 1.3

(all via patch)

Catch up with all the lint warnings since exit on warning was disabled.

Disable 'missing header declaration' and 'nested extern' warnings for now.
acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Factor out subroutines to reset and gather entropy.
`Reset' means we keep the data in the pool, but assume it had zero
entropy. `Gather' means we request samples from all on-demand
sources and wait for the synchronous ones to complete.

No functional change intended, other than to expose new symbols --
just preparation to expose these to acpivmgenid(4), so it can use
these when the VM host notifies us that we, the guest, have been
cloned.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Reset and gather entropy on VM clone notification.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Reseed if system entropy epoch changes.
This can happen, for example, if the system is a VM instance, and the
VM is cloned.

This incurs the cost of a system call on every arc4random call, which
is unfortunate, but
1. we don't currently have a (machine-independent) mechanism for
exposing a read-only page to userland shared by the kernel to
enable a cheaper access path to the entropy epoch; and
2. the algorithm here -- a simple application of ChaCha -- is likely
also a bottleneck and could be much cheaper by
(a) using sys/crypto/chacha for machine-dependent vectorized
ChaCha code, and
(b) filling a buffer (somewhere between a cipher block and a page)
in a batch at a time, instead of running ChaCha to generate
only 32 bytes at a time.
So although this might be a performance hit, the security benefit is
worthwhile and we have a clear path to do better than reversing the
performance hit later.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Nix BUGS that have been squashed.
Reference kern.entropy.epoch for the remaining bug (which is a
performance issue, not a security issue).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Allow unprivileged reads of sysctl kern.entropy.epoch.

Applications need this in order to know when to reseed. (We should
also expose it through a page shared read-only with userland for
cheaper access, but until we do, let's let applications get at it
through sysctl.)
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random.c: Fix test program.

This isn't wired up anywhere, but let's reduce the bitrot. It was
helpful in reminding me that kern.entropy.epoch was, for reasons I
can't remember, restricted to privileged access.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

amd64, evbarm, i386: Add acpivmgenid(4) to GENERIC.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

rnd(4): Document kern.entropy.epoch is unprivileged and elaborate.
Cross-reference acpivmgenid(4).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Note that arc4random respects kern.entropy.epoch.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork
Add debug info for new acpivmgenid module

arc4random(3): Add automatic tests.

This verifies that:
- arc4random zeroes its state and reseeds itself on fork
- arc4random reseeds itself on entropy consolidation (e.g., VM clone)
- arc4random falls back to global state if it can't allocate local
state because address space limits cause mmap to fail

NOTE: This adds a new libc symbol __arc4random_global, but it's in
the reserved namespace and only used by t_arc4random, so no libc
minor bump.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

getentropy(3): Note intent to reseed on VM clone, and caveats.

Tidy markup and pacify some mandoc -Tlint complaints while here.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

Bump dates on man pages recently updated to mention VM clones.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Pacify some of lint's complaints.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random: suppress another lint warning


distrib/sets/lists/debug/module.md.i386: revision 1.12
sys/dev/acpi/acpi_vmgenid.c: revision 1.1
sys/dev/acpi/acpi_vmgenid.c: revision 1.2
lib/libc/include/reentrant.h: revision 1.22
sys/arch/evbarm/conf/GENERIC64: revision 1.219
share/man/man4/Makefile: revision 1.735
distrib/sets/lists/modules/md.i386: revision 1.100
distrib/sets/lists/tests/mi: revision 1.1334
lib/libc/gen/arc4random.3: revision 1.22
sys/dev/acpi/files.acpi: revision 1.133
lib/libc/gen/arc4random.3: revision 1.23
tests/lib/libc/gen/t_arc4random.c: revision 1.1
sys/sys/entropy.h: revision 1.6
sys/arch/amd64/conf/GENERIC: revision 1.614
sys/modules/acpivmgenid/Makefile: revision 1.1
share/man/man4/acpivmgenid.4: revision 1.1
lib/libc/gen/Makefile.inc: revision 1.220
tests/lib/libc/gen/Makefile: revision 1.56
share/man/man4/acpivmgenid.4: revision 1.2
share/man/man4/acpivmgenid.4: revision 1.3

(all via patch)

Catch up with all the lint warnings since exit on warning was disabled.

Disable 'missing header declaration' and 'nested extern' warnings for now.
acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Factor out subroutines to reset and gather entropy.
`Reset' means we keep the data in the pool, but assume it had zero
entropy. `Gather' means we request samples from all on-demand
sources and wait for the synchronous ones to complete.

No functional change intended, other than to expose new symbols --
just preparation to expose these to acpivmgenid(4), so it can use
these when the VM host notifies us that we, the guest, have been
cloned.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Reset and gather entropy on VM clone notification.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Reseed if system entropy epoch changes.
This can happen, for example, if the system is a VM instance, and the
VM is cloned.

This incurs the cost of a system call on every arc4random call, which
is unfortunate, but
1. we don't currently have a (machine-independent) mechanism for
exposing a read-only page to userland shared by the kernel to
enable a cheaper access path to the entropy epoch; and
2. the algorithm here -- a simple application of ChaCha -- is likely
also a bottleneck and could be much cheaper by
(a) using sys/crypto/chacha for machine-dependent vectorized
ChaCha code, and
(b) filling a buffer (somewhere between a cipher block and a page)
in a batch at a time, instead of running ChaCha to generate
only 32 bytes at a time.
So although this might be a performance hit, the security benefit is
worthwhile and we have a clear path to do better than reversing the
performance hit later.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Nix BUGS that have been squashed.
Reference kern.entropy.epoch for the remaining bug (which is a
performance issue, not a security issue).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Allow unprivileged reads of sysctl kern.entropy.epoch.

Applications need this in order to know when to reseed. (We should
also expose it through a page shared read-only with userland for
cheaper access, but until we do, let's let applications get at it
through sysctl.)
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random.c: Fix test program.

This isn't wired up anywhere, but let's reduce the bitrot. It was
helpful in reminding me that kern.entropy.epoch was, for reasons I
can't remember, restricted to privileged access.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

amd64, evbarm, i386: Add acpivmgenid(4) to GENERIC.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

rnd(4): Document kern.entropy.epoch is unprivileged and elaborate.
Cross-reference acpivmgenid(4).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Note that arc4random respects kern.entropy.epoch.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork
Add debug info for new acpivmgenid module

arc4random(3): Add automatic tests.

This verifies that:
- arc4random zeroes its state and reseeds itself on fork
- arc4random reseeds itself on entropy consolidation (e.g., VM clone)
- arc4random falls back to global state if it can't allocate local
state because address space limits cause mmap to fail

NOTE: This adds a new libc symbol __arc4random_global, but it's in
the reserved namespace and only used by t_arc4random, so no libc
minor bump.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

getentropy(3): Note intent to reseed on VM clone, and caveats.

Tidy markup and pacify some mandoc -Tlint complaints while here.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

Bump dates on man pages recently updated to mention VM clones.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Pacify some of lint's complaints.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random: suppress another lint warning

  /src/lib/libc/gen/
arc4random.3 1.21.24.1 Wed Oct 09 13:25:10 UTC 2024 martin Pull up following revision(s) (requested by riastradh in ticket #939):

distrib/sets/lists/debug/module.md.amd64: revision 1.18
sys/modules/Makefile: revision 1.292
lib/libc/gen/arc4random.c: revision 1.34
lib/libc/gen/arc4random.c: revision 1.35
lib/libc/gen/arc4random.c: revision 1.36
lib/libc/gen/arc4random.c: revision 1.37
sys/kern/kern_entropy.c: revision 1.70
lib/libc/gen/arc4random.c: revision 1.38
sys/kern/kern_entropy.c: revision 1.71
lib/libc/gen/getentropy.3: revision 1.8
distrib/sets/lists/modules/md.amd64: revision 1.103
share/man/man4/rnd.4: revision 1.42
share/man/man4/rnd.4: revision 1.44
lib/libc/include/arc4random.h: revision 1.1
distrib/sets/lists/man/mi: revision 1.1786
sys/arch/i386/conf/GENERIC: revision 1.1258
sys/modules/acpivmgenid/acpivmgenid.ioconf: revision 1.1
sys/arch/amd64/conf/ALL: revision 1.190
distrib/sets/lists/debug/mi: revision 1.446
sys/arch/i386/conf/ALL: revision 1.521
lib/libc/gen/Makefile.inc: revision 1.219
distrib/sets/lists/debug/module.md.i386: revision 1.12
sys/dev/acpi/acpi_vmgenid.c: revision 1.1
sys/dev/acpi/acpi_vmgenid.c: revision 1.2
lib/libc/include/reentrant.h: revision 1.22
sys/arch/evbarm/conf/GENERIC64: revision 1.219
share/man/man4/Makefile: revision 1.735
distrib/sets/lists/modules/md.i386: revision 1.100
distrib/sets/lists/tests/mi: revision 1.1334
lib/libc/gen/arc4random.3: revision 1.22
sys/dev/acpi/files.acpi: revision 1.133
lib/libc/gen/arc4random.3: revision 1.23
tests/lib/libc/gen/t_arc4random.c: revision 1.1
sys/sys/entropy.h: revision 1.6
sys/arch/amd64/conf/GENERIC: revision 1.614
sys/modules/acpivmgenid/Makefile: revision 1.1
share/man/man4/acpivmgenid.4: revision 1.1
lib/libc/gen/Makefile.inc: revision 1.220
tests/lib/libc/gen/Makefile: revision 1.56
share/man/man4/acpivmgenid.4: revision 1.2
share/man/man4/acpivmgenid.4: revision 1.3

(all via patch)

Catch up with all the lint warnings since exit on warning was disabled.

Disable 'missing header declaration' and 'nested extern' warnings for now.
acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Factor out subroutines to reset and gather entropy.
`Reset' means we keep the data in the pool, but assume it had zero
entropy. `Gather' means we request samples from all on-demand
sources and wait for the synchronous ones to complete.

No functional change intended, other than to expose new symbols --
just preparation to expose these to acpivmgenid(4), so it can use
these when the VM host notifies us that we, the guest, have been
cloned.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Reset and gather entropy on VM clone notification.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Reseed if system entropy epoch changes.
This can happen, for example, if the system is a VM instance, and the
VM is cloned.

This incurs the cost of a system call on every arc4random call, which
is unfortunate, but
1. we don't currently have a (machine-independent) mechanism for
exposing a read-only page to userland shared by the kernel to
enable a cheaper access path to the entropy epoch; and
2. the algorithm here -- a simple application of ChaCha -- is likely
also a bottleneck and could be much cheaper by
(a) using sys/crypto/chacha for machine-dependent vectorized
ChaCha code, and
(b) filling a buffer (somewhere between a cipher block and a page)
in a batch at a time, instead of running ChaCha to generate
only 32 bytes at a time.
So although this might be a performance hit, the security benefit is
worthwhile and we have a clear path to do better than reversing the
performance hit later.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Nix BUGS that have been squashed.
Reference kern.entropy.epoch for the remaining bug (which is a
performance issue, not a security issue).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Allow unprivileged reads of sysctl kern.entropy.epoch.

Applications need this in order to know when to reseed. (We should
also expose it through a page shared read-only with userland for
cheaper access, but until we do, let's let applications get at it
through sysctl.)
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random.c: Fix test program.

This isn't wired up anywhere, but let's reduce the bitrot. It was
helpful in reminding me that kern.entropy.epoch was, for reasons I
can't remember, restricted to privileged access.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

amd64, evbarm, i386: Add acpivmgenid(4) to GENERIC.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

rnd(4): Document kern.entropy.epoch is unprivileged and elaborate.
Cross-reference acpivmgenid(4).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Note that arc4random respects kern.entropy.epoch.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork
Add debug info for new acpivmgenid module

arc4random(3): Add automatic tests.

This verifies that:
- arc4random zeroes its state and reseeds itself on fork
- arc4random reseeds itself on entropy consolidation (e.g., VM clone)
- arc4random falls back to global state if it can't allocate local
state because address space limits cause mmap to fail

NOTE: This adds a new libc symbol __arc4random_global, but it's in
the reserved namespace and only used by t_arc4random, so no libc
minor bump.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

getentropy(3): Note intent to reseed on VM clone, and caveats.

Tidy markup and pacify some mandoc -Tlint complaints while here.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

Bump dates on man pages recently updated to mention VM clones.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Pacify some of lint's complaints.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random: suppress another lint warning


distrib/sets/lists/debug/module.md.i386: revision 1.12
sys/dev/acpi/acpi_vmgenid.c: revision 1.1
sys/dev/acpi/acpi_vmgenid.c: revision 1.2
lib/libc/include/reentrant.h: revision 1.22
sys/arch/evbarm/conf/GENERIC64: revision 1.219
share/man/man4/Makefile: revision 1.735
distrib/sets/lists/modules/md.i386: revision 1.100
distrib/sets/lists/tests/mi: revision 1.1334
lib/libc/gen/arc4random.3: revision 1.22
sys/dev/acpi/files.acpi: revision 1.133
lib/libc/gen/arc4random.3: revision 1.23
tests/lib/libc/gen/t_arc4random.c: revision 1.1
sys/sys/entropy.h: revision 1.6
sys/arch/amd64/conf/GENERIC: revision 1.614
sys/modules/acpivmgenid/Makefile: revision 1.1
share/man/man4/acpivmgenid.4: revision 1.1
lib/libc/gen/Makefile.inc: revision 1.220
tests/lib/libc/gen/Makefile: revision 1.56
share/man/man4/acpivmgenid.4: revision 1.2
share/man/man4/acpivmgenid.4: revision 1.3

(all via patch)

Catch up with all the lint warnings since exit on warning was disabled.

Disable 'missing header declaration' and 'nested extern' warnings for now.
acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Factor out subroutines to reset and gather entropy.
`Reset' means we keep the data in the pool, but assume it had zero
entropy. `Gather' means we request samples from all on-demand
sources and wait for the synchronous ones to complete.

No functional change intended, other than to expose new symbols --
just preparation to expose these to acpivmgenid(4), so it can use
these when the VM host notifies us that we, the guest, have been
cloned.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Reset and gather entropy on VM clone notification.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Reseed if system entropy epoch changes.
This can happen, for example, if the system is a VM instance, and the
VM is cloned.

This incurs the cost of a system call on every arc4random call, which
is unfortunate, but
1. we don't currently have a (machine-independent) mechanism for
exposing a read-only page to userland shared by the kernel to
enable a cheaper access path to the entropy epoch; and
2. the algorithm here -- a simple application of ChaCha -- is likely
also a bottleneck and could be much cheaper by
(a) using sys/crypto/chacha for machine-dependent vectorized
ChaCha code, and
(b) filling a buffer (somewhere between a cipher block and a page)
in a batch at a time, instead of running ChaCha to generate
only 32 bytes at a time.
So although this might be a performance hit, the security benefit is
worthwhile and we have a clear path to do better than reversing the
performance hit later.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Nix BUGS that have been squashed.
Reference kern.entropy.epoch for the remaining bug (which is a
performance issue, not a security issue).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Allow unprivileged reads of sysctl kern.entropy.epoch.

Applications need this in order to know when to reseed. (We should
also expose it through a page shared read-only with userland for
cheaper access, but until we do, let's let applications get at it
through sysctl.)
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random.c: Fix test program.

This isn't wired up anywhere, but let's reduce the bitrot. It was
helpful in reminding me that kern.entropy.epoch was, for reasons I
can't remember, restricted to privileged access.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

amd64, evbarm, i386: Add acpivmgenid(4) to GENERIC.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

rnd(4): Document kern.entropy.epoch is unprivileged and elaborate.
Cross-reference acpivmgenid(4).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Note that arc4random respects kern.entropy.epoch.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork
Add debug info for new acpivmgenid module

arc4random(3): Add automatic tests.

This verifies that:
- arc4random zeroes its state and reseeds itself on fork
- arc4random reseeds itself on entropy consolidation (e.g., VM clone)
- arc4random falls back to global state if it can't allocate local
state because address space limits cause mmap to fail

NOTE: This adds a new libc symbol __arc4random_global, but it's in
the reserved namespace and only used by t_arc4random, so no libc
minor bump.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

getentropy(3): Note intent to reseed on VM clone, and caveats.

Tidy markup and pacify some mandoc -Tlint complaints while here.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

Bump dates on man pages recently updated to mention VM clones.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Pacify some of lint's complaints.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random: suppress another lint warning

  /src/sys/arch/amd64/conf/
std.amd64 1.11.20.1 Sat May 13 11:45:53 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #1632):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28 (via patch)
share/man/man8/man8.x86/boot.8: revision 1.29 (via patch)
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.

Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.

Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

1.12.20.1 Sat May 13 13:26:57 UTC 2023 martin Pull up following revision(s) (requested by manu in ticket #159):

share/man/man8/man8.x86/boot.8: revision 1.27
sys/arch/i386/stand/efiboot/version: revision 1.3
share/man/man8/man8.x86/boot.8: revision 1.28
share/man/man8/man8.x86/boot.8: revision 1.29
sys/arch/i386/stand/lib/exec.c: revision 1.79
sys/arch/i386/stand/efiboot/efiboot.c: revision 1.13
sys/arch/i386/stand/efiboot/bootx64/efibootx64.c: revision 1.6
sys/arch/i386/stand/efiboot/bootia32/efibootia32.c: revision 1.6
sys/arch/i386/stand/efiboot/boot.c: revision 1.22
sys/arch/amd64/amd64/locore.S: revision 1.219
sys/arch/i386/stand/efiboot/bootia32/startprog32.S: revision 1.3
sys/arch/i386/stand/efiboot/efiboot.h: revision 1.12
sys/arch/amd64/conf/files.amd64: revision 1.121
sys/arch/amd64/conf/std.amd64: revision 1.13
share/man/man8/man8.x86/pxeboot.8: revision 1.6
sys/arch/i386/stand/efiboot/bootx64/startprog64.S: revision 1.4
sys/arch/amd64/amd64/locore.S: revision 1.220
share/man/man8/man8.x86/dosboot.8: revision 1.4
share/man/man4/options.4: revision 1.524

Add reloc keyworkd to let EFI bootstrap load amd64 kernel at any address

EFI bootstrap assumes it can copy the amd64 kernel to its ELF load
address (that is KERNTEXTOFF - KERNBASE = 0x200000), but it can
clash with previous UEFI memory allocation, as described here:
http://mail-index.netbsd.org/tech-kern/2023/04/07/msg028833.html

This change adds a reloc keyword for controling where the EFI
boostrap will copy the kernel image. Possible values are:
default - the default and prior behavior, copy at 0x200000.
none - do not copy and use the kernel image where it was loaded.
address - specify an explicit address where to copy the kernel.

This comes with an amd64 kernel patch that makes it self-relocatable.
It first discover where it was loaded in memory, and if this is
different than the expected 0x200000, hhe the kernel relocates
itself and start over at the right address.


Merge x86 boot options in x86/boot(8) and add undocumented UEFI options

We were supposed to keep the option list in x86/boot(8), x86/dosoot(8)
and x86/pxeboot(8) in sync, but it did not happen, hence it may work
better with all the options in x86/boot(8). Also add the undocumented
UEFI boot options.


Add a SELFRELOC kernel option for the sake of documentation clarity.
Instead of telling that x86/boot(8) reloc command needs a kernel able
to self relocate, we can tell it needs a kernel built with the
SELFRELOC option. This keeps the reader from wondering what could
make a kernel able to self relocate.

Remove XXX todo marker left by mistake

Raise the version for new feature (here reloc command)
Suggested by Masanobu SAITOH

  /src/sys/rump/net/lib/libnetinet/
netinet_component.c 1.8.6.2 Mon Feb 26 13:32:01 UTC 2018 martin Pull up following revision(s) (requested by ozaki-r in ticket #588):
sys/netinet6/in6.c: revision 1.260
sys/netinet/in.c: revision 1.219
sys/netinet/wqinput.c: revision 1.4
sys/rump/net/lib/libnetinet/netinet_component.c: revision 1.11
sys/netinet/ip_input.c: revision 1.376
sys/netinet6/ip6_input.c: revision 1.193
Avoid a deadlock between softnet_lock and IFNET_LOCK

A deadlock occurs because there is a violation of the rule of lock ordering;
softnet_lock is held with hodling IFNET_LOCK, which violates the rule.
To avoid the deadlock, replace softnet_lock in in_control and in6_control
with KERNEL_LOCK.

We also need to add some KERNEL_LOCKs to protect the network stack surely.
This is required, for example, for PR kern/51356.

Fix PR kern/53043

1.8.6.1 Tue Jan 02 10:20:34 UTC 2018 snj Pull up following revision(s) (requested by ozaki-r in ticket #456):
sys/arch/arm/sunxi/sunxi_emac.c: 1.9
sys/dev/ic/dwc_gmac.c: 1.43-1.44
sys/dev/pci/if_iwm.c: 1.75
sys/dev/pci/if_wm.c: 1.543
sys/dev/pci/ixgbe/ixgbe.c: 1.112
sys/dev/pci/ixgbe/ixv.c: 1.74
sys/kern/sys_socket.c: 1.75
sys/net/agr/if_agr.c: 1.43
sys/net/bpf.c: 1.219
sys/net/if.c: 1.397, 1.399, 1.401-1.403, 1.406-1.410, 1.412-1.416
sys/net/if.h: 1.242-1.247, 1.250, 1.252-1.257
sys/net/if_bridge.c: 1.140 via patch, 1.142-1.146
sys/net/if_etherip.c: 1.40
sys/net/if_ethersubr.c: 1.243, 1.246
sys/net/if_faith.c: 1.57
sys/net/if_gif.c: 1.132
sys/net/if_l2tp.c: 1.15, 1.17
sys/net/if_loop.c: 1.98-1.101
sys/net/if_media.c: 1.35
sys/net/if_pppoe.c: 1.131-1.132
sys/net/if_spppsubr.c: 1.176-1.177
sys/net/if_tun.c: 1.142
sys/net/if_vlan.c: 1.107, 1.109, 1.114-1.121
sys/net/npf/npf_ifaddr.c: 1.3
sys/net/npf/npf_os.c: 1.8-1.9
sys/net/rtsock.c: 1.230
sys/netcan/if_canloop.c: 1.3-1.5
sys/netinet/if_arp.c: 1.255
sys/netinet/igmp.c: 1.65
sys/netinet/in.c: 1.210-1.211
sys/netinet/in_pcb.c: 1.180
sys/netinet/ip_carp.c: 1.92, 1.94
sys/netinet/ip_flow.c: 1.81
sys/netinet/ip_input.c: 1.362
sys/netinet/ip_mroute.c: 1.147
sys/netinet/ip_output.c: 1.283, 1.285, 1.287
sys/netinet6/frag6.c: 1.61
sys/netinet6/in6.c: 1.251, 1.255
sys/netinet6/in6_pcb.c: 1.162
sys/netinet6/ip6_flow.c: 1.35
sys/netinet6/ip6_input.c: 1.183
sys/netinet6/ip6_output.c: 1.196
sys/netinet6/mld6.c: 1.90
sys/netinet6/nd6.c: 1.239-1.240
sys/netinet6/nd6_nbr.c: 1.139
sys/netinet6/nd6_rtr.c: 1.136
sys/netipsec/ipsec_output.c: 1.65
sys/rump/net/lib/libnetinet/netinet_component.c: 1.9-1.10
kmem_intr_free kmem_intr_[z]alloced memory
the underlying pools are the same but api-wise those should match
Unify IFEF_*_MPSAFE into IFEF_MPSAFE
There are already two flags for if_output and if_start, however, it seems such
MPSAFE flags are eventually needed for all if_XXX operations. Having discrete
flags for each operation is wasteful of if_extflags bits. So let's unify
the flags into one: IFEF_MPSAFE.
Fortunately IFEF_*_MPSAFE flags have never been included in any releases, so
we can change them without breaking backward compatibility of the releases
(though the kernel version of -current should be bumped).
Note that if an interface have both MP-safe and non-MP-safe operations at a
time, we have to set the IFEF_MPSAFE flag and let callees of non-MP-safe
opeartions take the kernel lock.
Proposed on tech-kern@ and tech-net@
Provide macros for softnet_lock and KERNEL_LOCK hiding NET_MPSAFE switch
It reduces C&P codes such as "#ifndef NET_MPSAFE KERNEL_LOCK(1, NULL); ..."
scattered all over the source code and makes it easy to identify remaining
KERNEL_LOCK and/or softnet_lock that are held even if NET_MPSAFE.
No functional change
Hold KERNEL_LOCK on if_ioctl selectively based on IFEF_MPSAFE
If IFEF_MPSAFE is set, hold the lock and otherwise don't hold.
This change requires additions of KERNEL_LOCK to subsequence functions from
if_ioctl such as ifmedia_ioctl and ifioctl_common to protect non-MP-safe
components.
Proposed on tech-kern@ and tech-net@
Ensure to hold if_ioctl_lock when calling if_flags_set
Fix locking against myself on ifpromisc
vlan_unconfig_locked could be called with holding if_ioctl_lock.
Ensure to not turn on IFF_RUNNING of an interface until its initialization completes
And ensure to turn off it before destruction as per IFF_RUNNING's description
"resource allocated". (The description is a bit doubtful though, I believe the
change is still proper.)
Ensure to hold if_ioctl_lock on if_up and if_down
One exception for if_down is if_detach; in the case the lock isn't needed
because it's guaranteed that no other one can access ifp at that point.
Make if_link_queue MP-safe if IFEF_MPSAFE
if_link_queue is a queue to store events of link state changes, which is
used to pass events from (typically) an interrupt handler to
if_link_state_change softint. The queue was protected by KERNEL_LOCK so far,
but if IFEF_MPSAFE is enabled, it becomes unsafe because (perhaps) an interrupt
handler of an interface with IFEF_MPSAFE doesn't take KERNEL_LOCK. Protect it
by a spin mutex.
Additionally with this change KERNEL_LOCK of if_link_state_change softint is
omitted if NET_MPSAFE is enabled.
Note that the spin mutex is now ifp->if_snd.ifq_lock as well as the case of
if_timer (see the comment).
Use IFADDR_WRITER_FOREACH instead of IFADDR_READER_FOREACH
At that point no other one modifies the list so IFADDR_READER_FOREACH
is unnecessary. Use of IFADDR_READER_FOREACH is harmless in general though,
if we try to detect contract violations of pserialize, using it violates
the contract. So avoid using it makes life easy.
Ensure to call if_addr_init with holding if_ioctl_lock
Get rid of outdated comments
Fix build of kernels without ether
By throwing out if_enable_vlan_mtu and if_disable_vlan_mtu that
created a unnecessary dependency from if.c to if_ethersubr.c.
PR kern/52790
Rename IFNET_LOCK to IFNET_GLOBAL_LOCK
IFNET_LOCK will be used in another lock, if_ioctl_lock (might be renamed then).
Wrap if_ioctl_lock with IFNET_* macros (NFC)
Also if_ioctl_lock perhaps needs to be renamed to something because it's now
not just for ioctl...
Reorder some destruction routines in if_detach
- Destroy if_ioctl_lock at the end of the if_detach because it's used in various
destruction routines
- Move psref_target_destroy after pr_purgeif because we want to use psref in
pr_purgeif (otherwise destruction procedures can be tricky)
Ensure to call if_mcast_op with holding IFNET_LOCK
Note that CARP doesn't deal with IFNET_LOCK yet.
Remove IFNET_GLOBAL_LOCK where it's unnecessary because IFNET_LOCK is held
Describe which lock is used to protect each member variable of struct ifnet
Requested by skrll@
Write a guideline for converting an interface to IFEF_MPSAFE
Requested by skrll@
Note that IFNET_LOCK must not be held in softint
Don't set IFEF_MPSAFE unless NET_MPSAFE at this point
Because recent investigations show that interfaces with IFEF_MPSAFE need to
follow additional restrictions to work with the flag safely. We should enable it
on an interface by default only if the interface surely satisfies the
restrictions, which are described in if.h.
Note that enabling IFEF_MPSAFE solely gains a few benefit on performance because
the network stack is still serialized by the big kernel locks by default.

  /src/tests/lib/libc/gen/
t_arc4random.c 1.1.2.2 Wed Oct 09 13:25:13 UTC 2024 martin Pull up following revision(s) (requested by riastradh in ticket #939):

distrib/sets/lists/debug/module.md.amd64: revision 1.18
sys/modules/Makefile: revision 1.292
lib/libc/gen/arc4random.c: revision 1.34
lib/libc/gen/arc4random.c: revision 1.35
lib/libc/gen/arc4random.c: revision 1.36
lib/libc/gen/arc4random.c: revision 1.37
sys/kern/kern_entropy.c: revision 1.70
lib/libc/gen/arc4random.c: revision 1.38
sys/kern/kern_entropy.c: revision 1.71
lib/libc/gen/getentropy.3: revision 1.8
distrib/sets/lists/modules/md.amd64: revision 1.103
share/man/man4/rnd.4: revision 1.42
share/man/man4/rnd.4: revision 1.44
lib/libc/include/arc4random.h: revision 1.1
distrib/sets/lists/man/mi: revision 1.1786
sys/arch/i386/conf/GENERIC: revision 1.1258
sys/modules/acpivmgenid/acpivmgenid.ioconf: revision 1.1
sys/arch/amd64/conf/ALL: revision 1.190
distrib/sets/lists/debug/mi: revision 1.446
sys/arch/i386/conf/ALL: revision 1.521
lib/libc/gen/Makefile.inc: revision 1.219
distrib/sets/lists/debug/module.md.i386: revision 1.12
sys/dev/acpi/acpi_vmgenid.c: revision 1.1
sys/dev/acpi/acpi_vmgenid.c: revision 1.2
lib/libc/include/reentrant.h: revision 1.22
sys/arch/evbarm/conf/GENERIC64: revision 1.219
share/man/man4/Makefile: revision 1.735
distrib/sets/lists/modules/md.i386: revision 1.100
distrib/sets/lists/tests/mi: revision 1.1334
lib/libc/gen/arc4random.3: revision 1.22
sys/dev/acpi/files.acpi: revision 1.133
lib/libc/gen/arc4random.3: revision 1.23
tests/lib/libc/gen/t_arc4random.c: revision 1.1
sys/sys/entropy.h: revision 1.6
sys/arch/amd64/conf/GENERIC: revision 1.614
sys/modules/acpivmgenid/Makefile: revision 1.1
share/man/man4/acpivmgenid.4: revision 1.1
lib/libc/gen/Makefile.inc: revision 1.220
tests/lib/libc/gen/Makefile: revision 1.56
share/man/man4/acpivmgenid.4: revision 1.2
share/man/man4/acpivmgenid.4: revision 1.3

(all via patch)

Catch up with all the lint warnings since exit on warning was disabled.

Disable 'missing header declaration' and 'nested extern' warnings for now.
acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Factor out subroutines to reset and gather entropy.
`Reset' means we keep the data in the pool, but assume it had zero
entropy. `Gather' means we request samples from all on-demand
sources and wait for the synchronous ones to complete.

No functional change intended, other than to expose new symbols --
just preparation to expose these to acpivmgenid(4), so it can use
these when the VM host notifies us that we, the guest, have been
cloned.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Reset and gather entropy on VM clone notification.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Reseed if system entropy epoch changes.
This can happen, for example, if the system is a VM instance, and the
VM is cloned.

This incurs the cost of a system call on every arc4random call, which
is unfortunate, but
1. we don't currently have a (machine-independent) mechanism for
exposing a read-only page to userland shared by the kernel to
enable a cheaper access path to the entropy epoch; and
2. the algorithm here -- a simple application of ChaCha -- is likely
also a bottleneck and could be much cheaper by
(a) using sys/crypto/chacha for machine-dependent vectorized
ChaCha code, and
(b) filling a buffer (somewhere between a cipher block and a page)
in a batch at a time, instead of running ChaCha to generate
only 32 bytes at a time.
So although this might be a performance hit, the security benefit is
worthwhile and we have a clear path to do better than reversing the
performance hit later.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Nix BUGS that have been squashed.
Reference kern.entropy.epoch for the remaining bug (which is a
performance issue, not a security issue).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Allow unprivileged reads of sysctl kern.entropy.epoch.

Applications need this in order to know when to reseed. (We should
also expose it through a page shared read-only with userland for
cheaper access, but until we do, let's let applications get at it
through sysctl.)
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random.c: Fix test program.

This isn't wired up anywhere, but let's reduce the bitrot. It was
helpful in reminding me that kern.entropy.epoch was, for reasons I
can't remember, restricted to privileged access.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

amd64, evbarm, i386: Add acpivmgenid(4) to GENERIC.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

rnd(4): Document kern.entropy.epoch is unprivileged and elaborate.
Cross-reference acpivmgenid(4).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Note that arc4random respects kern.entropy.epoch.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork
Add debug info for new acpivmgenid module

arc4random(3): Add automatic tests.

This verifies that:
- arc4random zeroes its state and reseeds itself on fork
- arc4random reseeds itself on entropy consolidation (e.g., VM clone)
- arc4random falls back to global state if it can't allocate local
state because address space limits cause mmap to fail

NOTE: This adds a new libc symbol __arc4random_global, but it's in
the reserved namespace and only used by t_arc4random, so no libc
minor bump.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

getentropy(3): Note intent to reseed on VM clone, and caveats.

Tidy markup and pacify some mandoc -Tlint complaints while here.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

Bump dates on man pages recently updated to mention VM clones.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Pacify some of lint's complaints.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random: suppress another lint warning

distrib/sets/lists/debug/module.md.i386: revision 1.12
sys/dev/acpi/acpi_vmgenid.c: revision 1.1
sys/dev/acpi/acpi_vmgenid.c: revision 1.2
lib/libc/include/reentrant.h: revision 1.22
sys/arch/evbarm/conf/GENERIC64: revision 1.219
share/man/man4/Makefile: revision 1.735
distrib/sets/lists/modules/md.i386: revision 1.100
distrib/sets/lists/tests/mi: revision 1.1334
lib/libc/gen/arc4random.3: revision 1.22
sys/dev/acpi/files.acpi: revision 1.133
lib/libc/gen/arc4random.3: revision 1.23
tests/lib/libc/gen/t_arc4random.c: revision 1.1
sys/sys/entropy.h: revision 1.6
sys/arch/amd64/conf/GENERIC: revision 1.614
sys/modules/acpivmgenid/Makefile: revision 1.1
share/man/man4/acpivmgenid.4: revision 1.1
lib/libc/gen/Makefile.inc: revision 1.220
tests/lib/libc/gen/Makefile: revision 1.56
share/man/man4/acpivmgenid.4: revision 1.2
share/man/man4/acpivmgenid.4: revision 1.3

(all via patch)

Catch up with all the lint warnings since exit on warning was disabled.

Disable 'missing header declaration' and 'nested extern' warnings for now.
acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Factor out subroutines to reset and gather entropy.
`Reset' means we keep the data in the pool, but assume it had zero
entropy. `Gather' means we request samples from all on-demand
sources and wait for the synchronous ones to complete.

No functional change intended, other than to expose new symbols --
just preparation to expose these to acpivmgenid(4), so it can use
these when the VM host notifies us that we, the guest, have been
cloned.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Reset and gather entropy on VM clone notification.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Reseed if system entropy epoch changes.
This can happen, for example, if the system is a VM instance, and the
VM is cloned.

This incurs the cost of a system call on every arc4random call, which
is unfortunate, but
1. we don't currently have a (machine-independent) mechanism for
exposing a read-only page to userland shared by the kernel to
enable a cheaper access path to the entropy epoch; and
2. the algorithm here -- a simple application of ChaCha -- is likely
also a bottleneck and could be much cheaper by
(a) using sys/crypto/chacha for machine-dependent vectorized
ChaCha code, and
(b) filling a buffer (somewhere between a cipher block and a page)
in a batch at a time, instead of running ChaCha to generate
only 32 bytes at a time.
So although this might be a performance hit, the security benefit is
worthwhile and we have a clear path to do better than reversing the
performance hit later.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Nix BUGS that have been squashed.
Reference kern.entropy.epoch for the remaining bug (which is a
performance issue, not a security issue).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Allow unprivileged reads of sysctl kern.entropy.epoch.

Applications need this in order to know when to reseed. (We should
also expose it through a page shared read-only with userland for
cheaper access, but until we do, let's let applications get at it
through sysctl.)
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random.c: Fix test program.

This isn't wired up anywhere, but let's reduce the bitrot. It was
helpful in reminding me that kern.entropy.epoch was, for reasons I
can't remember, restricted to privileged access.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

amd64, evbarm, i386: Add acpivmgenid(4) to GENERIC.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

rnd(4): Document kern.entropy.epoch is unprivileged and elaborate.
Cross-reference acpivmgenid(4).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Note that arc4random respects kern.entropy.epoch.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork
Add debug info for new acpivmgenid module

arc4random(3): Add automatic tests.

This verifies that:
- arc4random zeroes its state and reseeds itself on fork
- arc4random reseeds itself on entropy consolidation (e.g., VM clone)
- arc4random falls back to global state if it can't allocate local
state because address space limits cause mmap to fail

NOTE: This adds a new libc symbol __arc4random_global, but it's in
the reserved namespace and only used by t_arc4random, so no libc
minor bump.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

getentropy(3): Note intent to reseed on VM clone, and caveats.

Tidy markup and pacify some mandoc -Tlint complaints while here.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

Bump dates on man pages recently updated to mention VM clones.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Pacify some of lint's complaints.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random: suppress another lint warning
  /src/sys/compat/linux/common/
linux_misc.c 1.219 Fri Oct 14 09:23:28 UTC 2011 hannken branches: 1.219.2; 1.219.8; 1.219.12; 1.219.14; 1.219.16;
Change the vnode locking protocol of VOP_GETATTR() to request at least
a shared lock. Make all calls outside of file systems respect it.

The calls from file systems need review.

No objections from tech-kern.
Fri Oct 14 09:23:28 UTC 2011 hannken branches: 1.219.2; 1.219.8; 1.219.12; 1.219.14; 1.219.16;
Change the vnode locking protocol of VOP_GETATTR() to request at least
a shared lock. Make all calls outside of file systems respect it.

The calls from file systems need review.

No objections from tech-kern.
.2; 1.219.8; 1.219.12; 1.219.14; 1.219.16;
Change the vnode locking protocol of VOP_GETATTR() to request at least
a shared lock. Make all calls outside of file systems respect it.

The calls from file systems need review.

No objections from tech-kern.
.8; 1.219.12; 1.219.14; 1.219.16;
Change the vnode locking protocol of VOP_GETATTR() to request at least
a shared lock. Make all calls outside of file systems respect it.

The calls from file systems need review.

No objections from tech-kern.
.12; 1.219.14; 1.219.16;
Change the vnode locking protocol of VOP_GETATTR() to request at least
a shared lock. Make all calls outside of file systems respect it.

The calls from file systems need review.

No objections from tech-kern.
.14; 1.219.16;
Change the vnode locking protocol of VOP_GETATTR() to request at least
a shared lock. Make all calls outside of file systems respect it.

The calls from file systems need review.

No objections from tech-kern.
1.219.16.1 Sat Aug 19 04:19:58 UTC 2017 snj Pull up following revision(s) (requested by mrg in ticket #1483):
sys/compat/common/vfs_syscalls_12.c: revision 1.34
sys/compat/svr4_32/svr4_32_misc.c: revision 1.78
sys/compat/sunos32/sunos32_misc.c: revision 1.78
sys/compat/linux/common/linux_misc.c: revision 1.239
sys/compat/osf1/osf1_file.c: revision 1.44
sys/compat/common/vfs_syscalls_43.c: revision 1.60
sys/compat/svr4/svr4_misc.c: revision 1.158
sys/compat/ibcs2/ibcs2_misc.c: revision 1.114
sys/compat/linux/common/linux_file64.c: revision 1.59
sys/compat/linux32/common/linux32_dirent.c: revision 1.18
sys/compat/sunos/sunos_misc.c: revision 1.171
Fail, don't panic, on bad dirents from file system.
Controllable via puffs from userland.
From Ilja Van Sprundel.
1.219.14.1 Sat Aug 19 04:19:55 UTC 2017 snj Pull up following revision(s) (requested by mrg in ticket #1483):
sys/compat/common/vfs_syscalls_12.c: revision 1.34
sys/compat/svr4_32/svr4_32_misc.c: revision 1.78
sys/compat/sunos32/sunos32_misc.c: revision 1.78
sys/compat/linux/common/linux_misc.c: revision 1.239
sys/compat/osf1/osf1_file.c: revision 1.44
sys/compat/common/vfs_syscalls_43.c: revision 1.60
sys/compat/svr4/svr4_misc.c: revision 1.158
sys/compat/ibcs2/ibcs2_misc.c: revision 1.114
sys/compat/linux/common/linux_file64.c: revision 1.59
sys/compat/linux32/common/linux32_dirent.c: revision 1.18
sys/compat/sunos/sunos_misc.c: revision 1.171
Fail, don't panic, on bad dirents from file system.
Controllable via puffs from userland.
From Ilja Van Sprundel.
1.219.12.4 Sun Dec 03 11:36:55 UTC 2017 jdolecek update from HEAD
1.219.12.3 Wed Aug 20 00:03:32 UTC 2014 tls Rebase to HEAD as of a few days ago.
  /src/sys/ufs/lfs/
ulfs_dirhash.c 1.16 Mon Jun 20 00:00:47 UTC 2016 dholland More already-merged or equivalent changes:

ufs_dirhash.c 1.36 corresponds to ulfs_dirhash.c 1.8
ufs_extattr.c 1.43 corresponds to ulfs_extattr.c 1.7
ufs_lookup.c 1.126 does not apply to lfs
ufs_lookup.c 1.127 we already have
ufs_lookup.c 1.128 does not apply to lfs
ufs_lookup.c 1.129 corresponds to ulfs_lookup.c 1.19
ufs_quota1.c 1.19 corresponds to ulfs_quota1.c 1.7
ufs_quota1.c 1.20 corresponds to ulfs_quota1.c 1.8
ufs_quota2.c 1.36 we have equivalent changes for
ufs_rename.c 1.9 corresponds to lfs_rename.c 1.5
ufs_rename.c 1.10 corresponds to lfs_rename.c 1.6
ufs_vnops.c 1.219 corresponds to lfs_vnops.c 1.260 and ulfs_vnops.c 1.19
ufs_vnops.c 1.220 corresponds to lfs_vnops.c 1.261 and ulfs_vnops.c 1.20
ufs_vnops.c 1.221 was superseded by later changes
ufs_vnops.c 1.222 got fixed independently in lfs

ulfs_quota1.c 1.10 Mon Jun 20 00:00:47 UTC 2016 dholland More already-merged or equivalent changes:

ufs_dirhash.c 1.36 corresponds to ulfs_dirhash.c 1.8
ufs_extattr.c 1.43 corresponds to ulfs_extattr.c 1.7
ufs_lookup.c 1.126 does not apply to lfs
ufs_lookup.c 1.127 we already have
ufs_lookup.c 1.128 does not apply to lfs
ufs_lookup.c 1.129 corresponds to ulfs_lookup.c 1.19
ufs_quota1.c 1.19 corresponds to ulfs_quota1.c 1.7
ufs_quota1.c 1.20 corresponds to ulfs_quota1.c 1.8
ufs_quota2.c 1.36 we have equivalent changes for
ufs_rename.c 1.9 corresponds to lfs_rename.c 1.5
ufs_rename.c 1.10 corresponds to lfs_rename.c 1.6
ufs_vnops.c 1.219 corresponds to lfs_vnops.c 1.260 and ulfs_vnops.c 1.19
ufs_vnops.c 1.220 corresponds to lfs_vnops.c 1.261 and ulfs_vnops.c 1.20
ufs_vnops.c 1.221 was superseded by later changes
ufs_vnops.c 1.222 got fixed independently in lfs
  /src/distrib/sets/lists/debug/
module.md.amd64 1.12.2.3 Wed Oct 09 13:25:10 UTC 2024 martin Pull up following revision(s) (requested by riastradh in ticket #939):

distrib/sets/lists/debug/module.md.amd64: revision 1.18
sys/modules/Makefile: revision 1.292
lib/libc/gen/arc4random.c: revision 1.34
lib/libc/gen/arc4random.c: revision 1.35
lib/libc/gen/arc4random.c: revision 1.36
lib/libc/gen/arc4random.c: revision 1.37
sys/kern/kern_entropy.c: revision 1.70
lib/libc/gen/arc4random.c: revision 1.38
sys/kern/kern_entropy.c: revision 1.71
lib/libc/gen/getentropy.3: revision 1.8
distrib/sets/lists/modules/md.amd64: revision 1.103
share/man/man4/rnd.4: revision 1.42
share/man/man4/rnd.4: revision 1.44
lib/libc/include/arc4random.h: revision 1.1
distrib/sets/lists/man/mi: revision 1.1786
sys/arch/i386/conf/GENERIC: revision 1.1258
sys/modules/acpivmgenid/acpivmgenid.ioconf: revision 1.1
sys/arch/amd64/conf/ALL: revision 1.190
distrib/sets/lists/debug/mi: revision 1.446
sys/arch/i386/conf/ALL: revision 1.521
lib/libc/gen/Makefile.inc: revision 1.219
distrib/sets/lists/debug/module.md.i386: revision 1.12
sys/dev/acpi/acpi_vmgenid.c: revision 1.1
sys/dev/acpi/acpi_vmgenid.c: revision 1.2
lib/libc/include/reentrant.h: revision 1.22
sys/arch/evbarm/conf/GENERIC64: revision 1.219
share/man/man4/Makefile: revision 1.735
distrib/sets/lists/modules/md.i386: revision 1.100
distrib/sets/lists/tests/mi: revision 1.1334
lib/libc/gen/arc4random.3: revision 1.22
sys/dev/acpi/files.acpi: revision 1.133
lib/libc/gen/arc4random.3: revision 1.23
tests/lib/libc/gen/t_arc4random.c: revision 1.1
sys/sys/entropy.h: revision 1.6
sys/arch/amd64/conf/GENERIC: revision 1.614
sys/modules/acpivmgenid/Makefile: revision 1.1
share/man/man4/acpivmgenid.4: revision 1.1
lib/libc/gen/Makefile.inc: revision 1.220
tests/lib/libc/gen/Makefile: revision 1.56
share/man/man4/acpivmgenid.4: revision 1.2
share/man/man4/acpivmgenid.4: revision 1.3

(all via patch)

Catch up with all the lint warnings since exit on warning was disabled.

Disable 'missing header declaration' and 'nested extern' warnings for now.
acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Factor out subroutines to reset and gather entropy.
`Reset' means we keep the data in the pool, but assume it had zero
entropy. `Gather' means we request samples from all on-demand
sources and wait for the synchronous ones to complete.

No functional change intended, other than to expose new symbols --
just preparation to expose these to acpivmgenid(4), so it can use
these when the VM host notifies us that we, the guest, have been
cloned.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Reset and gather entropy on VM clone notification.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Reseed if system entropy epoch changes.
This can happen, for example, if the system is a VM instance, and the
VM is cloned.

This incurs the cost of a system call on every arc4random call, which
is unfortunate, but
1. we don't currently have a (machine-independent) mechanism for
exposing a read-only page to userland shared by the kernel to
enable a cheaper access path to the entropy epoch; and
2. the algorithm here -- a simple application of ChaCha -- is likely
also a bottleneck and could be much cheaper by
(a) using sys/crypto/chacha for machine-dependent vectorized
ChaCha code, and
(b) filling a buffer (somewhere between a cipher block and a page)
in a batch at a time, instead of running ChaCha to generate
only 32 bytes at a time.
So although this might be a performance hit, the security benefit is
worthwhile and we have a clear path to do better than reversing the
performance hit later.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Nix BUGS that have been squashed.
Reference kern.entropy.epoch for the remaining bug (which is a
performance issue, not a security issue).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Allow unprivileged reads of sysctl kern.entropy.epoch.

Applications need this in order to know when to reseed. (We should
also expose it through a page shared read-only with userland for
cheaper access, but until we do, let's let applications get at it
through sysctl.)
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random.c: Fix test program.

This isn't wired up anywhere, but let's reduce the bitrot. It was
helpful in reminding me that kern.entropy.epoch was, for reasons I
can't remember, restricted to privileged access.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

amd64, evbarm, i386: Add acpivmgenid(4) to GENERIC.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

rnd(4): Document kern.entropy.epoch is unprivileged and elaborate.
Cross-reference acpivmgenid(4).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Note that arc4random respects kern.entropy.epoch.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork
Add debug info for new acpivmgenid module

arc4random(3): Add automatic tests.

This verifies that:
- arc4random zeroes its state and reseeds itself on fork
- arc4random reseeds itself on entropy consolidation (e.g., VM clone)
- arc4random falls back to global state if it can't allocate local
state because address space limits cause mmap to fail

NOTE: This adds a new libc symbol __arc4random_global, but it's in
the reserved namespace and only used by t_arc4random, so no libc
minor bump.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

getentropy(3): Note intent to reseed on VM clone, and caveats.

Tidy markup and pacify some mandoc -Tlint complaints while here.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

Bump dates on man pages recently updated to mention VM clones.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Pacify some of lint's complaints.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random: suppress another lint warning

distrib/sets/lists/debug/module.md.i386: revision 1.12
sys/dev/acpi/acpi_vmgenid.c: revision 1.1
sys/dev/acpi/acpi_vmgenid.c: revision 1.2
lib/libc/include/reentrant.h: revision 1.22
sys/arch/evbarm/conf/GENERIC64: revision 1.219
share/man/man4/Makefile: revision 1.735
distrib/sets/lists/modules/md.i386: revision 1.100
distrib/sets/lists/tests/mi: revision 1.1334
lib/libc/gen/arc4random.3: revision 1.22
sys/dev/acpi/files.acpi: revision 1.133
lib/libc/gen/arc4random.3: revision 1.23
tests/lib/libc/gen/t_arc4random.c: revision 1.1
sys/sys/entropy.h: revision 1.6
sys/arch/amd64/conf/GENERIC: revision 1.614
sys/modules/acpivmgenid/Makefile: revision 1.1
share/man/man4/acpivmgenid.4: revision 1.1
lib/libc/gen/Makefile.inc: revision 1.220
tests/lib/libc/gen/Makefile: revision 1.56
share/man/man4/acpivmgenid.4: revision 1.2
share/man/man4/acpivmgenid.4: revision 1.3

(all via patch)

Catch up with all the lint warnings since exit on warning was disabled.

Disable 'missing header declaration' and 'nested extern' warnings for now.
acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Factor out subroutines to reset and gather entropy.
`Reset' means we keep the data in the pool, but assume it had zero
entropy. `Gather' means we request samples from all on-demand
sources and wait for the synchronous ones to complete.

No functional change intended, other than to expose new symbols --
just preparation to expose these to acpivmgenid(4), so it can use
these when the VM host notifies us that we, the guest, have been
cloned.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Reset and gather entropy on VM clone notification.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Reseed if system entropy epoch changes.
This can happen, for example, if the system is a VM instance, and the
VM is cloned.

This incurs the cost of a system call on every arc4random call, which
is unfortunate, but
1. we don't currently have a (machine-independent) mechanism for
exposing a read-only page to userland shared by the kernel to
enable a cheaper access path to the entropy epoch; and
2. the algorithm here -- a simple application of ChaCha -- is likely
also a bottleneck and could be much cheaper by
(a) using sys/crypto/chacha for machine-dependent vectorized
ChaCha code, and
(b) filling a buffer (somewhere between a cipher block and a page)
in a batch at a time, instead of running ChaCha to generate
only 32 bytes at a time.
So although this might be a performance hit, the security benefit is
worthwhile and we have a clear path to do better than reversing the
performance hit later.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Nix BUGS that have been squashed.
Reference kern.entropy.epoch for the remaining bug (which is a
performance issue, not a security issue).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Allow unprivileged reads of sysctl kern.entropy.epoch.

Applications need this in order to know when to reseed. (We should
also expose it through a page shared read-only with userland for
cheaper access, but until we do, let's let applications get at it
through sysctl.)
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random.c: Fix test program.

This isn't wired up anywhere, but let's reduce the bitrot. It was
helpful in reminding me that kern.entropy.epoch was, for reasons I
can't remember, restricted to privileged access.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

amd64, evbarm, i386: Add acpivmgenid(4) to GENERIC.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

rnd(4): Document kern.entropy.epoch is unprivileged and elaborate.
Cross-reference acpivmgenid(4).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Note that arc4random respects kern.entropy.epoch.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork
Add debug info for new acpivmgenid module

arc4random(3): Add automatic tests.

This verifies that:
- arc4random zeroes its state and reseeds itself on fork
- arc4random reseeds itself on entropy consolidation (e.g., VM clone)
- arc4random falls back to global state if it can't allocate local
state because address space limits cause mmap to fail

NOTE: This adds a new libc symbol __arc4random_global, but it's in
the reserved namespace and only used by t_arc4random, so no libc
minor bump.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

getentropy(3): Note intent to reseed on VM clone, and caveats.

Tidy markup and pacify some mandoc -Tlint complaints while here.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

Bump dates on man pages recently updated to mention VM clones.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Pacify some of lint's complaints.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random: suppress another lint warning
module.md.i386 1.7.2.3 Wed Oct 09 13:25:10 UTC 2024 martin Pull up following revision(s) (requested by riastradh in ticket #939):

distrib/sets/lists/debug/module.md.amd64: revision 1.18
sys/modules/Makefile: revision 1.292
lib/libc/gen/arc4random.c: revision 1.34
lib/libc/gen/arc4random.c: revision 1.35
lib/libc/gen/arc4random.c: revision 1.36
lib/libc/gen/arc4random.c: revision 1.37
sys/kern/kern_entropy.c: revision 1.70
lib/libc/gen/arc4random.c: revision 1.38
sys/kern/kern_entropy.c: revision 1.71
lib/libc/gen/getentropy.3: revision 1.8
distrib/sets/lists/modules/md.amd64: revision 1.103
share/man/man4/rnd.4: revision 1.42
share/man/man4/rnd.4: revision 1.44
lib/libc/include/arc4random.h: revision 1.1
distrib/sets/lists/man/mi: revision 1.1786
sys/arch/i386/conf/GENERIC: revision 1.1258
sys/modules/acpivmgenid/acpivmgenid.ioconf: revision 1.1
sys/arch/amd64/conf/ALL: revision 1.190
distrib/sets/lists/debug/mi: revision 1.446
sys/arch/i386/conf/ALL: revision 1.521
lib/libc/gen/Makefile.inc: revision 1.219
distrib/sets/lists/debug/module.md.i386: revision 1.12
sys/dev/acpi/acpi_vmgenid.c: revision 1.1
sys/dev/acpi/acpi_vmgenid.c: revision 1.2
lib/libc/include/reentrant.h: revision 1.22
sys/arch/evbarm/conf/GENERIC64: revision 1.219
share/man/man4/Makefile: revision 1.735
distrib/sets/lists/modules/md.i386: revision 1.100
distrib/sets/lists/tests/mi: revision 1.1334
lib/libc/gen/arc4random.3: revision 1.22
sys/dev/acpi/files.acpi: revision 1.133
lib/libc/gen/arc4random.3: revision 1.23
tests/lib/libc/gen/t_arc4random.c: revision 1.1
sys/sys/entropy.h: revision 1.6
sys/arch/amd64/conf/GENERIC: revision 1.614
sys/modules/acpivmgenid/Makefile: revision 1.1
share/man/man4/acpivmgenid.4: revision 1.1
lib/libc/gen/Makefile.inc: revision 1.220
tests/lib/libc/gen/Makefile: revision 1.56
share/man/man4/acpivmgenid.4: revision 1.2
share/man/man4/acpivmgenid.4: revision 1.3

(all via patch)

Catch up with all the lint warnings since exit on warning was disabled.

Disable 'missing header declaration' and 'nested extern' warnings for now.
acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Factor out subroutines to reset and gather entropy.
`Reset' means we keep the data in the pool, but assume it had zero
entropy. `Gather' means we request samples from all on-demand
sources and wait for the synchronous ones to complete.

No functional change intended, other than to expose new symbols --
just preparation to expose these to acpivmgenid(4), so it can use
these when the VM host notifies us that we, the guest, have been
cloned.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Reset and gather entropy on VM clone notification.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Reseed if system entropy epoch changes.
This can happen, for example, if the system is a VM instance, and the
VM is cloned.

This incurs the cost of a system call on every arc4random call, which
is unfortunate, but
1. we don't currently have a (machine-independent) mechanism for
exposing a read-only page to userland shared by the kernel to
enable a cheaper access path to the entropy epoch; and
2. the algorithm here -- a simple application of ChaCha -- is likely
also a bottleneck and could be much cheaper by
(a) using sys/crypto/chacha for machine-dependent vectorized
ChaCha code, and
(b) filling a buffer (somewhere between a cipher block and a page)
in a batch at a time, instead of running ChaCha to generate
only 32 bytes at a time.
So although this might be a performance hit, the security benefit is
worthwhile and we have a clear path to do better than reversing the
performance hit later.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Nix BUGS that have been squashed.
Reference kern.entropy.epoch for the remaining bug (which is a
performance issue, not a security issue).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Allow unprivileged reads of sysctl kern.entropy.epoch.

Applications need this in order to know when to reseed. (We should
also expose it through a page shared read-only with userland for
cheaper access, but until we do, let's let applications get at it
through sysctl.)
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random.c: Fix test program.

This isn't wired up anywhere, but let's reduce the bitrot. It was
helpful in reminding me that kern.entropy.epoch was, for reasons I
can't remember, restricted to privileged access.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

amd64, evbarm, i386: Add acpivmgenid(4) to GENERIC.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

rnd(4): Document kern.entropy.epoch is unprivileged and elaborate.
Cross-reference acpivmgenid(4).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Note that arc4random respects kern.entropy.epoch.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork
Add debug info for new acpivmgenid module

arc4random(3): Add automatic tests.

This verifies that:
- arc4random zeroes its state and reseeds itself on fork
- arc4random reseeds itself on entropy consolidation (e.g., VM clone)
- arc4random falls back to global state if it can't allocate local
state because address space limits cause mmap to fail

NOTE: This adds a new libc symbol __arc4random_global, but it's in
the reserved namespace and only used by t_arc4random, so no libc
minor bump.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

getentropy(3): Note intent to reseed on VM clone, and caveats.

Tidy markup and pacify some mandoc -Tlint complaints while here.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

Bump dates on man pages recently updated to mention VM clones.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Pacify some of lint's complaints.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random: suppress another lint warning

distrib/sets/lists/debug/module.md.i386: revision 1.12
sys/dev/acpi/acpi_vmgenid.c: revision 1.1
sys/dev/acpi/acpi_vmgenid.c: revision 1.2
lib/libc/include/reentrant.h: revision 1.22
sys/arch/evbarm/conf/GENERIC64: revision 1.219
share/man/man4/Makefile: revision 1.735
distrib/sets/lists/modules/md.i386: revision 1.100
distrib/sets/lists/tests/mi: revision 1.1334
lib/libc/gen/arc4random.3: revision 1.22
sys/dev/acpi/files.acpi: revision 1.133
lib/libc/gen/arc4random.3: revision 1.23
tests/lib/libc/gen/t_arc4random.c: revision 1.1
sys/sys/entropy.h: revision 1.6
sys/arch/amd64/conf/GENERIC: revision 1.614
sys/modules/acpivmgenid/Makefile: revision 1.1
share/man/man4/acpivmgenid.4: revision 1.1
lib/libc/gen/Makefile.inc: revision 1.220
tests/lib/libc/gen/Makefile: revision 1.56
share/man/man4/acpivmgenid.4: revision 1.2
share/man/man4/acpivmgenid.4: revision 1.3

(all via patch)

Catch up with all the lint warnings since exit on warning was disabled.

Disable 'missing header declaration' and 'nested extern' warnings for now.
acpivmgenid(4): New driver for virtual machine generation ID.

Added to amd64/ALL and i386/ALL kernel configurations, and made
available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Factor out subroutines to reset and gather entropy.
`Reset' means we keep the data in the pool, but assume it had zero
entropy. `Gather' means we request samples from all on-demand
sources and wait for the synchronous ones to complete.

No functional change intended, other than to expose new symbols --
just preparation to expose these to acpivmgenid(4), so it can use
these when the VM host notifies us that we, the guest, have been
cloned.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Reset and gather entropy on VM clone notification.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Reseed if system entropy epoch changes.
This can happen, for example, if the system is a VM instance, and the
VM is cloned.

This incurs the cost of a system call on every arc4random call, which
is unfortunate, but
1. we don't currently have a (machine-independent) mechanism for
exposing a read-only page to userland shared by the kernel to
enable a cheaper access path to the entropy epoch; and
2. the algorithm here -- a simple application of ChaCha -- is likely
also a bottleneck and could be much cheaper by
(a) using sys/crypto/chacha for machine-dependent vectorized
ChaCha code, and
(b) filling a buffer (somewhere between a cipher block and a page)
in a batch at a time, instead of running ChaCha to generate
only 32 bytes at a time.
So although this might be a performance hit, the security benefit is
worthwhile and we have a clear path to do better than reversing the
performance hit later.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

acpivmgenid(4): Nix BUGS that have been squashed.
Reference kern.entropy.epoch for the remaining bug (which is a
performance issue, not a security issue).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

entropy(9): Allow unprivileged reads of sysctl kern.entropy.epoch.

Applications need this in order to know when to reseed. (We should
also expose it through a page shared read-only with userland for
cheaper access, but until we do, let's let applications get at it
through sysctl.)
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random.c: Fix test program.

This isn't wired up anywhere, but let's reduce the bitrot. It was
helpful in reminding me that kern.entropy.epoch was, for reasons I
can't remember, restricted to privileged access.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

amd64, evbarm, i386: Add acpivmgenid(4) to GENERIC.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

rnd(4): Document kern.entropy.epoch is unprivileged and elaborate.
Cross-reference acpivmgenid(4).
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Note that arc4random respects kern.entropy.epoch.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork
Add debug info for new acpivmgenid module

arc4random(3): Add automatic tests.

This verifies that:
- arc4random zeroes its state and reseeds itself on fork
- arc4random reseeds itself on entropy consolidation (e.g., VM clone)
- arc4random falls back to global state if it can't allocate local
state because address space limits cause mmap to fail

NOTE: This adds a new libc symbol __arc4random_global, but it's in
the reserved namespace and only used by t_arc4random, so no libc
minor bump.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

getentropy(3): Note intent to reseed on VM clone, and caveats.

Tidy markup and pacify some mandoc -Tlint complaints while here.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

Bump dates on man pages recently updated to mention VM clones.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random(3): Pacify some of lint's complaints.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM
fork

arc4random: suppress another lint warning

Completed in 138 milliseconds

1 2 3 4 5 6 7 8 91011>>