| Age | Commit message (Collapse) | Author |
|---|
|
If we get a random number, the NZCV is set to 0b0000. Then
"cset %w1, ne" will test whether Z == 0 and set %w1 to 1 if so.
More specifically, "cset %w1, ne" maps to "csinc %w1, wzr, wzr, eq",
which stores 0 in %w1 when NZCV == 0b0100 and 1 otherwise.
Thus, on a successful read we expect ret != 0, so the loop condition
needs to be fixed. In practice this means that we would end up trying
to fetch entropy up to ten times in a row. If all attempts are
successful, the last will be returned, otherwise no entropy will be
returned.
Reported by: Kevin Day <kevin@your.org>
Reviewed by: andrew
Fixes: 9eecef052155 ("Add an Armv8 rndr random number provider")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54259
|
|
and one that will be with us in the long-term future.
(this helps reduce diffs in the future and for down-stream users
that trim entropy sources). Also, move deprecated (removed in 16.0)
sources to the bottom of the list to reduce changes to 15.x.
Reviewed by: glebius
Obtained from: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D53311
|
|
Ensure that the number of elements of random_source_descr[]
and fxrng_ent_char[] matches that of enum random_entropy_source.
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D53255
|
|
The Hifn 7955 & 7956 only supports deprecated & NIST disallowed
algorithms (NIST SP800-224idp): SHA1 and SHA1-HMAC.
Furthermore the entropy RNG of the Hifn 7751, 7951, 7811, 7955,
and 7956 has no NIST Entropy Source Validation (ESV) certificate
and cannot be used in a FIPS-140-3 nor Common Criteara environment.
Furthermore the most prolific instance for FreeBSD was the
Soekris Engineering vpn1201, vpn1211, vpn1401, and vpn1411
offerings. These are all 32-bit only processors. The i386
kernel was de-supported in 15.0.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D53182
|
|
Reviewed by: cem
Fixes: 1492c8c0d qcom_rnd: add initial qualcomm prng driver.
Fixes: 9eecef052 Add an Armv8 rndr random number provider
Fixes: b2f8b2dc8 sys: Add an SMCCC Random Number Generator driver
Differential Revision: https://reviews.freebsd.org/D53292
|
|
Reviewed by: cem
Fixes: 3a1298 random: add RDSEED as a provably unique entropy source
Differential Revision: https://reviews.freebsd.org/D53291
|
|
It was used for Octeon MIPS and all producers have been removed
from the source tree.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D53146
|
|
NIST SP800-90B allows for only a single entropy source to be claimed
in a FIPS-140-3 certificate. In addition, only hardware sources that
have a NIST Entropy Source Validation (ESV) certificate, backed by
a SP800-90B Entropy Assessment Report, are usable. Intel has obtained
ESV certificates for several of their processors, so RDSEED is a
FIPS-140-3 suitable entropy source.
However, even though RDRAND is seeded by RDSEED internally, RDRAND
would need a RBG certificate and CAVP testing run on the DRBG in order
to use it for FIPS-140-3 (SP800-90B) purposes. So we need to know
down in the CSPRNG-subsystem which source the entropy came from.
In light of the potential issues surrounding AMD Zen 5 CPU's RDSEED
implementation[*], allow RDSEED to be disabled in loader.conf.
[*] https://www.phoronix.com/news/AMD-EPYC-Turin-RDSEED-Bug
Reviewed by: cem
MFC after: 3 days
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D53150
|
|
Otherwise we get a NULL pointer dereference when writing to /dev/random.
PR: 288826
Reviewed by: cem
MFC after: 1 week
Fixes: fa8db724ae6e ("random: Treat writes to /dev/random as separate from /entropy")
Differential Revision: https://reviews.freebsd.org/D52633
|
|
So-called pure sources provide entropy at regular intervals, so the
timestamp counter provides little entropy. Exclude it from health
testing for such sources.
Reviewed by: cem, emaste
MFC after: 2 weeks
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D52233
|
|
The current implementation of the NIST health tests assumes a
min-entropy estimate of one bit per sample, which is quite conservative.
For so-called "pure" sources (e.g., virtio-random, TPM) it might be nice
to support larger estimates so that the tests catch failed devices more
quickly.
Thus:
- let each pure random source provide an estimate, so that downstreams
or driver implementors can override defaults if they want to;
- increase the default estimate for pure sources;
- for pure sources initialize the state machine at source registration
time.
Reviewed by: cem
MFC after: 2 weeks
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D52232
|
|
This variable provides a mask of all registered entropy sources and is
updated when drivers attach and detach (or by sysctl). However, nothing
was synchronizing accesses to it. Use the harvest lock to provide
mutual exclusion for updates, and use atomic_load_int() to mark unlocked
reads.
Reviewed by: cem
MFC after: 2 weeks
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D52230
|
|
Most pure sources work under a "pull" model wherein a dedicated thread
polls the source at regular intervals (every 100ms). A couple of
sources, however, will instead call random_harvest_direct() to provide
entropy samples. Such sources were not calling random_source_register()
and thus weren't in the global random source list.
Modify "push" sources to use random_source_register() like other sources
do. Such sources omit an implementation of rs_read and are thus skipped
by the above-mentioned thread. This makes it easier to allow pure
sources to provide a min-entropy estimate in a uniform way.
Reviewed by: cem
MFC after: 2 weeks
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D52229
|
|
Right now the cutoff values for the RCT and APT tests are computed with
a fixed min-entropy estimate of 1. In preparation for permitting
alternative estimates for "pure" sources (i.e., hardware noise sources),
extend the code to handle alternative estimates of an integer number of
bits.
For the RCT test, the cutoff is simply the formula from section 4.4.1 of
NIST SP 800-90B. For the APT test, I used Excel to compute a lookup
table using the formula provided in section 4.4.2.
Reviewed by: cem
MFC after: 2 weeks
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D52228
|
|
We can do so trivially, so make these tables read-only. No functional
change intended.
Reviewed by: cem, emaste
MFC after: 2 weeks
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D52003
|
|
In the calculation of the cutoff value, we haven't changed the window
size itself, just the example formula, which takes the window size as a
parameter.
Reviewed by: cem
Fixes: f92ff79720fb ("random: Add NIST SP 800-90B entropy source health test implementations")
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D52002
|
|
RANDOM_CACHED is overloaded to refer both to entropy obtained from files
loaded by the boot loader, and entropy obtained via writes to
/dev/random. Introduce a new source, RANDOM_RANDOMDEV, to refer to the
latter. This is to enable treating RANDOM_CACHED as a special case in
the NIST health test implementation.
Update the default harvest_mask in rc.conf to include RANDOM_RANDOMDEV,
preserving the old behaviour of accepting writes to /dev/random.
Bump __FreeBSD_version for modules which register a pure source, since
all of their values have now shifted.
Reviewed by: cem
MFC after: 3 months
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51155
|
|
This patch implements the noise source health tests described in chapter
four of NIST SP 800-90B[1]. The repetition count test and adaptive
proportion test both help identify cases where a noise source is stuck
and generating the same output too frequently. The tests are disabled
by default, but making an implementation available may help implementors
conform to FIPS validation requirements. This implementation aims to
comply with the requirements listed in section 4.3 of the document.
To enable health testing, set the kern.random.nist_healthtest_enabled
tunable to 1. Startup testing is implemented as specified in the
document: the first 1024 samples from a source are evaluated according
to the two tests, and they are discarded. The RANDOM_CACHED and
RANDOM_PURE_VMGENID sources are excluded from testing, as they are
effectively a one-time source of entropy, and statistical testing
doesn't seem to provide much use.
Since the first 1024 samples from entropy sources are discarded by the
implementation, it is possible that we might end up with insufficient
entropy during early boot if no boot-time entropy source (i.e.,
/entropy) is provided. If this is a problem, it could be remediated by
modifying the implementation to poll applicable sources (e.g., RDRAND)
to complete startup testing quickly, rather than relying on the random
kthread.
The entry point for the tests is random_harvest_healthtest(), intended
to be called from individual CSPRNG implementations in order to leverage
their locking context, e.g., the entropy pool lock in Fortuna. The
Fortuna implementation is modified to call this entry point, mainly to
demonstrate how the health tests can be integrated.
The tests operate on the entropy buffer plus the embedded timestamp,
treating them as a single value. We could alternately apply the tests
to the buffer and timestamp separately.
The main parameters for the tests themselves are H, the expected
min-entropy of samples, and alpha, the desired false positive error
rate. This implementation selects H=1 and alpha=2^{-34}; since each
sample includes a CPU cycle counter value, it seems reasonable to expect
at least one bit of entropy from among the low bits of the
high-frequency counter present on systems where FreeBSD is commonly
deployed, and the false positive rate was somewhat arbitrarily selected;
for more details see the comment in random_healthtest_init().
When a health test fails, a message is printed to the console and the
source is disabled. On-demand testing is also supported via the
kern.random.nist_healthtest_ondemand sysctl. This can be used be an
administrator to re-enable a disabled source, following the same startup
testing mentioned above.
[1] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf
Reviewed by: cem
MFC after: 3 months
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51154
|
|
The entropy queue stores entropy gathered from environmental sources.
Periodically (every 100ms currently), the random kthread will drain this
queue and mix it into the CSPRNG's entropy pool(s).
The old scheme uses a ring buffer with a mutex to serialize producers,
while the sole consumer, the random kthread, avoids using a mutex on the
basis that no serialization is needed since nothing else is updating the
consumer index. On platforms without total store ordering, however,
this isn't sufficient: when a producer inserts a queue entry and updates
`ring.in`, there is no guarantee that the consumer will see the updated
queue entry upon observing the updated producer index. That is, the
update to `ring.in` may be visible before the updated queue entry is
visible. As a result, we could end up mixing in zero'ed queue entries,
though this race is fairly unlikely in practice given how infrequently
the kthread runs.
The easiest way to fix this is to make the kthread acquire the mutex as
well, and hold it while processing queue entries. However, this might
result in a long hold time if there are many queue entries, and we
really want the hold times to be short, e.g., to avoid delaying
interrupt processing.
We could introduce a proper MPSC queue, but this is probably
overcomplicated for a consumer which runs at 10Hz.
Instead, define two buffers, always with one designated as the "active"
buffer. Producers queue entries in the active buffer, and the kthread
uses the mutex to atomically flip the two buffers, so it can process
entries from the inactive buffer without holding the mutex. This
requires more memory, but keeps mutex hold times short and lets us keep
the queue implementation very simple.
Reviewed by: cem
MFC after: 1 month
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51112
|
|
Such annotations are obsolete, the compiler tells us when parameters are
unused. No functional change intended.
Reviewed by: cem
MFC after: 1 week
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51114
|
|
Entropy queue entries always include the low 32 bits of a CPU cycle
count reading. Introduce a macro for this instead of hard-coding
get_cyclecount() calls everywhere; this is handy for testing purposes
since this way, random(4)'s use of the cycle counter (e.g., the number
of bits we use) can be changed in one place.
No functional change intended.
Reviewed by: cem, delphij
MFC after: 1 week
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51113
|
|
They can't be used externally, so it makes no sense to have them in a
header. No functional change intended.
Reviewed by: cem
MFC after: 1 week
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51111
|
|
No functional change intended.
Reviewed by: cem
MFC after: 1 week
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51110
|
|
Switch to using sys/stdarg.h for va_list type and va_* builtins.
Make an attempt to insert the include in a sensible place. Where
style(9) was followed this is easy, where it was ignored, aim for the
first block of sys/*.h headers and don't get too fussy or try to fix
other style bugs.
Reviewed by: imp
Exp-run by: antoine (PR 286274)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1595
|
|
The Arm True Random Number Generator Firmware Interface provides a way
to query the SMCCC firmware for up to 192 bits of entropy. Use it to
provide another source of randomness to the kernel.
Reviewed by: cem, markm
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D46989
|
|
Move RANDOM_FORTUNA_{NPOOLS,DEFPOOLSIZE} from fortuna.c to fortuna.h
and use RANDOM_FORTUNA_DEFPOOLSIZE in random_harvestq.c rather than
having a magic (albeit explained in a comment) number. The NPOOLS
value will be used in a later commit.
Reviewed by: cem
MFC after: 1 week
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D46693
|
|
- s/parmeter/parameter/
MFC after: 3 days
|
|
We have the mechanism in place to support encoding system registers
explicitly, so use that rather than requiring LLVM 13+, which breaks our
current set of GitHub CI builds.
Fixes: 9eecef052155 ("Add an Armv8 rndr random number provider")
|
|
Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.
Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/
Sponsored by: Netflix
|
|
Armv8.5 adds an optional random number generator. This is implemented
as two special registers one to read a random number, the other to
re-seed the entropy pool before reading a random number. Both registers
will set the condition flags to tell the caller they can't produce a
random number in a reasonable amount of time.
Without a signal to reseed the entropy pool use the latter register
to provide random numbers to the kernel pool. If at a later time we
had a way to tell the provider if it needs to reseed or not we could
use the former.
On an Amazon AWS Graviton3 VM this never failed, however this may not
be the case on low end CPUs so retry reading the random number 10 times
before returning an error.
Reviewed by: imp, delphij (csprng)
Sponsored by: The FreeBSD Foundation
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D35411
|
|
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D41583
|
|
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
|
|
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
|
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
|
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
|
|
We periodically ingest entropy from pollable entropy sources, but only
8 bytes at a time and only occasionally enough to feed all of Fortuna's
pools once per second. This can result in Fortuna remaining unseeded
for a nontrivial amount of time when there is no entropy passed in from
the boot loader, even if RDRAND is available to quickly provide a large
amount of entropy.
Detect in random_sources_feed if we are not yet seeded, and increase the
amount of immediate entropy harvesting we perform, in order to "fill"
Fortuna's entropy pools and avoid having
random: randomdev_wait_until_seeded unblock wait
stall the boot process when entropy is available.
This speeds up the FreeBSD boot in the Firecracker VM by 2.3 seconds.
Approved by: csprng (delphij)
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D35802
|
|
- Add the missing RANDOM_PURE_QUALCOMM description
- Make RANDOM_PURE_VMGENID consistent with the other pure sources
by including "PURE_" in the description.
Approved by: csprng (cem)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35412
|
|
All supported compilers (modern versions of GCC and clang) support
this.
Many places didn't have an #else so would just silently do the wrong
thing. Ancient versions of icc (the original motivation for this) are
no longer a compiler FreeBSD supports.
PR: 263102 (exp-run)
Reviewed by: brooks, imp
Differential Revision: https://reviews.freebsd.org/D34797
|
|
- s/psuedo/pseudo/
MFC after: 3 days
|
|
UEFI provides a protocol for accessing randomness. This is a good way
to gather early entropy, especially when there's no driver for the RNG
on the platform (as is the case on the Marvell Armada8k (MACCHIATObin)
for now).
If the entropy_efi_seed option is enabled in loader.conf (default: YES)
obtain 2048 bytes of entropy from UEFI and pass is to the kernel as a
"module" of name "efi_rng_seed" and type "boot_entropy_platform"; if
present, ingest it into the kernel RNG.
Submitted by: Greg V
Reviewed by: markm, kevans
Approved by: csprng (markm)
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D20780
|
|
74cf7cae4d22 ("softclock: Use dedicated ithreads for running callouts.")
switched callouts away from the swi infrastructure. It turns out that
this was a major source of entropy in early boot, which we've now lost.
As a result, first boot on hardware without a 'fast' entropy source
would block waiting for fortuna to be seeded with little hope of
progressing without manual intervention.
Let's resolve it by explicitly harvesting entropy in callout_process()
if we've handled any callouts. cc/curthread/now seem to be reasonable
sources of entropy, so use those.
Discussed with: jhb (also proposed initial patch)
Reported by: many
Reviewed by: cem, markm (both csprng)
Differential Revision: https://reviews.freebsd.org/D34150
|
|
This was introduced in 2014 along with the comment (which has since
been deleted):
/* Introduce an annoying delay to stop swamping */
Modern cryptographic random number generators can ingest arbitrarily
large amounts of non-random (or even maliciously selected) input
without losing their security.
Depending on the number of "boot entropy files" present on the system,
this can speed up the boot process by up to 1 second.
Reviewed by: cem
MFC ater: 1 week
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D32984
|
|
It seems that clang IAS erronously adds repz prefix which should not be
there. Cpu would try to store around %ecx bytes of random, while we
only expect a word.
PR: 259218
Reported and tested by: Dennis Clarke <dclarke@blastwave.org>
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
|
|
Previously, we were collecting at a base rate of:
64 bits x 32 pools x 10 Hz = 2.5 kB/s
This change drops it to closer to 64-ish bits per pool per second, to
work a little better with entropy providers in virtualized environments
without compromising the security goals of Fortuna.
Reviewed by: #csprng (cem, delphij, markm)
Differential Revision: https://reviews.freebsd.org/D32021
|
|
Refer to discussion in PR 230808 for a less incomplete discussion, but
the gist of this change is that we currently collect orders of magnitude
more entropy than we need.
The excess comes from bytes being read out of /dev/*random. The default
rate at which we collect entropy without the read_rate increase is
already more than we need to recover from a compromise of an internal
state.
Reviewed by: #csprng (cem, delphij, markm)
Differential Revision: https://reviews.freebsd.org/D32021
|
|
Push the root seed version to userspace through the VDSO page, if
the RANDOM_FENESTRASX algorithm is enabled. Otherwise, there is no
functional change. The mechanism can be disabled with
debug.fxrng_vdso_enable=0.
arc4random(3) obtains a pointer to the root seed version published by
the kernel in the shared page at allocation time. Like arc4random(9),
it maintains its own per-process copy of the seed version corresponding
to the root seed version at the time it last rekeyed. On read requests,
the process seed version is compared with the version published in the
shared page; if they do not match, arc4random(3) reseeds from the
kernel before providing generated output.
This change does not implement the FenestrasX concept of PCPU userspace
generators seeded from a per-process base generator. That change is
left for future discussion/work.
Reviewed by: kib (previous version)
Approved by: csprng (me -- only touching FXRNG here)
Differential Revision: https://reviews.freebsd.org/D22839
Notes:
svn path=/head/; revision=366622
|
|
There is no functional change for the existing Fortuna random(4)
implementation, which remains the default in GENERIC.
In the FenestrasX model, when the root CSPRNG is reseeded from pools due to
an (infrequent) timer, child CSPRNGs can cheaply detect this condition and
reseed. To do so, they just need to track an additional 64-bit value in the
associated state, and compare it against the root seed version (generation)
on random reads.
This revision integrates arc4random(9) into that model without substantially
changing the design or implementation of arc4random(9). The motivation is
that arc4random(9) is immediately reseeded when the backing random(4)
implementation has additional entropy. This is arguably most important
during boot, when fenestrasX is reseeding at 1, 3, 9, 27, etc., second
intervals. Today, arc4random(9) has a hardcoded 300 second reseed window.
Without this mechanism, if arc4random(9) gets weak entropy during initial
seed (and arc4random(9) is used early in boot, so this is quite possible),
it may continue to emit poorly seeded output for 5 minutes. The FenestrasX
push-reseed scheme corrects consumers, like arc4random(9), as soon as
possible.
Reviewed by: markm
Approved by: csprng (markm)
Differential Revision: https://reviews.freebsd.org/D22838
Notes:
svn path=/head/; revision=366621
|
|
Fortuna remains the default; no functional change to GENERIC.
Big picture:
- Scalable entropy generation with per-CPU, buffered local generators.
- "Push" system for reseeding child generators when root PRNG is
reseeded. (Design can be extended to arc4random(9) and userspace
generators.)
- Similar entropy pooling system to Fortuna, but starts with a single
pool to quickly bootstrap as much entropy as possible early on.
- Reseeding from pooled entropy based on time schedule. The time
interval starts small and grows exponentially until reaching a cap.
Again, the goal is to have the RNG state depend on as much entropy as
possible quickly, but still periodically incorporate new entropy for
the same reasons as Fortuna.
Notable design choices in this implementation that differ from those
specified in the whitepaper:
- Blake2B instead of SHA-2 512 for entropy pooling
- Chacha20 instead of AES-CTR DRBG
- Initial seeding. We support more platforms and not all of them use
loader(8). So we have to grab the initial entropy sources in kernel
mode instead, as much as possible. Fortuna didn't have any mechanism
for this aside from the special case of loader-provided previous-boot
entropy, so most of these sources remain TODO after this commit.
Reviewed by: markm
Approved by: csprng (markm)
Differential Revision: https://reviews.freebsd.org/D22837
Notes:
svn path=/head/; revision=366620
|
|
In addition to reducing lines of code, this also ensures that the full
allocation is always zeroed avoiding possible bugs with incorrect
lengths passed to explicit_bzero().
Suggested by: cem
Reviewed by: cem, delphij
Approved by: csprng (cem)
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D25435
Notes:
svn path=/head/; revision=362624
|
|
This driver was previously marked for deprecation in r360710.
Approved by: csprng (cem, gordon, delphij)
Relnotes: yes
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D24766
Notes:
svn path=/head/; revision=360918
|
