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>
(cherry picked from commit 0063e3421d)
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>
(cherry picked from commit d1b5d17d03)
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>
(cherry picked from commit 21825af2da)
Apply an upstream patch that removes unnecessary CFLAGs, avoiding
generation of incompatible code.
Commit 0bd5367233 is reverted so the
accelerated version builds by default on x86_64.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit 639419ec4f)
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>
(cherry picked from commit 0bd5367233)
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>
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>
(cherry picked from commit 0a2edc2714)
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>
Support for wolfSSL has been upstreamed to the master OpenVPN branch
in f6dca235ae560597a0763f0c98fcc9130b80ccf4, so we can use wolfSSL
directly in OpenVPN. So no more needed differnt SSL engine for OpenVPN
in systems based on wolfSSL library
Compiled && tested on ramips/mt7620, ramips/mt7621
Signed-off-by: Ivan Pavlov <AuthorReflex@gmail.com>
Hardware acceleration was disabled when AES-CCM was selected as a
workaround for a build failure. This applies a couple of upstream
patches fixing this.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Always build AES-GCM support.
Unnecessary patches were removed.
This includes two vulnerability fixes:
CVE-2019-11873: a potential buffer overflow case with the TLSv1.3 PSK
extension parsing.
CVE-2019-13628 (currently assigned-only): potential leak of nonce sizes
when performing ECDSA signing operations. The leak is considered to be
difficult to exploit but it could potentially be used maliciously to
perform a lattice based timing attack.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Removed options that can't be turned off because we're building with
--enable-stunnel, some of which affect hostapd's Config.in.
Adjusted the title of OCSP option, as OCSP itself can't be turned off,
only the stapling part is selectable.
Mark options turned on when wpad support is selected.
Add building options for TLS 1.0, and TLS 1.3.
Add hardware crypto support, which due to a bug, only works when CCM
support is turned off.
Reorganized option conditionals in Makefile.
Add Eneas U de Queiroz as maintainer.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This includes a fix for a medium-level potential cache attack with a
variant of Bleichenbacher’s attack. Patches were refreshed.
Increased FP_MAX_BITS to allow 4096-bit RSA keys.
Fixed poly1305 build option, and some Makefile updates.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Implicetely selecting the required options via Kconfig snippet from
hostapd worked fine in local builds when using menuconfig but confused
the buildbots which (in phase1) may build wpad-mini and hence already
come with CONFIG_WPA_WOLFSSL being defined as unset which then won't
trigger changing the defaults of wolfssl.
Work around by explicitely reflecting wpa_supplicant's needs in
wolfssl's default settings to make buildbots happy.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Some options' default values have been changed upstream, others were
accidentally inverted (CONFIG_WOLFSSL_HAS_DES3). Also add options
needed to build hostapd/wpa_supplicant against wolfssl.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This is to eliminate any ambiguity about the cyassl/wolfssl lib.
The rename happened some time ago (~3+ years).
As time goes by, people will start to forget cyassl and
start to get confused about the wolfSSL vs cyassl thing.
It's a good idea to keep up with the times (moving forward).
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
