Rename libwolfssl-cpu-crypto to libwolfsslcpu-crypto so that the
regular libwolfssl version comes first when running:
opkg install libwolfssl
Normally, if the package name matches the opkg parameter, that package
is preferred. However, for libraries, the ABI version string is
appended to the package official name, and the short name won't match.
Failing a name match, the candidate packages are sorted in alphabetical
order, and a dash will come before any number. So in order to prefer
the original library, the dash should be removed from the alternative
library.
Fixes: c3e7d86d2b (wolfssl: add libwolfssl-cpu-crypto package)
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
libwolfssl-cpu-crypto is a variant of libwolfssl with support for
cryptographic CPU instructions on x86_64 and aarch64.
On aarch64, wolfSSL does not perform run-time detection, so the library
will crash when the AES functions are called. A preinst script attempts
to check for support by querying /proc/cpuinfo, if installed in a
running system. When building an image, the script will check the
DISTRIB_TARGET value in /etc/openwrt_release, and will abort
installation if target is bcm27xx.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Disable the usage of target specific CPU crypto instructions by default
to allow the package being shared again. Since WolfSSL does not offer
a stable ABI or a long term support version suitable for OpenWrt release
timeframes, we're forced to frequently update it which is greatly
complicated by the package being nonshared.
People who want or need CPU crypto instruction support can enable it in
menuconfig while building custom images for the few platforms that support
them.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
The armvirt target is also used to run OpenWrt in lxc on other targets
like a Raspberry Pi. If we set WOLFSSL_HAS_CPU_CRYPTO by default the
wolfssl binray is only working when the CPU supports the hardware crypto
extension.
Some targets like the Raspberry Pi do not support the ARM CPU crypto
extension, compile wolfssl without it by default. It is still possible
to activate it in custom builds.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Without this, WOLFSSL_HAS_DH can be disabled even if WOLFSSL_HAS_WPAS is
enabled, resulting in an "Anonymous suite requires DH" error when trying
to compile wolfssl.
Signed-off-by: Pascal Ernster <git@hardfalcon.net>
Reviewed-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Co-authored-by: Pascal Ernster <git@hardfalcon.net>
Apply an upstream patch that removes unnecessary CFLAGs, avoiding
generation of incompatible code.
Commit 0bd536723303ccd178e289690d073740c928bb34 is reverted so the
accelerated version builds by default on x86_64.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This enables building WolfSSL with Curve448, which can be used by
Strongswan. This has been tested on a Linksys E8450, running OpenWrt
22.03-rc4.
This allows parity with OpenSSL, which already supports Curve448 in
OpenWrt 21.02.
Fixesopenwrt/packages#18812.
Signed-off-by: Joel Low <joel@joelsplace.sg>
Co-authored-by: Joel Low <joel@joelsplace.sg>
WolfSSL is crashing with an illegal opcode in some x86_64 CPUs that have
AES instructions but lack other extensions that are used by WolfSSL
when AES-NI is enabled.
Disable the option by default for now until the issue is properly fixed.
People can enable them in a custom build if they are sure it will work
for them.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
* wolfssl: don't change ABI because of hw crypto
Enabling different hardware crypto acceleration should not change the
library ABI. Add them to PKG_CONFIG_DEPENDS after the ABI version hash
has been computed.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
* wolfssl: add benchmark utility
This packages the wolfssl benchmark utility.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
* wolfssl: enable CPU crypto instructions
This enables AES & SHA CPU instructions for compatible armv8, and x86_64
architectures. Add this to the hardware acceleration choice, since they
can't be enabled at the same time.
The package was marked non-shared, since the arm CPUs may or may not
have crypto extensions enabled based on licensing; bcm27xx does not
enable them. There is no run-time detection of this for arm.
NOTE:
Should this be backported to a release branch, it must be done shortly
before a new minor release, because the change to nonshared will remove
libwolfssl from the shared packages, but the nonshared are only built in
a subsequent release!
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
* wolfssl: set nonshared flag global
libwolfssl-benchmark should NOT be compiled as nonshared but
currently there is a bug where, on buildbot stage2, the package
is recompiled to build libwolfssl-benchmark and the dependency
change to the new libwolfssl version.
Each dependant package will now depend on the new wolfssl package
instead of the one previously on stage1 that has a different package
HASH.
Set the nonshared PKGFLAGS global while this gets investigated
and eventually fixed.
Fixes: 0a2edc2714dc ("wolfssl: enable CPU crypto instructions")
Signed-off-by: Christian 'Ansuel' Marangi <ansuelsmth@gmail.com>
* Revert "wolfssl: set nonshared flag global"
This reverts commit e0cc5b9b3ae65113f0e0dd9249dae4776b65c503.
A better and correct solution was found.
Signed-off-by: Christian 'Ansuel' Marangi <ansuelsmth@gmail.com>
* wolfssl: make WOLFSSL_HAS_OPENVPN default to y
Openvpn forces CONFIG_WOLFSSL_HAS_OPENVPN=y. When the phase1 bots build
the now non-shared package, openvpn will not be selected, and WolfSSL
will be built without it. Then phase2 bots have CONFIG_ALL=y, which
will select openvpn and force CONFIG_WOLFSSL_HAS_OPENVPN=y. This
changes the version hash, causing dependency failures, as shared
packages expect the phase2 hash.
Fixes: #9738
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Co-authored-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Co-authored-by: Christian 'Ansuel' Marangi <ansuelsmth@gmail.com>
* libs/wolfssl: add SAN (Subject Alternative Name) support
x509v3 SAN extension is required to generate a certificate compatible with
chromium-based web browsers (version >58)
It can be disabled via unsetting CONFIG_WOLFSSL_ALT_NAMES
Signed-off-by: Sergey V. Lobanov <sergey@lobanov.in>
* wolfssl: update to 5.1.1-stable
Bump from 4.8.1-stable to 5.1.1-stable
Detailed release notes: https://github.com/wolfSSL/wolfssl/releases
Upstreamed patches:
001-Maths-x86-asm-change-asm-snippets-to-get-compiling.patch -
fa8f23284d
002-Update-macro-guard-on-SHA256-transform-call.patch -
f447e4c1fa
Refreshed patches:
100-disable-hardening-check.patch
200-ecc-rng.patch
CFLAG -DWOLFSSL_ALT_CERT_CHAINS replaced to --enable-altcertchains
configure option
The size of the ipk changed on aarch64 like this:
491341 libwolfssl4.8.1.31258522_4.8.1-stable-7_aarch64_cortex-a53.ipk
520322 libwolfssl5.1.1.31258522_5.1.1-stable-1_aarch64_cortex-a53.ipk
Tested-by: Alozxy <alozxy@users.noreply.github.com>
Acked-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Signed-off-by: Sergey V. Lobanov <sergey@lobanov.in>
Co-authored-by: Sergey V. Lobanov <sergey@lobanov.in>
