This activates some extra checks in SLAB or SLUB to make it harder to
execute kernel heap exploits. This adds a minor performance
degradation which I haven't measured-.
Many mainstream Linux distributions also activate this option.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This activates the following kernel options by default:
* CONFIG_RANDOM_TRUST_CPU
* CONFIG_RANDOM_TRUST_BOOTLOADER
With these option Linux will also use data from the CPU RNG e.g. RDRAND
and the bootloader to initialize the Linux RNG if such sources are
available.
These random bits are used in addition to the other sources, no other
sources are getting deactivated. I read that the Chacha mixer isn't
vulnerable to injected entropy, so this should not be a problem even if
these sources might inject bad random data.
The Linux kernel suggests to activate both options, Debian also
activates them. This does not increase kernel code size.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This applies commit 02ac9c94 to fix this OpenSSL Security Advisory
issued on 20th April 2023[1]:
Input buffer over-read in AES-XTS implementation on 64 bit ARM
(CVE-2023-1255)
==============================================================
Severity: Low
Issue summary: The AES-XTS cipher decryption implementation for 64 bit
ARM platform contains a bug that could cause it to read past the input
buffer, leading to a crash.
Impact summary: Applications that use the AES-XTS algorithm on the 64
bit ARM platform can crash in rare circumstances. The AES-XTS algorithm
is usually used for disk encryption.
The AES-XTS cipher decryption implementation for 64 bit ARM platform
will read past the end of the ciphertext buffer if the ciphertext size
is 4 mod 5 in 16 byte blocks, e.g. 144 bytes or 1024 bytes. If the
memory after the ciphertext buffer is unmapped, this will trigger a
crash which results in a denial of service.
If an attacker can control the size and location of the ciphertext
buffer being decrypted by an application using AES-XTS on 64 bit ARM,
the application is affected. This is fairly unlikely making this issue a
Low severity one.
1. https://www.openssl.org/news/secadv/20230420.txt
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
It was brought to attention the Archer AX23 v1 fails to read jffs2 data
from time to time. While this is not reproducible on my unit, it is on
others.
Reducing the SPI frequency does the trick. While it worked with at lest
40 MHz, opt for the cautious side and choose a save frequency of 25 MHz.
Apply the same treatment to the Mercusys MR70X which uses a similar
design just in case.
Signed-off-by: David Bauer <mail@david-bauer.net>
OpenWrt's developer guide prefers having actual patches so they an be
sent upstream more easily.
However, in the case of hack-5.15 patches which are not meant for
upstream, adding proper fields allows for `git am` to properly function.
This commit tries to rectify that, by digging in the history to find
where and how it was first added.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
- irq_domain_add_simple() can't be used on bmips since interrupts aren't
hardcoded with specific offsets for internal and external as opposed to
bcm63xx. This is needed to avoid collisions with other interrupts.
- remove unused bcm63xx-specific code.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
There's no need to poll the gpio keys every 20 ms and the linux kernel
documentation suggests 100 ms.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Coverity Scan is a static code analysis service focused on open source
software quality and security, so lets scan various OpenWrt components
every Friday for the start.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
The resize tool will resize the prompt to match the current terminal
size. This is helpful when connecting to the system using UART to make
the vi or top output match the current terminal size.
This increases the busybox binary size by 136 bytes and the ipkg size by
335 bytes on aarch64.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The current bcma SPROM extraction from upstream only supports SPROMs with
revisions from 8 to 11.
Let's align the downstream fallback driver with upstream.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
- Remove unneeded mac bytes from struct (it's already present in the SPROM).
- Convert devid_override to boolean.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
- Remove unneeded mac bytes from struct (it's already present in the SPROM).
- Convert devid_override to boolean.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Convert GL-AP1300 to DSA and enable it.
While working on it rename the GL-AP1300 leds from green to white.
Tested-by: Rob White <rob@blue-wave.net>
Tested-by: Robert Sommer <frauhottelmann@gmail.com>
Signed-off-by: Nick Hainke <vincent@systemli.org>
As was done in commit e11d00d44c ("ath79: create Aruba AP-105 APBoot
compatible image"), alter the Aruba AP-175 image generation process so
OpenWrt can be loaded with the vendor Aruba APBoot. Since the
remainder of the explanation and installation process is identical,
continuing the quote from that commit:
This works by prepending the OpenWrt LZMA loader to the uImage and
jumping directly to the loader. Aruba does not offer bootm on these
boards.
This approach keeps compatibility to devices which had their U-Boot
replaced. Both bootloaders can boot the same image.
With this patch, new installations do not require replacing the
bootloader and can be performed from the serial console without
opening the case.
Installation
------------
1. Attach to the serial console of the AP-175.
Interrupt autoboot and change the U-Boot env.
$ setenv apb_rb_openwrt "setenv ipaddr 192.168.1.1;
setenv serverip 192.168.1.66;
netget 0x84000000 ap175.bin; go 0x84000040"
$ setenv apb_fb_openwrt "cp.b 0xbf040000 0x84000000 0x10000;
go 0x84000040"
$ setenv bootcmd "run apb_fb_openwrt"
$ saveenv
2. Load the OpenWrt initramfs image on the device using TFTP.
Place the initramfs image as "ap175.bin" in the TFTP server
root directory, connect it to the AP and make the server reachable
at 192.168.1.66/24.
$ run apb_rb_openwrt
3. Once OpenWrt booted, transfer the sysupgrade image to the device
using scp and use sysupgrade to install the firmware.
Signed-off-by: Martin Kennedy <hurricos@gmail.com>
The previous attempt to replace an open coded paged read in the RealTek
Ethernet PHY driver was too naive and resulted in breaking the r8169
PCIe Ethernet driver which also makes use of the RealTek Ethernet PHY
driver.
Fix this by instead of using the (not yet populated) paged operations
rather use rtl821x_write_page and protect the whole paged read operation
using the MDIO bus mutex.
Fixes: 998b973157 ("kernel: net: phy: realtek: improve RealTek 2.5G PHY driver")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
It was found this device uses a single tri-color power/status LED
rather than individual red/orange LEDs, which also supports green.
Add GPIO for green color and use with `boot` and `running` aliases.
Signed-off-by: Sebastian Schaper <openwrt@sebastianschaper.net>
Reviewed-by: Philip Prindeville <philipp@redfish-solutions.com>
Signed-off-by: David Bauer <mail@david-bauer.net>
- Correct WiFi MACs, they didn't match oem firmware
- Move nvmem-cells to bdinfo partition and remove &bdinfo reference
- Add OEM device model name R13 to SUPPORTED_DEVICES
This allows sysupgrading from Cudy's OpenWrt fork without force
- Label red_led and use it during failsafe mode and upgrades
MAC addresses as verified by OEM firmware:
use address source
LAN b4:4b:d6:2d:c8:4a label
WAN b4:4b:d6:2d:c8:4b label + 1
2g b4:4b:d6:2d:c8:4a label
5g b6:4b:d6:3d:c8:4a label + LA-Bit set + 4th oktet increased
The label MAC address is found in bdinfo 0xde00.
Signed-off-by: Felix Baumann <felix.bau@gmx.de>
[read wifi mac from flash offset]
Signed-off-by: David Bauer <mail@david-bauer.net>
The Alcatel HH40V is a CAT4 LTE router used by various ISPs.
Specifications
==============
SoC: QCA9531 650MHz
RAM: 128MiB
Flash: 32MiB SPI NOR
LAN: 1x 10/100MBit
WAN: 1x 10/100MBit
LTE: MDM9607 USB 2.0 (rndis configuration)
WiFi: 802.11n (SoC integrated)
MAC address assignment
======================
There are three MAC addresses stored in the flash ROM, the assignment
follows stock. The MAC on the label is the WiFi MAC address.
Installation (TFTP)
===================
1. Connect serial console
2. Configure static IP to 192.168.1.112
3. Put OpenWrt factory.bin file as firmware-system.bin
4. Press Power + WPS and plug in power
5. Keep buttons pressed until TFTP requests are visible
6. Wait for the system to finish flashing and wait for reboot
7. Bootup will fail as the kernel offset is wrong
8. Run "setenv bootcmd bootm 0x9f150000"
9. Reset board and enjoy OpenWrt
Installation (without UART)
===========================
Installation without UART is a bit tricky and requires several steps too
long for the commit message. Basic steps:
1. Create configure backup
2. Patch backup file to enable SSH
3. Login via SSH and configure the new bootcmd
3. Flash OpenWrt factory.bin image manually (sysupgrade doesn't work)
More detailed instructions will be provided on the Wiki page.
Tested by: Christian Heuff <christian@heuff.at>
Signed-off-by: Andreas Böhler <dev@aboehler.at>
The RTL8366S/RB switch node in DTS defines "mii-bus = <&mdio0>" to permit
management via SMI but this has likely never worked, instead falling back
to using GPIOs in the past:
rtl8366s switch: cannot find mdio bus from bus handle (yet)
rtl8366s switch: using GPIO pins 19 (SDA) and 20 (SCK)
rtl8366s switch: RTL8366 ver. 1 chip found
Recently, the rtl8366s and rtl8366_smi drivers were changed from built-in
to loadable modules. This affected driver probing order and caused switch
initialization (and network access) to fail:
rtl8366s switch: using MDIO bus 'ag71xx_mdio'
rtl8366s switch: unknown chip id (ffff)
rtl8366s switch: chip detection failed, err=-19
Force using GPIOs to manage the switch by dropping the "mii-bus" DTS
definition, which works for both built-in and loadable switch drivers.
Fixes: 6e0f0eae5b ("ath79: use rtl8366s and rtl8366_smi as a module")
Fixes: 575ec7a4b1 ("ath79: use rtl8366rb as a module")
Tested-by: Tony Ambardar <itugrok@yahoo.com> # WZR-HP-G300NH (RTL8366S)
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
Switch drivers for RTL8366S/RB were packaged as modules but not properly
added to device definitions for WZR-HP-G300NH router variants, breaking
network access to both after installation or upgrade.
Assign the correct switch driver package for each router.
Fixes: 6e0f0eae5b ("ath79: use rtl8366s and rtl8366_smi as a module")
Fixes: 575ec7a4b1 ("ath79: use rtl8366rb as a module")
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
This fixes a well known "LZMA ERROR 1" error, reported previously on
numerous of similar devices.
Fixes: #11919
Signed-off-by: Haoan Li <lihaoan1001@163.com>
Apart from the embedded BCM63268 wireless, this device has an external BCM4360
connected by PCIe which needs a fallback SPROM.
b43 isn't enabled for this device because BCM4360 isn't supported (AC PHY).
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Apart from the embedded BCM6362 wireless, Netgear DGND3700v2 has external
BCM43228 wireless connected by PCIe.
Fallback SPROM isn't needed for this one because it has a physical SPROM.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
late_initcall_sync() is no longer needed so standard module functions can be
used on all bmips PCI/PCIe drivers.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
By default both kmod-bcma and kmod-ssb are selected by kmod-b43.
However, only one of both modules is needed for bmips subtargets:
- bcma: bcm6318, bcm6328, bcm6362, bcm63268
- ssb: bcm6358, bcm6368
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Stop using bmips b43-sprom fixups and switch to generic bcma/ssb fallback
SPROMs. This way we don't need to include the b43-sprom fixups on devices
without Broadcom wireless.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
This adds generic kernel support for Broadcom Fallback SPROMs so that it can be
used in any target, even non Broadcom ones.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
This adds a new package with Broadcom SPROMs that can be used as fallback when
the devices lack physical SPROMs.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
A patch was added in kernel 5.4 to support the fiber operation of
AR8033 with ramips devices. In kernel 5.18 similar enhancements
were added to the kernel. Those patches are required for other
fiber based devices but when added, build fails for ramips targets.
This commit removes the ramips patch and adds the kernel 5.18 ones.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
[ split commit,refresh patch and improve commit message ]
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
A patch was added in kernel 5.4 to support the fiber operation of
AR8033 with ramips devices. In kernel 5.18 similar enhancements
were added to the kernel. Those patches are required for other
fiber based devices but when added, build fails for ramips targets.
This commit removes the ramips patch and adds the kernel 5.18 ones.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
[ split commit, refresh patch and improve commit title ]
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Replace pending 730-net-phy-at803x-fix-feature-detection.patch with
upstream version and move it to backport.
Refresh other related patch while moving it.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Upload proposed refreshed patches if the check fails.
This should help devs refresh the patches if they don't have access to a
buildroot.
Devs should ALWAYS refresh the patches before submitting and merging
commits.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The patch needs to be refreshed to apply cleanly.
Fixes: 998b973157 ("kernel: net: phy: realtek: improve RealTek 2.5G PHY driver")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Hardware specification:
SoC: MediaTek MT7986A 4x A53
Flash: ESMT F50L1G41LB 128MB
RAM: ESMT M15T4G16256A 512MB
Ethernet (Max Speed):
XDR4288: 1x 2.5G Wan, 1x 2.5G Lan, 4x 1G Lan
XDR6086: 1x 2.5G Wan, 1x 2.5G Lan, 1x 1G Lan
XDR6088: 1x 2.5G Wan, 1x 2.5G Lan, 4x 1G Lan
WiFi:
XDR4288: MT7976DAN (2.4G 2T2R, 5G 3T3R)
XDR6086/XDR6088:
WiFi1: MT7976GN 2.4GHz 4T4R
WiFi2: MT7976AN 5GHz 4T4R
Button: Reset, WPS, Turbo
USB: 1 x USB 3.0
Power: DC 12V 4A
Flash instructions:
1. Execute the following operation to open nc shell:
https://openwrt.org/inbox/toh/tp-link/xdr-6086#rooting
2. Replace the stock bootloader to OpenWrt's:
dd bs=131072 conv=sync of=/dev/mtdblock9 if=/tmp/xxx-preloader.bin
dd bs=131072 conv=sync of=/dev/mtdblock9 seek=28 if=/tmp/xxx-bl31-uboot.fip
3. Connect to your PC via the Gigabit port of the router,
set a static ip on the ethernet interface of your PC.
(ip 192.168.1.254, gateway 192.168.1.1)
4. Download the initramfs image, and restart the router,
waiting for tftp recovery to complete.
5. After openwrt boots up, perform sysupgrade.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
[Add uboot build, fit and sysupgrade support, fix RealTek PHYs]
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
TP-Link TL-XDR608x comes with locked vendor loader. Add U-Boot build
for replacement loader for both TL-XDR6086 and TL-XDR6088. The only
difference at U-Boot level is the different filename requested via
TFTP, matching the corresponding OpenWrt build artifacts for each
device.
The TP-Link TL-XDR4288 has the same hardware as the TP-Link TL-XDR6088
except for the wireless part. Also create a uboot for the TP-Link
TL-XDR4288.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
[rebase to uboot 23.04, correct led and button]
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
* use interface mode switching only when operating in C45 mode
Linux prevents switching the interface mode when using C22 MDIO,
hence use rate-adapter mode in case the PHY controlled via C22.
* use phy_read_paged where appropriate
* use existing generic inline functions to handle 10GbE advertisements
instead of redundantly defining register macros in realtek.c which
are not actually vendor-specific.
* make sure 10GbE advertisement is valid, preventing false-positive
warning "Downshift occurred from negotiated speed 2.5Gbps to actual
speed 1Gbps, check cabling!" with some link-partners using 1G mode.
* Support Link Down Power Saving Mode (ALDPS)
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
