nvmecontrol: Always build instead of being conditional on WITH_NVME

This now builds fine on all platforms so always include it similar
to other tools such as camcontrol.

Reviewed by: imp, emaste
Sp

nvmecontrol: Always build instead of being conditional on WITH_NVME

This now builds fine on all platforms so always include it similar
to other tools such as camcontrol.

Reviewed by: imp, emaste
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44842

(cherry picked from commit 2d51a9898e26c87586ba50e71b6b3fdf1591713d)

show more ...

Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

Retire WITHOUT_CXX option

Several important base system components are written in C++, and the
WITHOUT_CXX option produced a system that was not fully functional.
Just accept this, and remove the op

Retire WITHOUT_CXX option

Several important base system components are written in C++, and the
WITHOUT_CXX option produced a system that was not fully functional.
Just accept this, and remove the option to build without C++ support.

This reverts commit adc3c128c6603054586a993d117e5dd808deac17.

Reviewed by: brooks, kevans, jhb (earlier)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33108

show more ...

sbin: build ping if at least one of INET & INET6 is enabled

It does not build (and serves no purpose) if neither is true (i.e.,
building WITHOUT_INET and WITHOUT_INET6). Also add an explicit error

sbin: build ping if at least one of INET & INET6 is enabled

It does not build (and serves no purpose) if neither is true (i.e.,
building WITHOUT_INET and WITHOUT_INET6). Also add an explicit error
in ping to make this case clear.

PR: 260082
Sponsored by: The FreeBSD Foundation

show more ...

Retire obsolete iscsi_initiator(4)

The new iSCSI initiator iscsi(4) was introduced with FreeBSD 10.0, and
the old intiator was marked obsolete shortly thereafter (in commit
d32789d95cfbf, MFC'd to s

Retire obsolete iscsi_initiator(4)

The new iSCSI initiator iscsi(4) was introduced with FreeBSD 10.0, and
the old intiator was marked obsolete shortly thereafter (in commit
d32789d95cfbf, MFC'd to stable/10 in ba54910169c4). Remove it now.

Reviewed by: jhb, mav
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32673

show more ...

Fix sconfig(8) build.

Missed that since sconfig(8) was built on i386 only. Since I enabled
cp(4) on amd64, enable sconfig(8) as well.

Fixes: 6aae3517ed25

Retire synchronous PPP kernel driver sppp(4).

The last two drivers that required sppp are cp(4) and ce(4).

These devices are still produced and can be purchased
at Cronyx <http://cronyx.ru/hardware

Retire synchronous PPP kernel driver sppp(4).

The last two drivers that required sppp are cp(4) and ce(4).

These devices are still produced and can be purchased
at Cronyx <http://cronyx.ru/hardware/wan.html>.

Since Roman Kurakin <[email protected]> has quit them, they no
longer support FreeBSD officially. Later they have dropped
support for Linux drivers to. As of mid-2020 they don't even
have a developer to maintain their Windows driver. However,
their support verbally told me that they could provide aid to
a FreeBSD developer with documentaion in case if there appears
a new customer for their devices.

These drivers have a feature to not use sppp(4) and create an
interface, but instead expose the device as netgraph(4) node.
Then, you can attach ng_ppp(4) with help of ports/net/mpd5 on
top of the node and get your synchronous PPP. Alternatively
you can attach ng_frame_relay(4) or ng_cisco(4) for HDLC.
Actually, last time I used cp(4) back in 2004, using netgraph(4)
instead of sppp(4) was already the right way to do.

Thus, remove the sppp(4) related part of the drivers and enable
by default the negraph(4) part. Further maintenance of these
drivers in the tree shouldn't be a big deal.

While doing that, remove some cruft and enable cp(4) compilation
on amd64. The ce(4) for some unknown reason marks its internal
DDK functions with __attribute__ fastcall, which most likely is
safe to remove, but without hardware I'm not going to do that, so
ce(4) remains i386-only.

Reviewed by: emaste, imp, donner
Differential Revision: https://reviews.freebsd.org/D32590
See also: https://reviews.freebsd.org/D23928

show more ...

Fix bsd.subdir.mk-related issues after 0a0f7486413c

Since bsd.prog.mk includes bsd.obj.mk, and thus bsd.subdir.mk, we must
ensure all our bsd.subdir.mk-affecting variables are set before
including b

Fix bsd.subdir.mk-related issues after 0a0f7486413c

Since bsd.prog.mk includes bsd.obj.mk, and thus bsd.subdir.mk, we must
ensure all our bsd.subdir.mk-affecting variables are set before
including bsd.prog.mk. Since sbin's various Makefile.arch files add to
SUBDIR this results in those not taking effect, and presumably we also
end up not having buildworld as parallel as it should be due to the fact
that SUBDIR_PARALLEL was not being set before including bsd.prog.mk.

MFC with: 0a0f7486413c147d56808b38055c40c64cff61f5
Reviewed by: olivier
Differential Revision: https://reviews.freebsd.org/D31125

show more ...

man: Build manpages for all architectures

Building and installing architecture-specific man pages only raises a number of
problems:

* The https://www.freebsd.org/cgi/man.cgi is incomplete. As an

man: Build manpages for all architectures

Building and installing architecture-specific man pages only raises a number of
problems:

* The https://www.freebsd.org/cgi/man.cgi is incomplete. As an
example, it does not show results for pae(4). The reason for this is
that the cgi interface runs on FreeBSD amd64.

* In FreeBSD amd64 some manual pages have broken X-refs. See hptrr(4)
for an example.

* Also, we have broken links in our Release Notes. This is a
consequence of the first point. See
https://www.freebsd.org/releases/13.0R/hardware/#proc-i386.

Make MAN_ARCH default to 'all' so we build all the man pages for all the
architectures. The difference in disk space is negligible. Also link
architecture-specific man pages to their own section while keeping their own
namespace.

PR: 212290
Reported by: [email protected]
Approved by: ceri@, wosch@
MFC after: 4 weeks

show more ...

Merge ping6 to ping

There is now a single ping binary, which chooses to use ICMP or ICMPv4
based on the -4 and -6 options, and the format of the address.

Submitted by: Ján Sučan <[email protected]

Merge ping6 to ping

There is now a single ping binary, which chooses to use ICMP or ICMPv4
based on the -4 and -6 options, and the format of the address.

Submitted by: Ján Sučan <[email protected]>
Sponsored by: Google LLC (Google Summer of Code 2019)
MFC after: Never
Differential Revision: https://reviews.freebsd.org/D21377

show more ...

Remove NAND and NANDFS support

NANDFS has been broken for years. Remove it. The NAND drivers that
remain are for ancient parts that are no longer relevant. They are
polled, have terrible performance

Remove NAND and NANDFS support

NANDFS has been broken for years. Remove it. The NAND drivers that
remain are for ancient parts that are no longer relevant. They are
polled, have terrible performance and just for ancient arm
hardware. NAND parts have evolved significantly from this early work
and little to none of it would be relevant should someone need to
update to support raw nand. This code has been off by default for
years and has violated the vnode protocol leading to panics since it
was committed.

Numerous posts to arch@ and other locations have found no actual users
for this software.

Relnotes: Yes
No Objection From: arch@
Differential Revision: https://reviews.freebsd.org/D20745

show more ...

Add verifying manifest loader for mac_veriexec

This tool will verify a signed manifest and load contents into
mac_veriexec for storage

Sponsored by: Juniper Networks
Differential Revision: D16575

New pfil(9) KPI together with newborn pfil API and control utility.

The KPI have been reviewed and cleansed of features that were planned
back 20 years ago and never implemented. The pfil(9) intern

New pfil(9) KPI together with newborn pfil API and control utility.

The KPI have been reviewed and cleansed of features that were planned
back 20 years ago and never implemented. The pfil(9) internals have
been made opaque to protocols with only returned types and function
declarations exposed. The KPI is made more strict, but at the same time
more extensible, as kernel uses same command structures that userland
ioctl uses.

In nutshell [KA]PI is about declaring filtering points, declaring
filters and linking and unlinking them together.

New [KA]PI makes it possible to reconfigure pfil(9) configuration:
change order of hooks, rehook filter from one filtering point to a
different one, disconnect a hook on output leaving it on input only,
prepend/append a filter to existing list of filters.

Now it possible for a single packet filter to provide multiple rulesets
that may be linked to different points. Think of per-interface ACLs in
Cisco or Juniper. None of existing packet filters yet support that,
however limited usage is already possible, e.g. default ruleset can
be moved to single interface, as soon as interface would pride their
filtering points.

Another future feature is possiblity to create pfil heads, that provide
not an mbuf pointer but just a memory pointer with length. That would
allow filtering at very early stages of a packet lifecycle, e.g. when
packet has just been received by a NIC and no mbuf was yet allocated.

Differential Revision: https://reviews.freebsd.org/D18951

show more ...

Rename be(1) to bectl(8); continues to live in /sbin

Discussed with: rpokala, allanjude

Import libbe(3)/be(1) from socsvn/soc2017/kneitinger/libbe-head

Makefiles: remove outdated comments

NVME support is only for x86 and powerpc64.

Implement MK_NVME now that the expression for where NVMe is
complicated. Default it to "yes" for x86 and powerpc64 and
no everywhere else. Use it in camco

NVME support is only for x86 and powerpc64.

Implement MK_NVME now that the expression for where NVMe is
complicated. Default it to "yes" for x86 and powerpc64 and
no everywhere else. Use it in camcontrol to define WITH_NVME
for those platforms where we support nvme.

This should fix the newly introduced nvme files to camcontrol
which were building everywhere.

Pointy Hat To: imp
Sponsored by: Netflix

show more ...

Move devmatch to sbin from usr/sbin.

Since we want to use devmatch in context before a split /,/usr system
has mounted /usr, move devmatch to /sbin.

Sponsored by: Netflix

Remove badsect(8).

Failure modes of the modern (that is, produced in the last 25 years)
hard drives and SSDs made the utility outdated. Since the kernel
interface to support it was removed in r3248

Remove badsect(8).

Failure modes of the modern (that is, produced in the last 25 years)
hard drives and SSDs made the utility outdated. Since the kernel
interface to support it was removed in r324853, cut the userspace
remnants as well.

Discussed with: bde (who does not like the removal)
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks

show more ...

Remove SUBDIR ordering/uniquifying in *bin/Makefile

After the addition of SUBDIR.yes, uniquifying/ordering the SUBDIRs doesn't
make a whole lot of sense, and it's in effect a half measure.

Ordering

Remove SUBDIR ordering/uniquifying in *bin/Makefile

After the addition of SUBDIR.yes, uniquifying/ordering the SUBDIRs doesn't
make a whole lot of sense, and it's in effect a half measure.

Ordering SUBDIR (after adding SUBDIR.yes to it) in bsd.subdir.mk is a
separate change that warrants more discussion/testing, because while
the SUBDIR_PARALLEL work largely fixed dependency ordering for SUBDIRs,
there might be downstream FreeBSD consumers that rely on the SUBDIR
ordering.

MFC after: 2 months
Reviewed by: bdrewery
Differential Revision: D11398

show more ...

Remove the NATM framework including the en(4), fatm(4), hatm(4), and
patm(4) devices.

Maintaining an address family and framework has real costs when we make
infrastructure improvements. In the cas

Remove the NATM framework including the en(4), fatm(4), hatm(4), and
patm(4) devices.

Maintaining an address family and framework has real costs when we make
infrastructure improvements. In the case of NATM we support no devices
manufactured in the last 20 years and some will not even work in modern
motherboards (some newer devices that patm(4) could be updated to
support apparently exist, but we do not currently have support).

With this change, support remains for some netgraph modules that don't
require NATM support code. It is unclear if all these should remain,
though ng_atmllc certainly stands alone.

Note well: FreeBSD 11 supports NATM and will continue to do so until at
least September 30, 2021. Improvements to the code in FreeBSD 11 are
certainly welcome.

Reviewed by: philip
Approved by: harti

show more ...

Add support for encrypted kernel crash dumps.

Changes include modifications in kernel crash dump routines, dumpon(8) and
savecore(8). A new tool called decryptcore(8) was added.

A new DIOCSKERNELDU

Add support for encrypted kernel crash dumps.

Changes include modifications in kernel crash dump routines, dumpon(8) and
savecore(8). A new tool called decryptcore(8) was added.

A new DIOCSKERNELDUMP I/O control was added to send a kernel crash dump
configuration in the diocskerneldump_arg structure to the kernel.
The old DIOCSKERNELDUMP I/O control was renamed to DIOCSKERNELDUMP_FREEBSD11 for
backward ABI compatibility.

dumpon(8) generates an one-time random symmetric key and encrypts it using
an RSA public key in capability mode. Currently only AES-256-CBC is supported
but EKCD was designed to implement support for other algorithms in the future.
The public key is chosen using the -k flag. The dumpon rc(8) script can do this
automatically during startup using the dumppubkey rc.conf(5) variable. Once the
keys are calculated dumpon sends them to the kernel via DIOCSKERNELDUMP I/O
control.

When the kernel receives the DIOCSKERNELDUMP I/O control it generates a random
IV and sets up the key schedule for the specified algorithm. Each time the
kernel tries to write a crash dump to the dump device, the IV is replaced by
a SHA-256 hash of the previous value. This is intended to make a possible
differential cryptanalysis harder since it is possible to write multiple crash
dumps without reboot by repeating the following commands:
# sysctl debug.kdb.enter=1
db> call doadump(0)
db> continue
# savecore

A kernel dump key consists of an algorithm identifier, an IV and an encrypted
symmetric key. The kernel dump key size is included in a kernel dump header.
The size is an unsigned 32-bit integer and it is aligned to a block size.
The header structure has 512 bytes to match the block size so it was required to
make a panic string 4 bytes shorter to add a new field to the header structure.
If the kernel dump key size in the header is nonzero it is assumed that the
kernel dump key is placed after the first header on the dump device and the core
dump is encrypted.

Separate functions were implemented to write the kernel dump header and the
kernel dump key as they need to be unencrypted. The dump_write function encrypts
data if the kernel was compiled with the EKCD option. Encrypted kernel textdumps
are not supported due to the way they are constructed which makes it impossible
to use the CBC mode for encryption. It should be also noted that textdumps don't
contain sensitive data by design as a user decides what information should be
dumped.

savecore(8) writes the kernel dump key to a key.# file if its size in the header
is nonzero. # is the number of the current core dump.

decryptcore(8) decrypts the core dump using a private RSA key and the kernel
dump key. This is performed by a child process in capability mode.
If the decryption was not successful the parent process removes a partially
decrypted core dump.

Description on how to encrypt crash dumps was added to the decryptcore(8),
dumpon(8), rc.conf(5) and savecore(8) manual pages.

EKCD was tested on amd64 using bhyve and i386, mipsel and sparc64 using QEMU.
The feature still has to be tested on arm and arm64 as it wasn't possible to run
FreeBSD due to the problems with QEMU emulation and lack of hardware.

Designed by: def, pjd
Reviewed by: cem, oshogbo, pjd
Partial review: delphij, emaste, jhb, kib
Approved by: pjd (mentor)
Differential Revision: https://reviews.freebsd.org/D4712

show more ...

zfsbootcfg: a simple tool to set next boot (one time) options for zfsboot

(gpt)zfsboot will read one-time boot directives from a special ZFS pool
area. The area was previously described as "Boot Bl

zfsbootcfg: a simple tool to set next boot (one time) options for zfsboot

(gpt)zfsboot will read one-time boot directives from a special ZFS pool
area. The area was previously described as "Boot Block Header", but
currently it is know as Pad2, marked as reserved and is zeroed out on
pool creation. The new code interprets data in this area, if any, using
the same format as boot.config. The area is immediately wiped out.
Failure to parse the directives results in a reboot right after the
cleanup. Otherwise the boot sequence proceeds as usual.

zfsbootcfg writes zfsboot arguments specified on its command line to the
Pad2 area of a disk identified by vfs.zfs.boot.primary_pool and
vfs.zfs.boot.primary_vdev kenv variables that are set by loader during
boot. Please see the manual page for more.

Thanks to all who reviewed, contributed and made suggestions! There are
many potential improvements to the feature, please see the review for
details.

Reviewed by: wblock (docs)
Discussed with: jhb, tsoome
MFC after: 3 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D7612

show more ...

Update ^/vendor/NetBSD/tests/dist to a more recent snapshot

Pulled on "Thu Aug 11 18:01:19 PDT 2016"

Convert casperd(8) daemon to the libcasper.
After calling the cap_init(3) function Casper will fork from it's original
process, using pdfork(2). Forking from a process has a lot of advantages:
1. We

Convert casperd(8) daemon to the libcasper.
After calling the cap_init(3) function Casper will fork from it's original
process, using pdfork(2). Forking from a process has a lot of advantages:
1. We have the same cwd as the original process.
2. The same uid, gid and groups.
3. The same MAC labels.
4. The same descriptor table.
5. The same routing table.
6. The same umask.
7. The same cpuset(1).
From now services are also in form of libraries.
We also removed libcapsicum at all and converts existing program using Casper
to new architecture.

Discussed with: pjd, jonathan, ed, [email protected], emaste
Partially reviewed by: [email protected], bdrewery
Approved by: pjd (mentor)
Differential Revision: https://reviews.freebsd.org/D4277

show more ...