It calls OF_* functions to check if it needs to implement workarounds.
This may not be the case on arm64 where we support both FDT and ACPI.
Fix this by checking if we are booting on FDT before calling these checks.
Reviewed by: ian
Sponsored by: DARPA, AFRL
Sponsored by: Cavium (Hardware)
Differential Revision: https://reviews.freebsd.org/D14515
Retpoline is a compiler-based mitigation for CVE-2017-5715, also known
as Spectre V2, that protects against speculative execution branch target
injection attacks.
In this commit it is disabled by default, but will be changed in a
followup commit.
Reviewed by: bdrewery (previous version)
MFC after: 3 days
Security: CVE-2017-5715
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D14242
When checking the validity of the pf.conf file also include the user supplied
pf_flags. These flags might overrule macros or specify anchors, which we will
apply when actually applying the pf.conf file, so we must also take them into
account when verifying the validity.
Submitted by: Andreas Longwitz <longwitz at incore.de>
MFC after: 3 weeks
pfctl only takes the last '-F' argument into account, so this never did what
was intended.
Moreover, there is no reason to flush rules before reloading, because pf keeps
track of the rule which created a given state. That means that existing
connections will keep being processed according to the rule which originally
created them. Simply reloading the (new) rules suffices. The new rules will
apply to new connections.
PR: 127814
Submitted by: Andreas Longwitz <longwitz at incore.de>
MFC after: 3 weeks
We've included an extra '0' in there (which might get removed later, but
it's maintained for the moment for legacy purposes) which oftentimes
indicate that the following number should be treated as octal. This is not
the case, so note that to prevent future confusion (of myself and others).
Our module bits ended up more stable than I anticipated, so this turns out
to be no longer useful.
If things like this need to come back, we should do it in a separate 'debug'
module to serve as a collection of debugging aides. As a rule, this 'debug'
module would *not* be allowed as a requirement of any other modules in-tree.
- Add screen.default_x and screen.default_y to determine where
screen.defcursor resets the cursor to.
- Use screen.setcursor in screen.defcursor instead of rewriting the escape
sequence.
- Use screen.default_y when resetting the cursor after writing the new
twiddle character, add a comment verbally describing the position just in
case.
It worked on my test setup, but is clearly non-functional on others.
Further examination of check-password.4th showed that it actually reset the
cursor to 0,25 every time and overwrote the previous password prompt. Do
that, and also clear the "Incorrect Password" text if the correct password
gets entered.
Revert r314685, and add a comment describing the original
behavior and the intent.
Reviewed by: dab@ vangyzen@ jhb@
Differential Revision: https://reviews.freebsd.org/D14530
for the minimum length.
This fixes a bug where cookies of length 2 bytes (which is smaller
than the minimum length of 4) is provided by the server.
Sponsored by: Netflix, Inc.
The source of error is a rounded increment being too large and thus the loop
steps slightly past 'last'. Perform a final comparison using the formatted
string values (truncated precision) to determine if we still need to print
the 'last' value.
PR: 217149
Submitted by: Fernando Apesteguía <fernando.apesteguia AT gmail.com>,
Yuri Pankov <yuripv AT icloud.com> (earlier version)
Reported by: Martijn Dekker <mcdutchie AT hotmail.com>
Sponsored by: Dell EMC Isilon
When dhclient first starts, if an old IP address exists in the
dhclient.leases file, dhclient(8) sends early DHCPREQUEST message(s)
in an attempt to re-obtain the old IP address again. These messages
contain the old IP as a requested-IP-address option in the message
body (correct) but also use the old IP address as the packet's source
IP (incorrect).
RFC2131 sec 4.1 states:
DHCP messages broadcast by a client prior to that client obtaining
its IP address must have the source address field in the IP header
set to 0.
The use of the old IP as the packet's source address is incorrect if
(a) the computer is now on a different network or (b) it is on the
same network, but the old IP has been reallocated to another host.
Fix dhclient to use 0.0.0.0 as the source IP in this circumstance
without removing any existing functionality. Any previously-used old
IP is still requested in the body of an early DHCPREQUEST message.
PR: 199378
Submitted by: J.R. Oldroyd <fbsd@opal.com>
Reported by: J.R. Oldroyd <fbsd@opal.com>
Reviewed by: cem, asomers, vangyzen
MFC after: 1 week
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D14527
twiddle_pos didn't need to be a module-scope local, since it's going to get
reset with every read anyways- it was left-over from other things.
screen.movecursor with a y=-1 setting was from a test of movecursor,
resulting in the twiddle characters being drawn going up the console and
looking quite funky.
This gives some form of feedback while typing, and matches-(ish*) Forth
behavior. The cursor generally rests two column after the password prompt,
then the twiddle is drawn three columns later and the cursor reset to
resting position after being drawn.
I've removed the note about re-evaluating it for security considerations and
instead set it up as a module-local variable that we can set later depending
on environment or something. It's set to false with no chance of changing at
the moment.
*As close as I can tell from reading check-password.4th, because I don't
have an easy test (or deployed) setup for forth loader to check how close
it is. Please do mention if it's not close enough.
Page daemon threads for other domains show up in ps(1) output as
"pagedaemon/domN", so let that be the case for domain 0 as well.
Submitted by: Kevin Bowling <kevin.bowling@kev009.com>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D14518
Those operations, zfsctl_snapdir_readdir and zfsctl_snapdir_getattr,
access the filesystem's objset and it can be unstable during operations
like receive and rollback.
MFC after: 2 weeks
There are some _write callbacks left only returning EROFS, replace them
by null_write. return EROFS from null_write().
Reviewed by: cem, imp, kan
Differential Revision: https://reviews.freebsd.org/D14523
nothing - it was checking for ENXIO, which, with devfs, is no longer
returned - and was badly placed anyway, and replaces it with similar
one that works, and is done just before starting getty, instead of being
done when rereading ttys(5).
From the practical point of view, this makes init(8) handle disappearing
terminals (eg /dev/ttyU*) gracefully, without unneccessary getty restarts
and resulting error messages.
Reviewed by: imp@
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D14307
A reservation granule on PowerPC is a cache line.
On e500mc and derivatives a cacheline size is 64 bytes, not 32. Allocate
the maximum size permitted, but only utilize the size that is needed. On
e500v1 and e500v2 the reservation granule will still be 32 bytes.
Chain frames required to satisfy all 2K of declared I/Os of 128KB each take
more then a megabyte of a physical memory, all of which existing code tries
allocate as physically contiguous. This patch removes that physical
contiguousness requirement, leaving only virtual contiguousness. I was
thinking about other ways of allocation, but the less granular allocation
becomes, the bigger is the overhead and/or complexity, reaching about 100%
overhead if allocate each frame separately.
The patch also bumps the chain frames hard limit from 2K to 16K. It is more
than enough for the case of default REQ_FRAMES and MAXPHYS (the drivers will
allocate less than that automatically), while in case of increased MAXPHYS
it will control maximal memory usage.
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D14420
to what other arches (all except riscv and armv4/5) do.
Submitted by: Hyun Hwang <hyun@caffeinated.codes>
Differential Revision: https://reviews.freebsd.org/D14465
After the auth key is copied into the ipad[] array, any remaining bytes
are cleared to zero (in case the key is shorter than one block size).
The full block size was used as the length of the zero rather than the
size of the remaining ipad[]. In practice this overflow was harmless as
it could only clear bytes in the following opad[] array which is
initialized with a copy of ipad[] in the next statement.
Sponsored by: Chelsio Communications
The parameters describe how much of the adapter's memory is reserved for
storing TLS keys. The 'meminfo' sysctl now lists this region of adapter
memory as 'TLS keys' if present.
Sponsored by: Chelsio Communications
* If compiled with EXT_RESOURCES look up the "biu" and "ciu" clocks in
the DT
* Don't use custom property "bus-frequency" but the standard one
"clock-frequency"
* Use the DT property max-frequency and fall back to 200Mhz if it don't exists
* Add more mmc caps suported by the controller
* Always ack all interrupts
* Subclassed driver can supply an update_ios so they can handle update
the clocks accordingly
* Take care of the DDR bit in update_ios (no functional change since we
do not support voltage change for now)
* Make use of the FDT bus-width property
* rk_cru is a cru driver that needs to be subclassed by
the real CRU driver
* rk_clk_pll handle the pll type clock on RockChip SoC, it's only read
only for now.
* rk_clk_composite handle the different composite clock types (with gate,
with mux etc ...)
* rk_clk_gate handle the RockChip gates
* rk_clk_mux handle the RockChip muxes (unused for now)
* Only clocks for supported devices are supported for now, the rest will be
added when driver support comes
* The assigned-clock* property are not handled for now so we rely a lot on the
bootloader to setup some initial values for some clocks.
A memory leak in syslogd for processing of forward actions was
reported. This modification adapts the patch submitted with that bug
to fix the leak. While testing the modification, another leak was also
found and fixed.
PR: 198385
Submitted by: Sreeram <sreeramabs@yahoo.com>
Reported by: Sreeram <sreeramabs@yahoo.com>
Reviewed by: hrs
MFC after: 1 week
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D14510
