fixed file path in diff

Thanks for the review!

Nothing left for me to review here since the manual page was addressed elsewhere, I think.

Ping .

I agree with all the comments above; I can't think of any significance to order of configuration of interfaces now. It might still affect the order of the interface list returned from the kernel, but most things that look at that list now process the whole thing.

Since Mike is still around, added him to confirm :)

This was in 4.3BSD:

The loopback interface should be the last interface configured,
as protocols may use the order of configuration as an indication of priority.
The loopback should \fBnever\fP be configured first unless no hardware
interfaces exist.

which is word-for-word identical, except for markup. It likely was true in the mid 80s, but I agree, it's no longer true or necessary. Mike Karels added it with the unhelpful commit message "warning about order of configuration" in 1986.

The text comes from pre-FreeBSD times.

@melifaro Done!

In D32820#809133, @pauamma_gundo.com wrote:

A few more nits, and https://reviews.freebsd.org/D32820?id=105449#inline-217280 still (and a few more minor nits)

Also: maybe it's worth considering splitting this review into two? Most of the ifconfig.8 changes does not look directly related to the review topic.

A few more nits, and https://reviews.freebsd.org/D32820?id=105449#inline-217280 still (and a few more minor nits)

D35409 and D35384 have been merged. Let's move on :)

Rebased on latest main branch.

Some minor nits found.

Test OK.

Fix bug in m_rcvif_restore() .

Fix whitespace.

Merge in changes from @jhb to sync with his latest "ktls_nic_tls_rx2" branch as of now.

Sorry, missed this one earlier.

Ping .

• Implement crypto state as enum (as suggested by Gleb)
• Remove an unused variable
• Rebased patch.

Protect from concurrent ioctls, and rebase on latest main branch

Rebase patch after @jhb latest crypto additions.

Manual page LGTM as well, English-wise. Can't speak for the rest or for consistency.

For example it is possible to share file descriptor tables, and one of the processes may not be encumbered by the jail.

I'm going to have to sleep on the approach. This is a known escape, but I don't know if the method used can fully plug it. For example it is possible to share file descriptor tables, and one of the processes may not be encumbered by the jail. As is it does solve it for processes which have no way to talk to each other apart from a partially shared fs though.

In D32356#785045, @hselasky wrote:

@jhb : No. The current patch is for -current / main. Do you want me to create such a git repository, or can we use your existing freebsd fork / branch?

@jhb : No. The current patch is for -current / main. Do you want me to create such a git repository, or can we use your existing freebsd fork / branch?

Do you have this pushed to a public branch somewhere (e.g. on GitHub?) It might be easiest to show you what I am saying about how to handle the crypto for the mixed case if I can generate a patch relative to your branch.

I think pushing it and fixing the lagg issue after its in the tree is probably the best path forward.

In D32356#778142, @jhb wrote:

One other structural thing I see is that this still assumes the outbound route path matches the inbound path (using the route to allocate the tag and changing ktls_output_eagain to reset both sessions on a TX failure). But as Drew noted that doesn't work in his setup where the RX and TX can be over different ports in a lagg since the remove end of the lagg can use whatever algorithm it wants to distribute the RX traffic. Instead, we need to store the "leaf" ifp in a new field in m_pkthdr or the like and pass that up through into the socket buffer. At the point of m_demote when we remove the packet header you would want to check for ifp mismatches like we do for output in ip_output_send. Perhaps that can be done as a second round, but then we will just have to revert the ktls_output_eagain() change so I'd rather avoid changing that API just to have to change it back later.

One other structural thing I see is that this still assumes the outbound route path matches the inbound path (using the route to allocate the tag and changing ktls_output_eagain to reset both sessions on a TX failure). But as Drew noted that doesn't work in his setup where the RX and TX can be over different ports in a lagg since the remove end of the lagg can use whatever algorithm it wants to distribute the RX traffic. Instead, we need to store the "leaf" ifp in a new field in m_pkthdr or the like and pass that up through into the socket buffer. At the point of m_demote when we remove the packet header you would want to check for ifp mismatches like we do for output in ip_output_send. Perhaps that can be done as a second round, but then we will just have to revert the ktls_output_eagain() change so I'd rather avoid changing that API just to have to change it back later.

@melifaro @jhb : ping

Rebase.

Rebase patch.

@jhb : Ping.

And for VNET(9) jail, it seems the loopback interface is always configured first.
The behavior is inconsistent with the host.

@jhb: I noticed in the AESNI crypto implementation that it might call malloc() when using the output buffer feature ... and this should be avoided when we already allocated a buffer.

Take @jhb 's suggestion to encrypt a zero'ed mbuf and then XOR.

In D32356#765375, @hselasky wrote:

Rework the re-crypt support. The low level APIs in the crypto framework can apparently only do full encryption and full decryption :-( So use that for now.

Rework the re-crypt support. The low level APIs in the crypto framework can apparently only do full encryption and full decryption :-( So use that for now.

Fix one more compilation issue.

Fix minor compilation issue.

Implement native single-pass recrypt function in the open crypto framework.

Hi John,

Diff reduction.

Rebased patch.

• Rebase patch.
• Properly implement ktls_ocf_tls13_aead_recrypt().

• Catch up with latest INP_FREED changes.
• Fix some compile issues.

Rebase patch.

Oooh, good catch.

In D33210#750542, @kp wrote:

That was done in 3dd5760aa5f876f8a3f0735afeebdf9ee414e1f5, so I'm a little confused where this comes from.

That was done in 3dd5760aa5f876f8a3f0735afeebdf9ee414e1f5, so I'm a little confused where this comes from.

Rebase patch for FreeBSD main branch.