Bug 166508

Summary: [glxsb] AES 256 encryption does not work with glxsb driver
Product: Base System Reporter: Todd Blum <todd>
Component: kernAssignee: John Baldwin <jhb>
Status: Closed FIXED    
Severity: Affects Only Me CC: jhb, longwitz
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description Todd Blum 2012-03-30 04:00:26 UTC
Enabling the glxsb driver on an Alix board (Netgate m1n1wall 2D13) running pfSense 2.0.1 (FreeBSD 8.1) prevents AES256 IPSec Phase2 connections from establishing:

Mar 27 16:31:44 racoon: ERROR: pfkey ADD failed: Invalid argument
Mar 27 16:31:44 racoon: ERROR: pfkey UPDATE failed: Invalid argument
Mar 27 16:31:44 racoon: WARNING: attribute has been modified.
Mar 27 16:31:44 racoon: [Name of Tunnel]: INFO: initiate new phase 2 negotiation: my.ip.add.ress500<=>rem.ote.ip.adr500

AES128 IPSec connections still work OK.

I believe the remote side is Cisco IOS or ASA.   I am running 2.0.1-RELEASE (i386).  Other users have reported similar behavior: 


Per pfSense dev team, the problem is upstream in the FreeBSD kernel:


How-To-Repeat: Load glxsb driver, then try to establish an AES256 IPSec tunnel.
Comment 1 patfbsd 2012-06-24 13:33:52 UTC

This is a known issue and a problem within the crypto(9) framework. In
the crypto framework we can only specify the algorithm (here aes) to
use but not the size of the key. As glxsb only does aes-128, it fails
when the crypto framework opens a session on it if the key size if
different than 128.

There is a CAVEAT section in the manual page of glxsb(4) for this :
     The crypto(9) framework will fail to open the crypto session on the
     device if the AES key's length is != 128 bits.  This prevents the
     use of the glxsb device driver with AES keys of length != 128 bits.

To make this to work, it need some changes in crypto(9). Sorry.
(we can close this PR I guess, as it will not be solved)

Comment 2 Mark Linimon freebsd_committer freebsd_triage 2012-07-16 03:29:47 UTC
State Changed
From-To: open->suspended

Apparently this is documented in the manpage as being missing functionality. 

I'm going to leave it in 'suspended' in case someone searches GNATS in the 
Comment 3 longwitz 2016-03-25 10:12:07 UTC

the following patch eliminates the CAVEAT of glxsb(4) for me, so I can run AES with mixed length on soekris boxes using glxsb:

--- crypto.c.orig       2015-03-13 12:01:21.000000000 +0100
+++ crypto.c    2016-03-25 11:04:57.670215000 +0100
@@ -362,6 +362,14 @@
                    (cap->cc_flags & match) == 0)

+               /*
+                * workaround for CAVEAT in glxsb(4)
+                */
+               if (strncmp(device_get_nameunit(cap->cc_dev), "glxsb", 5) == 0 &&
+                   cri->cri_alg == CRYPTO_AES_CBC &&
+                   cri->cri_klen != 128)
+                       continue;
                /* verify all the algorithms are supported. */
                if (driver_suitable(cap, cri)) {
                        if (best == NULL |
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2018-05-20 23:52:31 UTC
For bugs matching the following conditions:
- Status == In Progress
- Assignee == "bugs@FreeBSD.org"
- Last Modified Year <= 2017

- Set Status to "Open"
Comment 5 John Baldwin freebsd_committer freebsd_triage 2021-05-26 20:07:37 UTC
I believe this should be resolved in FreeBSD 13 as the crypto framework provides more information such as key sizes to the drivers when a session is established via the crypto_probesession hook and glxsb should reject AES-256 sessions such that they should be able to fall back to another driver instead.  If you are still seeing issues with this in FreeBSD 13, please reopen.  Note that the changes in 13 are too disruptive to backport to 12.x.