In D12421#258230, @wma wrote:

Oh, I indeed forgot to add -U9999 to the format-patch, sorry.

As for the installation of fbsd on P8, I have a plan to investigate what can be done to make the petitboot running the freebsd kernel or loader netively.
I see two solutions - just ideas, I didn't check their feasibility yet:

1. Modify kexec+petitboot to understand freebsd kernel. Right now it finds that the ELF is relocatable and refuses to go further. Most likely it would require porting loader.kboot into petitboot.

In D12466#258441, @tsoome wrote:

In D12466#258432, @sbruno wrote:

In D12466#258416, @tsoome wrote:

This is busting all the effort of avoiding to define tftp or NFS at build time, isn’t it?

I'm unsure as what I can tell is that the current version of pxeboot won't tftp an MFSroot + Kernel in its current state.

Its possible that I just don't know what the magical incantation is in dhcpd.conf to get it to work right, but tcpdump doesn't show a TFTP req if this code isn't in place.

I can not check the man pxeboot right now, but we have tftp:// prefix etc. I am not sure if the man has received the update, or it is just a,bout the source.

In D12466#258441, @tsoome wrote:

In D12466#258432, @sbruno wrote:

In D12466#258416, @tsoome wrote:

This is busting all the effort of avoiding to define tftp or NFS at build time, isn’t it?

I'm unsure as what I can tell is that the current version of pxeboot won't tftp an MFSroot + Kernel in its current state.

Its possible that I just don't know what the magical incantation is in dhcpd.conf to get it to work right, but tcpdump doesn't show a TFTP req if this code isn't in place.

I can not check the man pxeboot right now, but we have tftp:// prefix etc. I am not sure if the man has received the update, or it is just a,bout the source.

Hmm, the commit message is perhaps not clear as it conflates the two meanings of "key" when it first states "there is no limit", which applies to "user supplied key" but it is about correcting the size of the "key the algorithm uses". I would perhaps leave the member as 'keysize' instead of 'max_keysize'. Perhaps we can replace it in the future with a flag indicating if a key is valid at all and if it is the implied value is 'blocksize'.

In D12452#258449, @jhb wrote:

On a general note, I would almost consider making this part of aesni.ko instead if the effective sets of CPUs that support both instruction sets is the same (or nearly so).

In D12451#258445, @jhb wrote:

Note that using this should also let you remove the hardcoded lists of supported "cipher groups" for device names and all the 'skipif' stuff.

In D12437#258443, @jhb wrote:

In D12437#258088, @cem wrote:

In D12437#258077, @jhb wrote:

By larger keys I meant keys larger than the block size. ccr(4) handles this explicitly in ccr_init_hmac_digest() for example. However, this same bit of code needs to be duplicated in all drivers which seems a bit odd.

Ah. None of the drivers I reviewed handles larger than block size correctly. It would be a little odd to have to duplicate that in all of the drivers.

That is what Linux does. I'd probably like us to avoid that if possible.

On a general note, I would almost consider making this part of aesni.ko instead if the effective sets of CPUs that support both instruction sets is the same (or nearly so). In particular, the existing aesni.ko code does not accelerate things that combine AES with an HMAC (like an IPSec session using AES-CBC with a SHA HMAC). Having a single module that registers support for whatever algorithms the CPU supports (only SHA if AESNI isn't available for example) would permit the driver to handle these chained operations by combining AESNI with accelerated SHA hashing. (In this case aesni.ko would perhaps be better named "x86_crypto.ko" or some such to mean "accelerated software crypto for x86".)

In D12437#258443, @jhb wrote:

Well, I think the only functional result of this change is to permit shorter keys passed via /dev/crypto, yes?

I was going to say that you needed to update crypto(4) but it doesn't have an ERRORS section yet. :(

In D12437#258088, @cem wrote:

In D12437#258077, @jhb wrote:

By larger keys I meant keys larger than the block size. ccr(4) handles this explicitly in ccr_init_hmac_digest() for example. However, this same bit of code needs to be duplicated in all drivers which seems a bit odd.

Ah. None of the drivers I reviewed handles larger than block size correctly. It would be a little odd to have to duplicate that in all of the drivers.

If I don't receive any feedback, I'll treat the silence as acquiescence and go ahead with this change.

In D12466#258432, @sbruno wrote:

In D12466#258416, @tsoome wrote:

This is busting all the effort of avoiding to define tftp or NFS at build time, isn’t it?

I'm unsure as what I can tell is that the current version of pxeboot won't tftp an MFSroot + Kernel in its current state.

Its possible that I just don't know what the magical incantation is in dhcpd.conf to get it to work right, but tcpdump doesn't show a TFTP req if this code isn't in place.