Ping @salvadore -- I just want to check I got the Sponsor: bit right before I push.

Updated, just one question...

Use Sponsor: tag

Ping @salvadore ? Just want to make sure this doesn't miss the deadline now that the quarter is over.

In D46851#1068386, @concussious.bugzilla_runbox.com wrote:

The doc/website/tools/hardware-notes-processor.rb script parses the .Sh HARDWARE section to automagically create a note once the manual page is listed in the website/archetypes/release/hardware.adoc file.

This is extremely significant news to me. HARDWARE is not a standard section in mdoc(7) or mentioned in style.mdoc(5). The linter (at least used to) complains about non-standard sections. I will work on this.

I don't like the idea of having "vendor" code as part of the FreeBSD release process. As far as I'm concerned, it's either part of FreeBSD or it isn't -- we can bring mfsBSD into FreeBSD if @mm wants but if we're going to do that it should be maintained in the FreeBSD tree.

@pjd Are you ok with this now?

In D46635#1064502, @cem wrote:

This is now sort of a layering violation, right? We're assuming Fortuna implements devrandom, but the interface is pluggable. We have 2-3 implementations in tree, and integrators might write their own for compliance reasons.

I would suggest adding a new interface to devrandom for providing boot-time trusted entropy (sufficient for initial seeding), and let devrandom implementations integrate that entropy appropriately.

This seems like it could be a kernel panic rather than merely logging an error and resetting the device.

this commit adds a new reset reason.

the PTA device, march hare network, TOR, Chrony, Pacemaker and ENA driver read delay

I'd suggest expanding the abbreviation "PHC" somewhere early in the commit message. I *think* we're talking about PTP Hardware Clock here?

Is returning an error the right response here? My initial reaction is that this should be a kernel panic, but maybe it's easier to track down such faults if the system keeps running?

Given that there's an implicit cast to u8 in the assignment,
the correct value is being read, but this change makes it
even more accurate.

It seems a bit weird to define functions for setting bits which Must Be Zero, but this looks rather like generated code so I guess that's why?

BTW "parmater" -> "parameter" in the title.

ENA_MEMCPY_TO_DEVICE_64 macro needs pci bus id

Dumb question, but where does the delay_us value which is passed to this come from? It looks like it come from ena_min_poll_delay_us which... as far as I can tell is never set? Is this just vestigal code or am I missing something?

number of descriptors can vary from 1 to 8

This now depends on https://reviews.freebsd.org/D46693 which exposes some Fortuna constants.

Add missing free(buf)

Avoid magic numbers, and add comments.

In D46638#1062943, @lwhsu wrote:

Perhaps just do this globally?

In D46635#1063113, @cem wrote:

I don't think there's any reason to spread this using pbkdf2 just to defeat the Fortuna input seeding thresholds. You might as well seed the 64 bytes and then 2048-64 bytes of zero, or whatever. (Internally Fortuna is compressing the provided seed material using SHA2.)

Basically your goal is to assert that this source is perfectly trustworthy and has relatively high bits-per-byte of actual entropy. That is probably reasonable.

(Maybe Fortuna should have a seeding mode for this built in and incorporate x86 rdrand/rdseed like this too.)