Bug 166508 - [glxsb] AES 256 encryption does not work with glxsb driver
Summary: [glxsb] AES 256 encryption does not work with glxsb driver
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: John Baldwin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-30 04:00 UTC by Todd Blum
Modified: 2021-05-26 20:07 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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: 

http://forum.pfsense.org/index.php?topic=47701.new

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

https://redmine.pfsense.org/issues/2324#change-8509

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

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 :
CAVEAT
     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)

Regards.
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 
future.
Comment 3 longwitz 2016-03-25 10:12:07 UTC
Hello,

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)
                        continue;

+               /*
+                * 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

Do
- 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.