shadowsocks-rust is shadowsocks written in rust, with high performance
for AES AEAD ciphers (while much lower for non-ones).
However with the lack of rust toolchain, by now we can only download
pre-compiled binaries for quick setup and this Makefile needs to be
rewritten when rust toolchain is up.
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
This introduces rockchip ddrloader firmware, which allows
users to control the memory frequency runtime.
Signed-off-by: AmadeusGhost <amadeus@immortalwrt.org>
[fixed binary output and format issues]
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
A compact patch that provides AES and GCM implementations that utilize the
ARMv8 Crypto Extensions. The config flag is MBEDTLS_ARMV8CE_AES_C, which
is disabled by default as we don't do runtime checking for the feature.
The new implementation lives in armv8ce_aes.c.
Provides similar functionality to https://github.com/ARMmbed/mbedtls/pull/432
Thanks to Barry O'Rourke and others for that contribtion.
Tested on a Cortex A53 device and QEMU. On a midrange phone the real AES-GCM
throughput increases about 4x, while raw AES speed is up to 10x faster.
[updated Makefile to enable this function, adjusted commit message]
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
with u-boot v2020.07 some variables have been renamed so this patch needs to be adjusted
otherwise at least with macOS as build system there are build errors
Signed-off-by: Ronny Kotzschmar <ro.ok@me.com>
(cherry picked from commit 547a932ee9)
Non Linux systems e.g. macOS lack the __u64 type and produce build errors:
In file included from tools/aisimage.c:9:
In file included from include/image.h:19:
In file included from ./arch/arm/include/asm/byteorder.h:29:
In file included from include/linux/byteorder/little_endian.h:13:
include/linux/types.h:146:9: error: unknown type name '__u64'; did you mean '__s64'?
typedef __u64 __bitwise __le64;
Resolved by declaring __u64 in include/linux/types.h
Build tested on macOS and Ubuntu.
Signed-off-by: Georgi Valkov <gvalkov@abv.bg>
(cherry picked from commit 3cc57ba462)
p2p_add_device() may remove the oldest entry if there is no room in the
peer table for a new peer. This would result in any pointer to that
removed entry becoming stale. A corner case with an invalid PD Request
frame could result in such a case ending up using (read+write) freed
memory. This could only by triggered when the peer table has reached its
maximum size and the PD Request frame is received from the P2P Device
Address of the oldest remaining entry and the frame has incorrect P2P
Device Address in the payload.
Fix this by fetching the dev pointer again after having called
p2p_add_device() so that the stale pointer cannot be used.
This fixes the following security vulnerabilities/bugs:
- CVE-2021-27803 - A vulnerability was discovered in how p2p/p2p_pd.c
in wpa_supplicant before 2.10 processes P2P (Wi-Fi Direct) provision
discovery requests. It could result in denial of service or other
impact (potentially execution of arbitrary code), for an attacker
within radio range.
Fixes: 17bef1e97a50 ("P2P: Add peer entry based on Provision Discovery Request")
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
(cherry picked from commit 1ca5de13a1)
