This lets IPsec SA installation explicitly fail if HW offload is enabled
but either the kernel or the device don't support it. And it adds a new
configuration mode 'auto', which enables HW offload, if supported, but
does not fail the installation otherwise.
Until now the configuration available to user for HW offload were:
hw_offload = no
hw_offload = yes
With this commit users will be able to configure auto mode using:
hw_offload = auto
Signed-off-by: Adi Nissim <[email protected]>
Reviewed-by: Aviv Heller <[email protected]>
Until now there were 2 hw_offload modes: no/yes
* hw_offload = no : Configure the SA without HW offload.
* hw_offload = yes : Configure the SA with HW offload.
In this case, if the device does not support
offloading, SA creation will fail.
This commit introduces a new mode: hw_offload = auto
----------------------------------------------------
If the device and kernel support HW offload, configure
the SA with HW offload, but do not fail SA creation otherwise.
Signed-off-by: Adi Nissim <[email protected]>
Reviewed-by: Aviv Heller <[email protected]>
If a daemon PID file references the process that does the check, it is safe
to ignore it; no running process can have the same PID. While this is rather
unlikely to get restarted with the same PID under normal conditions, it is
quite common when running inside PID namespaced containers: If a container
gets stopped and restarted with a PID file remaining, it is very likely that
the PID namespace assigns the same PID to our service, as they are assigned
sequentially starting from 1.
According to RFC 5114 the exponent length for these groups should always equal
the size of their prime order subgroup.
This was handled correctly before the initialization was done during
library initialization.
Fixes: 46184b07c1 ("diffie-hellman: Explicitly initialize DH exponent sizes during initialization")
The previous code was obviously incorrect and caused strange side effects
depending on the compiler and its optimization flags (infinite looping seen
with GCC 4.8.4, segfault when destroying the private key in build() seen
with clang 4.0.0 on FreeBSD).
Fixes#2579.
We can't use ASN1_DEF, which would technically be more correct, as the
ASN.1 parser currently can't handle that. For algorithm identifiers we
often use ASN1_EOC as type (with ASN1_RAW), however, that doesn't work with
ASN1_DEF because the element is assumed missing if the type doesn't match.
On the other hand, we can't set the type to ASN1_SEQUENCE because then the
parser skips the following rule if the element is missing (it does so for
all constructed types, but I guess is mainly intended for context tags),
which in this case overruns the parser rules array.
This changes how unknown transform types are handled in proposals. In
particular we make sure not to accept a proposal if it contains unknown
transform types (they were just ignored previously, which could have
resulted in an invalid selected proposal).
Fixes#2557.
This way there will be a mismatch if one of the proposals contains
transform types not contained in the other (the fix list of transform
types used previously resulted in a match if unknown transform types
were contained in one of the proposals). Merging the sets of types
makes comparing proposals with optional transform types easier (e.g.
DH for ESP with MODP_NONE).
This improves the behavior during CREATE_CHILD_SA exchanges if the peer
sends an INVALID_KE_PAYLOAD with a DH group we didn't request or continues
to return the same notify even if we use the requested group.
Fixes#2536.
If we receive an INVALID_KE_PAYLOAD notify we should not just retry
with the requested DH group without checking first if we actually propose
the group (or any at all).
After a rekeying we keep the inbound SA and policies installed for a
while, but the outbound SA and policies are already removed. Attempting
to update them could get the refcount in the kernel interface out of sync
as the additional policy won't be removed when the CHILD_SA object is
eventually destroyed.
This changes how trap policies are deleted in order to avoid conflicts if a
trap policy with changed peer config is concurrently removed and reinstalled
under a different name (the reqid will be the same, so the wrong policy
could have been deleted by the old code).
Tobias Brunner