The function pr_pack() prints out a packet, if the IP packet contains
options, these are printed as well.
Test the functionality fixed in
70960bb86a.
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D38470
Ping used to provide some sort of packet sniffing capabilities, this was
in an era where hubs were used and tcpdump wasn't invented.
pr_iph() is a function that prints the IP header of the packet.
pr_retip() is essentially a wrapper function to pr_iph(), that also
displays the source and destination ports of a TCP or UDP packet.
After ef9e6dc7ee some of this
functionality was almost removed, to only display packets sent by us
(26+ years ago).
At this point, reaching this code path was only possible by doctoring
the original packet.
After 46d7b45a26 this code path can never
be reached.
Remove the code.
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D38475
When an ICMP packet contains an IP packet in its payload, and that
original IP packet contains options, these options were not displayed
accordingly in pr_iph().
pr_iph() is a function that prints the original "quoted packet" IP
header, with only an IP struct as an argument. The IP struct does not
contain IP options, and it is not guaranteed that the options will be
contiguous in memory to the IP struct after
d9cacf605e.
Pass the raw ICMP data along with the IP struct, in order to print the
options, if any.
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D38469
Historically the system panic'ed when it encountered a corrupt
directory. This change recovers well enough to continue operations.
This change is made in response to a similar change made in the ext2
filesystem as described in the cited Differential Revision.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D38503
Revision r333125 AKA 986c4ca387 forced clear cpu_stdext_feature3
on suspend, since at that time microcode update was not reloaded
early on resume. Then, revision 050f5a8405 started re-reading
cpu_stdext_feature3 again. Since modern CPUs do not require mitigations
from the Skylake era, this went unnoticed for some time.
Keep zeroing cpu_stdext_feature3 on suspend, but re-read it in more
controlled way on resume after microcode is reloaded, and recalculate
active workarounds based on actual microcode capabilities.
Reported and tested by: romain
Reviewed by: emaste, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D39146
A number of improvements has commited to snl(3) recently.
A notable one is snl(3) build-in parsers for all of the objects
exported by the kernel.
This change updates netlink handling code to the latest available snl(3)
API.
Use .An -nosplit for the AUTHORS section, so that
it renders without an unnecessary newline.
No .Dd bump since it isn't a content change.
MFC after: 3 days
Azure setup does not like it when FreeBSD overrides the settings of the
UART device. When Hyper-V is detected, don't do this and also don't
throttle putc() output. This is a workaround for the early boot hang
of FreeBSD on Azure.
Tested on Azure, ESXi (VM with serial port), and SG-8200
PR: 264267
Reviewed by: kevans, whu
Tested by: whu
Obtained from: Rubicon Communications, LLC (Netgate)
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (Netgate)
UEFI provides ConIn/ConOut handles for consoles that it supports,
which include the text-video and serial ports. When the serial port
is available, use the UEFI driver instead of direct io-port accesses
to avoid conflicts between the firmware and direct hardware access, as
happens on Hyper-V (Azure) setups.
This change enables efiserialio to be built for efi-amd64 and has
higher order priority vs comconsole, and only uses efiserialio
if the hypervisor is Hyper-V. When efiserialio successfully
probes, it will set efi_comconsole_avail=true which will prevent
comconsole from probing in this setup.
Tested on Hyper-V, ESXi and Azure VMs.
PR: 264267
Reviewed by: kevans, whu
Tested by: whu
Obtained from: Rubicon Communications, LLC (Netgate)
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (Netgate)
The panic() will be called under ext2_dirbad()
function in case of rw mount. It cause user confusion,
like in BZ 265951.
PR: 265951
Reviewed by: pfg, mckusick
MFC after: 2 week
Differential revision: https://reviews.freebsd.org/D38503
Add check that directory entry with ino=EXT2_ROOTINO
have correct namelength and name. It is possible to
create malicious image which will cause panic if root
directory entry have incorrect name.
PR: 259068
Reported by: Robert Morris
Reviewed by: pfg
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D38502
Start breaking down big main()
Remove goto exit label and replace it with a function that does cleanup.
Comment re-worded by kevans@.
Pull Request: https://github.com/freebsd/freebsd-src/pull/694
And minor style fixes.
Reviewed by: hselasky
Tested by: Weitao Wang <WeitaoWang-oc@zhaoxin.com>
Fixes: 0d7064d58f xhci(4): Add new USB IDs
Differential Revision: https://reviews.freebsd.org/D38921
It got disabled in 2003:
commit acb18acfec
Author: Poul-Henning Kamp <phk@FreeBSD.org>
Date: Sun Feb 23 18:09:05 2003 +0000
Bracket the kern.vnode sysctl in #ifdef notyet because it results
in massive locking issues on diskless systems.
It is also not clear that this sysctl is non-dangerous in its
requirements for locked down memory on large RAM systems.
There does not seem to be practical use for it and the disabled routine
does not work anyway.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D39127
The sizeof(struct ip) is 20.
The sizeof(struct in_addr) is 4.
No functional change intended.
Reviewed by: asomers, markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D39125
ipi counters are missing in bhyvectl's output because vm_maxcpu is 0
when initializing them. That's because vmm_stat_register is executed
before vmm_init.
Instead of directly fixing it, there's a better solution in illumos
which is cherry picked:
65a3bc8373
It replaces the matrix statistic by two counters per vcpu. One for
counting the ipis to the vcpu and one counting the ipis received by the
vcpu. This has several advantages:
- A matrix statistic becomes huge when using many vcpus.
- A matrix statistic easily reaches the MAX_VMM_STAT_ELEMS limit.
- Two counters are enough in most cases. DTrace can be used for more
advanced debugging purposes.
- A matrix statistic wastes memory. The matrix size is determined by
vm_maxcpu regardless of the number of vcpus assigned to the vm.
Reviewed by: corvink, markj
Fixes: ee98f99d7a ("vmm: Convert VM_MAXCPU into a loader tunable hw.vmm.maxcpu.")
MFC after: 1 week
Sponsored by: vStack
Differential Revision: https://reviews.freebsd.org/D39038
We had GENERIC for a while now so anyone still interested in those boards
should make sure that we can boot on them with it and with upstream DTS files.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: br
Differential Revision: https://reviews.freebsd.org/D39088
There is nothing hdmi related in this interface, it's just a generic interface
for crt controller so rename it.
This also remove the 'hdmi' device used in arm kernel config. 'vt' now controls
if we build this interface (sc(4) isn't supported on arm).
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D39120
device 'hdmi' is too generic (and will be used later in a new device) so rename
the arm TI devices to some proper name.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D39119
device 'hdmi' is too generic (and will be used later in a new device) so rename
the arm IMX devices to some proper name.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D39118
It was disconnected 5 years ago in 4573cd3914
("arm: allwinner: Disconnect A10/A20 HDMI driver") as it wasn't working.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D39117
All devices are in GENERIC and GENERIC is known to boot on those SoCs.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D39090
We had GENERIC for a while now so anyone still interested in those boards
should make sure that we can boot on them with it and with upstream DTS files.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D39089
We had GENERIC for a while now so anyone still interested in those boards
should make sure that we can boot on them with it and with upstream DTS files.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D39087
It reference to a non-existant dts file apalis-imx6.dts so unlikekly to compile.
Aldo IMX6 support is in GENERIC so anyone interested in this board should
make it work with GENERIC kernel (if that's not already the case).
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D39086
Let the user decide if he wants to use bhyve's fwctl or qemu's fwcfg. He
can set the interface by adding a fwcfg option to bootrom:
-l bootrom,<path/to/rom>,fwcfg=bhyve
-l bootrom,<path/to/rom>,fwcfg=qemu
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38337
Fwcfg items without a fixed index are reported by the file_dir. They
have an index of 0x20 and above. This helper simplifies the addition of
such fwcfg items. It selects a new free index, assigns it to the fwcfg
items and creates an proper entry in the file_dir.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38336
cpuid detection may have picked up a more specific guest type already,
and a follow-up check of smbios vendor/product may erroneously blow
away the previously detected type.
This reportedly fixes the boot under Hyper-V, which advertises an
smbios.system.product of "Virtual Machine."
PR: 270239
Reviewed by: imp, kib (both earlier version, same concept)
Fixes: 2fee875629 ("abstract out the vm detection via smbios..")
Differential Revision: https://reviews.freebsd.org/D39140
Without this patch, a Kerberized NFSv4.1/4.2 mount must provide
a Kerberos credential for the client at mount time. This credential
is typically referred to as a "machine credential". It can be
created one of two ways:
- The user (usually root) has a valid TGT at the time the mount
is done and this becomes the machine credential.
There are two problems with this.
1 - The user doing the mount must have a valid TGT for a user
principal at mount time. As such, the mount cannot be put
in fstab(5) or similar.
2 - When the TGT expires, the mount breaks.
- The client machine has a service principal in its default keytab
file and this service principal (typically called a host-based
initiator credential) is used as the machine credential.
There are problems with this approach as well:
1 - There is a certain amount of administrative overhead creating
the service principal for the NFS client, creating a keytab
entry for this principal and then copying the keytab entry
into the client's default keytab file via some secure means.
2 - The NFS client must have a fixed, well known, DNS name, since
that FQDN is in the service principal name as the instance.
This patch uses a feature of NFSv4.1/4.2 called SP4_NONE, which
allows the state maintenance operations to be performed by any
authentication mechanism, to do these operations via AUTH_SYS
instead of RPCSEC_GSS (Kerberos). As such, neither of the above
mechanisms is needed.
It is hoped that this option will encourage adoption of Kerberized
NFS mounts using TLS, to provide a more secure NFS mount.
This new NFSv4.1/4.2 mount option, called "syskrb5" must be used
with "sec=krb5[ip]" to avoid the need for either of the above
Kerberos setups to be done by the client.
Note that all file access/modification operations still require
users on the NFS client to have a valid TGT recognized by the
NFSv4.1/4.2 server. As such, this option allows, at most, a
malicious client to do some sort of DOS attack.
Although not required, use of "tls" with this new option is
encouraged, since it provides on-the-wire encryption plus,
optionally, client identity verification via a X.509
certificate provided to the server during TLS handshake.
Alternately, "sec=krb5p" does provide on-the-wire
encryption of file data.
A mount_nfs(8) man page update will be done in a separate commit.
Discussed on: freebsd-current@
MFC after: 3 months