Dear Maintainer,

on systems lacking AES-NI support critical strongswan processes (charon,
swanctl) get terminated by SIGILL in libstrongswan-aesni.so.

The issue is that strongswan applications auto-load all plugins and
libstrongswan-aesni.so loads even when AES-NI are not available.



Issue appeared after upgrading from bullseye (5.9.1-1+deb11u5).
I did not yet have a chance to test this with trixie yet, sorry.

Explicitely configuring charon AND swanctl plugins or simply deleting
the .so makes strongswan fall back non-AES-NI path and work correctly.



Is it possible to modify libstrongswan-aesni.so so it refuses to load
when AES-NI are not available instead of causing hard-to-debug SIGILL?



Best,
n.b.f.

Hi,

The plugin definitely checks for AES-NI and PCLMULQDQ at runtime.  But
what it did not do so far is check for SSSE3 (the next release will do
so).  So are you running on a CPU that has AES-NI and PCLMULQDQ
instructions but lacks support for SSSE3?  Maybe virtualized?

It's loaded but it doesn't register any plugin features if the required
CPU features are not found.  So it shouldn't cause any SIGILL when
running on unsuitable hardware (except in the combination mentioned above).

Regards,
Tobias

Hi,

The plugin definitely checks for AES-NI and PCLMULQDQ at runtime.  But
what it did not do so far is check for SSSE3 (the next release will do
so).  So are you running on a CPU that has AES-NI and PCLMULQDQ
instructions but lacks support for SSSE3?  Maybe virtualized?

It's loaded but it doesn't register any plugin features if the required
CPU features are not found.  So it shouldn't cause any SIGILL when
running on unsuitable hardware (except in the combination mentioned above).

Regards,
Tobias

Hello,

No, it is a real i686 CPU. No SSE and definitely no AES-NI.

Then it must be something else, even before it tries to encrypt anything.
Yes, even swanctl --help crashes with SIGILL when swanctl.load="aesni".


Best,
n.b.f.

Hi,

What CPU is that (/proc/cpuinfo could be helpful)?

So maybe it's the feature detection that runs when the plugin is loaded.
 But that's some simple push/pop/mov and cpuid assembler code [1].  Does
your CPU lack support for cpuid?

Regards,
Tobias

[1]
https://github.com/strongswan/strongswan/blob/master/src/libstrongswan/utils/cpu_feature.c#L57-L61

Hello
Debian 12 cpu_feature.c uses only cpuid leaf 0 and leaf 1, that should be safe.

Result from gdb: Illegal instruction is punpcklqdq in aesni_plugin_create.
  <+52>: movd %ecs,%xmm0
  <+56>: movd %edx,%xmm0
  <+60>: punpckldq %xmm2,%xmm1
  <+64>: punpckldq %xmm3,%xmm0
=><+68>: puncpklqdq %xmm1,%xmm0
  <+72>: movups %#mm0,(%eax)
  <+75>: add $0x18,%esp
  <+78>: pop %ebx
  <+79>: ret

https://lwn.net/Articles/1046940/ says SSE2 is mandatory for Trixie and later.
Bookworm and before should work with original P6 set, only SSE and MMX?

Do you actually support Bookworm? For Trixie and later this is "won't fix".
Fingers crossed 32-bit networking boxes would continue to support encryption.


Best,
n.b.f.

Hi,

Oh, interesting.  The complete `aesni` plugin is compiled with `-maes
-mpclmul -mssse3`.  That apparently causes the compiler to "optimize"
the code there.  I guess we could split the plugin into a helper library
that uses those flags and compile the plugin constructor/detection code
without it.  I've pushed such a change to the devel branch [1].

Anyway, another question is if it actually makes sense to ship the
plugin in Debian.  The default crypto library is OpenSSL nowadays and
since that will use AES-NI etc. anyway (likely more optimized than this
plugin), there is probably not much use having `aesni` enabled as well.

Regards,
Tobias

[1]
https://github.com/strongswan/strongswan/commit/553ac5678b50729da896fa07ff8bc502a2a8f3da

Hello,

Nice to see strongswan design makes this easy. Though it's more like
"implementation" library than "helper".

Good question, especially for i386.


Best,
n.b.f.

[1] https://github.com/strongswan/strongswan/commit/553ac5678b50729da896fa07ff8bc502a2a8f3da

I think it's the default in Trixie but not in Bookworm.