Page MenuHomeFreeBSD

New port: security/ktls_isa-l_crypto.
ClosedPublic

Authored by gallatin on Aug 27 2019, 10:54 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Mar 4, 5:11 PM
Unknown Object (File)
Feb 21 2024, 4:46 AM
Unknown Object (File)
Jan 24 2024, 7:33 AM
Unknown Object (File)
Dec 24 2023, 4:01 PM
Unknown Object (File)
Dec 20 2023, 7:11 AM
Unknown Object (File)
Nov 13 2023, 9:40 PM
Unknown Object (File)
Sep 30 2023, 8:01 PM
Unknown Object (File)
Jul 20 2023, 10:23 PM
Subscribers

Details

Summary

This port provides a kernel module containing a KTLS software
backend for AES-GCM connections using Intel's ISA-L crypto
library.

Test Plan
  • tested with KTLS
  • I have left gallatin@ as the MAINTAINER as he is likely to be more active with this going forward I think

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 26201
Build 24706: arc lint + arc unit

Event Timeline

gallatin added inline comments.
security/ktls_isa-l_crypto/files/Makefile
36

I'm not a ports expert, but does specifying the full path to yasm here come with any drawbacks?

This revision is now accepted and ready to land.Aug 30 2019, 1:46 PM
security/ktls_isa-l_crypto/files/Makefile
36

Probably. It should maybe use LOCALBASE. I'll try to find a ports person who can review this.

imp added a subscriber: imp.

It looks good to my eye, modulo my suggestion.

security/ktls_isa-l_crypto/files/Makefile
36

YASM=${PREFIX}/bin/yasm
I think is the right thing

  • Use LOCALBASE for yasm.
  • Make portlint mostly happy.
  • Use IGNORE instead of BROKEN.
  • Use PLIST_FILES instead of 1-line pkg-plist.
This revision now requires review to proceed.Aug 30 2019, 10:22 PM
jhb marked 2 inline comments as done.Aug 30 2019, 10:24 PM
  • Use bsd.post.port.mk at bottom.
  • Add missing svn props on intel_isakern.c.

By convention we use the suffix -kmod for such ports.

Let me take a look at a few other things that those ports do by default (I know USES=uidfix is in most of them). I am not that familiar with them.

Please see PR 240395. After a half hour of trying to argue with phabricator-- and failing -- I need to move on to other tasks.

gallatin edited reviewers, added: jhb; removed: gallatin.
  • I've taken linimon's changes from bugzilla
  • I've hooked the port to the Makefile in the parent

Mark: I was not able to reproduce your build failure. If you could give me more details about where you're building the port, I can try to fix what you are seeing.

Updated the port to handle TLS 1.3

Re-submit diff with -U999999 for full context.

Mark: I was not able to reproduce your build failure. If you could give me more details about where you're building the port, I can try to fix what you are seeing.

I am trying to bring up a later 13 snapshot so that I can try again.

security/ktls_isa-l_crypto-kmod/Makefile
1 ↗(On Diff #62663)

So, the Created by: line is only "about" the ports Makefile itself. Even so, we've been moving away from including it, in favor of letting people use SVN to look at the committer of the initial import. FYI.

This revision was not accepted when it landed; it landed in state Needs Review.Sep 29 2019, 1:10 AM
This revision was automatically updated to reflect the committed changes.
head/security/ktls_isa-l_crypto-kmod/files/intelisa_kern.c
166 ↗(On Diff #62695)

This actually undoes one of the changes I had made. For TLS < 1.3 you need to read the 8 byte nonce out of the TLS header supplied by the kernel instead of assuming it is the sequence number. Especially if we do the change to use a random starting value, then this will break since the nonce on the wire will be the random value but this module would have encrypted it as if it was the sequence number, so the client will get garbage when it tries to decrypt.

head/security/ktls_isa-l_crypto-kmod/files/intelisa_kern.c
142 ↗(On Diff #62695)

Why is this 32 bytes I wonder? The AES IV is always 16 bytes regardless of key size as it is the length of one block. Furthermore, for GCM it is really always 12 bytes with the last 4 bytes as a counter that always starts as 0x0002 and increments by 1 for each 16-byte block.