This activates CONFIG_HARDENED_USERCOPY for the remaining targets. This
adds additional checks in the copy_from_user() and copy_to_user()
functions.
This was not activated for ARCHS38 before because of a bug in the Linux
kernel 5.4 till 5.14, which as fixed and is described here:
https://github.com/foss-for-synopsys-dwc-arc-processors/linux/issues/15
I do not know why this was deactivated for mt7629 and rockchip.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The ZyXEL WSM20 aka Multy M1 is a cheap mesh router system by ZyXEL
based on the MT7621 CPU.
Specifications
==============
SoC: MediaTek MT7621AT (880MHz)
RAM: 256MiB
Flash: 128MiB NAND
Wireless: 802.11ax (2x2 MT7915E DBDC)
Ethernet: 4x 10/100/1000 (MT7530)
Button: 1x WPS, 1x Reset, 1x LED On/Off
LED: 7 LEDs (3x white, 2x red, 2x green)
MAC address assignment
======================
The MAC address assignment follows stock: The label MAC address is the LAN
MAC address, the WAN address is read from flash.
The WiFi MAC addresses are set in userspace to label MAC + 1 and label MAC
+ 2.
Installation (web interface)
============================
The device is cloud-managed, but there is a hidden local firmware upgrade
page in the OEM web interface. The device has to be registered in the
cloud in order to be able to access this page.
The system has a dual firmware design, there is no way to tell which
firmware is currently booted. Therefore, an -initramfs version is flashed
first.
1. Log into the OEM web GUI
2. Access the hidden upgrade page by navigating to
https://192.168.212.1/gui/#/main/debug/firmwareupgrade
3. Upload the -initramfs-kernel.bin file and flash it
4. Wait for OpenWrt to boot and log in via SSH
5. Transfer the sysupgrade file via SCP
6. Run sysupgrade to install the image
7. Reboot and enjoy
NB: If the initramfs version was installed in RAS2, the sysupgrade script
sets the boot number to the first partition. A backup has to be performed
manually in case the OEM firwmare should be kept.
Installation (UART method)
==========================
The UART method is more difficult, as the boot loader does not have a
timeout set. A semi-working stock firmware is required to configure it:
1. Attach UART
2. Boot the stock firmware until the message about failsafe mode appears
3. Enter failsafe mode by pressing "f" and "Enter"
4. Type "mount_root"
5. Run "fw_setenv bootmenu_delay 3"
6. Reboot, U-Boot now presents a menu
7. The -initramfs-kernel.bin image can be flashed using the menu
8. Run the regular sysupgrade for a permanent installation
Changing the partition to boot is a bit cumbersome in U-Boot, as there is
no menu to select it. It can only be checked using mstc_bootnum. To change
it, issue the following commands in U-Boot:
nand read 1800000 53c0000 800
mw.b 1800004 1 1
nand erase 53c0000 800
nand write 1800000 53c0000 800
This selects FW1. Replace "mw.b 1800004 1 1" by "mw.b 1800004 2 1" to
change to the second slot.
Back to stock
=============
It is possible to flash back to stock, but a OEM firmware upgrade is
required. ZyXEL does not provide the link on its website, but the link
can be acquired from the OEM web GUI by analyzing the transferred JSON
objects.
It is then a matter of writing the firmware to Kernel2 and setting the
boot partition to FW2:
mtd write zyxel.bin Kernel2
echo -ne "\x02" | dd of=/dev/mtdblock7 count=1 bs=1 seek=4 conv=notrunc
Signed-off-by: Andreas Böhler <dev@aboehler.at>
Credits to forum users Annick and SirLouen for their initial work on this
device
In MBIM interfaces, DNS servers may be provided out-of-band regardless
whether DHCP is used for configuration, or not. Move the DNS
configuration outside "if" blocks to support that.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Beginnings and endings of sub-interface creation procedure were
literally duplicates - extract them outside if "if" blocks
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Allow setting interface MTU through UCI. If this is not set,
use MBIM-provided MTU, if provided through control channel.
If separate MTUs are provided for IPv4 and IPv6, apply larger of them.
This is very unlikely and possible only for IPv4v6 dual-stack configuration.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Delegate prefixes received through MBIM control channel the same way, as
would be done through DHCP, according to RFC7278.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
MBIM supports multiple values for IP address and DNS server, and such
configuration is available through output of MBIM. Use new helper
method to support adding multiple addresses and DNS servers to static
interfaces for both IPv4 and IPv6.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Add a new helper to extract IP configuration from umbim output. This is
required to extract fields which can possibly have multiple values,
namely IP addresses and DNS servers, and get rid of primitive parser
using 'eval' builtin without support for this.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Display full configuration obtained using MBIM control channel in the
log, from umbim output verbatim, for easier troubleshooting, and in
preparation for parser refactoring.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Inspired by commti e51aa699f7, allow setting specific routing tables
via ip4table and ip6table options, by passing them on child interfaces
created by MBIM protocol handler.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Finally, inspired by ModemManager's logic, make static configuration
obtained through MBIM control channel, preferred.
If IP configuration is not available this way, fallback to DHCP(v6) if
enabled, else do not create a sub-interface for unavailable IP type.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Now, that sub-interface setup is split by IP type, and separate checks
are performed for DHCP selection, it is possible to control DHCP on v4
an v6 sub-interfaces instantly. Add "dhcpv6" variable, akin to QMI
option, to control behaviour of DHCPv6 separately from IPv4 option,
which is required for some mobile operators.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Check whether interface is configured per IP type, not per DHCP. This is
preparation to allow fallback to DHCP if static IP configuration is not
available, which is the default option for MBIM modems
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Fix an issue where subinterfaces were not added to the same
firewall zone as their parent.
Inspired by 64bb88841f.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
MBIM protocol handler should intherit "peerdns" options from parent
interface on sub-interfaces, otherwise upstream DNS servers are applied
regardless of configuration.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Previously, DHCP was used. According to MBIM Specification v1.0 errata 1 [1],
section 10.5.20, MBIM_CID_IP_CONFIGURATION,
if MBIM information element containing IP configuration is available,
host shall use it, and fall back to in-band mechanisms to acquire it therwise -
therefore make static configuration the default.
[1] https://www.usb.org/document-library/mobile-broadband-interface-model-v10-errata-1-and-adopters-agreement
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Current implementation needlessly creates both IPv4 and IPv6
sub-interfaces for single-stack IP types. Limit this only to selected IP
type. While at that, ensure that IP type is also passed to umbim during
"connect" phase. In addition, detect the actual established connection
type returned by umbim and set up subinterfaces according to that,
not to requested configuration. While at that, allow empty IP type explicitly,
interpreted as "any" according to MBIM specification.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Subsequent calls to 'umbim connect' do not have any effect if a failure
occured, and in such case an infinite loop without timeout is created,
leading to possibility of interface stuck at connecting forever.
Drop this loop, and issue MBIM disconnect properly, so netifd can
restart from scratch.
This issue can be observed with Sierra EM7455 at changing APN, which
causes network re-registration by default, and a MBIM transaction
timeout, which is resolved on next interface bringup by netifd.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Previous implementation automatically set up connections for both IPv4
and IPv6, even if one of them isn't supported. Respect the "pdptype"
option in the same way, as it is done for QMI or NCM, and only start the
respective PDN sessions, if set.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
There are mbim compatible wwan modules available which do not support
the dhcp autoconfiguration. (e.g. gemalto Cinterion ELS81)
This adds the possibility to get the configuration parameters from mbim.
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
This activates the CONFIG_SCHED_STACK_END_CHECK option.
The kernel will check if the kernel stack overflowed in the schedule()
function. This just adds a very small computational overhead.
This option is activated in Debian by default.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
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>
