Re: [OpenWrt-Devel] New OpenWrt logo proposal [Was: Re: [RFC]new "corporate identity" for OpenWrt & static rendering]
Hi Petr, On 14/01/20 4:57 PM, Petr Štetiar wrote: > Petr Štetiar [2020-01-08 22:47:28]: > > 1. > https://forum.openwrt.org/t/help-pre-select-new-openwrt-project-logo-in-the-poll/52674 All of them are nice and I have voted for the one I liked. I have a thought here. As far as I see and use, OpenWrt doesn't stand just for wireless freedom, though that's the most popular use case. It is being used as a base for various functions related but not limited to meshing, routing, network security, IoT and anything or everything that one can imagine or implement with additional packages. It gives us such a "freedom" and helps us protect our "privacy". The logo "H" represents the versatility, but misses the wireless. Regards, Nishant ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] mediatek: use consistent naming scheme for device nodes
This harmonizes the device node names (and thus the image names, too) between subtargets of the mediatek target. So far, each subtarget has somewhat used its own naming scheme. Now, we use the vendor_device syntax there, too. Since DTS names have different patterns and the target only contains a few devices, this does not replace DEVICE_DTS by a calculated default value (like for other targets). SUPPORTED_DEVICES is adjusted based on the node rename where necessary, though it looks like for several older devices it was not set up correctly so far. While at it, this also changes the DTS name for u7623-02-emmc-512m to all-lower-case. Cc: John Crispin Signed-off-by: Adrian Schmutzler --- target/linux/mediatek/image/mt7622.mk | 14 -- target/linux/mediatek/image/mt7623.mk | 14 ++ target/linux/mediatek/image/mt7629.mk | 1 - .../0227-arm-dts-Add-Unielec-U7623-DTS.patch | 8 .../0227-arm-dts-Add-Unielec-U7623-DTS.patch | 8 5 files changed, 22 insertions(+), 23 deletions(-) diff --git a/target/linux/mediatek/image/mt7622.mk b/target/linux/mediatek/image/mt7622.mk index b84a3a6b50..9a5aedc88d 100644 --- a/target/linux/mediatek/image/mt7622.mk +++ b/target/linux/mediatek/image/mt7622.mk @@ -1,4 +1,4 @@ -define Device/MTK-RFB1 +define Device/mediatek_mt7622-rfb1 DEVICE_VENDOR := MediaTek DEVICE_MODEL := MTK7622 rfb1 AP DEVICE_DTS := mt7622-rfb1 @@ -6,24 +6,26 @@ define Device/MTK-RFB1 DEVICE_PACKAGES := kmod-usb-ohci kmod-usb2 kmod-usb3 \ kmod-ata-core kmod-ata-ahci-mtk endef -TARGET_DEVICES += MTK-RFB1 +TARGET_DEVICES += mediatek_mt7622-rfb1 -define Device/MTK-LYNX-RFB1 +define Device/mediatek_mt7622-lynx-rfb1 DEVICE_VENDOR := MediaTek DEVICE_MODEL := MTK7622 Lynx rfb1 AP DEVICE_DTS := mt7622-lynx-rfb1 DEVICE_DTS_DIR := $(DTS_DIR)/mediatek + SUPPORTED_DEVICES := mediatek,mt7622-rfb1 DEVICE_PACKAGES := kmod-usb-ohci kmod-usb2 kmod-usb3 \ kmod-ata-core kmod-ata-ahci-mtk endef -TARGET_DEVICES += MTK-LYNX-RFB1 +TARGET_DEVICES += mediatek_mt7622-lynx-rfb1 -define Device/BPI-R64 +define Device/lemaker_bananapi-bpi-r64 DEVICE_VENDOR := LeMaker DEVICE_MODEL := Banana Pi R64 DEVICE_DTS := mt7622-bananapi-bpi-r64 DEVICE_DTS_DIR := $(DTS_DIR)/mediatek + SUPPORTED_DEVICES := bananapi,bpi-r64 DEVICE_PACKAGES := kmod-usb-ohci kmod-usb2 kmod-usb3 \ kmod-ata-core kmod-ata-ahci-mtk endef -TARGET_DEVICES += BPI-R64 +TARGET_DEVICES += lemaker_bananapi-bpi-r64 diff --git a/target/linux/mediatek/image/mt7623.mk b/target/linux/mediatek/image/mt7623.mk index 3f72979849..fd609d22fa 100644 --- a/target/linux/mediatek/image/mt7623.mk +++ b/target/linux/mediatek/image/mt7623.mk @@ -1,20 +1,18 @@ -define Device/7623a-unielec-u7623-02-emmc-512m +define Device/unielec_u7623-02-emmc-512m DEVICE_VENDOR := UniElec DEVICE_MODEL := U7623-02 DEVICE_VARIANT := eMMC/512MB RAM - DEVICE_DTS := mt7623a-unielec-u7623-02-emmc-512M + DEVICE_DTS := mt7623a-unielec-u7623-02-emmc-512m DEVICE_PACKAGES := mkf2fs e2fsprogs kmod-fs-vfat kmod-nls-cp437 kmod-nls-iso8859-1 kmod-mmc - SUPPORTED_DEVICES := unielec,u7623-02-emmc-512m IMAGES := sysupgrade-emmc.bin.gz IMAGE/sysupgrade-emmc.bin.gz := sysupgrade-emmc | gzip | append-metadata endef +TARGET_DEVICES += unielec_u7623-02-emmc-512m -TARGET_DEVICES += 7623a-unielec-u7623-02-emmc-512m - -define Device/7623n-bananapi-bpi-r2 +define Device/lemaker_bananapi-bpi-r2 DEVICE_VENDOR := LeMaker DEVICE_MODEL := Banana Pi R2 DEVICE_DTS := mt7623n-bananapi-bpi-r2 + SUPPORTED_DEVICES := bananapi,bpi-r2 endef - -TARGET_DEVICES += 7623n-bananapi-bpi-r2 +TARGET_DEVICES += lemaker_bananapi-bpi-r2 diff --git a/target/linux/mediatek/image/mt7629.mk b/target/linux/mediatek/image/mt7629.mk index ba1daefa03..71fb3dda09 100644 --- a/target/linux/mediatek/image/mt7629.mk +++ b/target/linux/mediatek/image/mt7629.mk @@ -5,4 +5,3 @@ define Device/mediatek_mt7629-lynx-rfb DEVICE_PACKAGES := swconfig endef TARGET_DEVICES += mediatek_mt7629-lynx-rfb - diff --git a/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch b/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch index 996b309e8f..46fc9abab9 100644 --- a/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch +++ b/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch @@ -5,10 +5,10 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS --- arch/arm/boot/dts/Makefile | 1 + - .../dts/mt7623a-unielec-u7623-02-emmc-512M.dts | 18 + + .../dts/mt7623a-unielec-u7623-02-emmc-512m.dts | 18 + .../boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi| 366 + 3 files changed, 385 insertions(+) - create mode 100644 arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc-512M.dts + create mode
[OpenWrt-Devel] [RFC RFT PATCH 2/2] mediatek: mt7623: add back images for mt7623a-rfb-emmc
The image creation for the mt7623a-rfb-emmc has been removed during
a patch refresh without specific comment. The corresponding base-files
entries are still there, and the DTS is still present in kernel.
This adds back the corresponding image definition.
While at it, apply alphabetic sorting to Makefile.
Fixes: 050da2107a7e ("mediatek: backport upstream mediatek patches")
Cc: John Crispin
Signed-off-by: Adrian Schmutzler
---
target/linux/mediatek/image/mt7623.mk | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/target/linux/mediatek/image/mt7623.mk
b/target/linux/mediatek/image/mt7623.mk
index fd609d22fa..ab08ca83a3 100644
--- a/target/linux/mediatek/image/mt7623.mk
+++ b/target/linux/mediatek/image/mt7623.mk
@@ -1,3 +1,19 @@
+define Device/lemaker_bananapi-bpi-r2
+ DEVICE_VENDOR := LeMaker
+ DEVICE_MODEL := Banana Pi R2
+ DEVICE_DTS := mt7623n-bananapi-bpi-r2
+ SUPPORTED_DEVICES := bananapi,bpi-r2
+endef
+TARGET_DEVICES += lemaker_bananapi-bpi-r2
+
+define Device/mediatek_mt7623a-rfb-emmc
+ DEVICE_VENDOR := MediaTek
+ DEVICE_MODEL := MT7623A reference board
+ DEVICE_VARIANT := eMMC
+ DEVICE_DTS := mt7623a-rfb-emmc
+endef
+TARGET_DEVICES += mediatek_mt7623a-rfb-emmc
+
define Device/unielec_u7623-02-emmc-512m
DEVICE_VENDOR := UniElec
DEVICE_MODEL := U7623-02
@@ -8,11 +24,3 @@ define Device/unielec_u7623-02-emmc-512m
IMAGE/sysupgrade-emmc.bin.gz := sysupgrade-emmc | gzip | append-metadata
endef
TARGET_DEVICES += unielec_u7623-02-emmc-512m
-
-define Device/lemaker_bananapi-bpi-r2
- DEVICE_VENDOR := LeMaker
- DEVICE_MODEL := Banana Pi R2
- DEVICE_DTS := mt7623n-bananapi-bpi-r2
- SUPPORTED_DEVICES := bananapi,bpi-r2
-endef
-TARGET_DEVICES += lemaker_bananapi-bpi-r2
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: wlr-7100: use ath10k-ct smallbuffers package variant
The memory hacks got removed from ath10k with 1e27bef ("mac80211: remove
ath10k_pci memory hacks"). As this device has low amount of RAM, switch
to ath-10k-ct small buffers variant, to avoid the OOM Reaper.
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/ath79/image/generic.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ath79/image/generic.mk
b/target/linux/ath79/image/generic.mk
index 18dad80d5d..abc6f96a80 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -986,7 +986,7 @@ define Device/sitecom_wlr-7100
DEVICE_VENDOR := Sitecom
DEVICE_MODEL := WLR-7100
DEVICE_VARIANT := v1 002
- DEVICE_PACKAGES := ath10k-firmware-qca988x kmod-ath10k kmod-usb2
+ DEVICE_PACKAGES := ath10k-firmware-qca988x-ct kmod-ath10k-ct-smallbuffers
kmod-usb2
IMAGES += factory.dlf
IMAGE/factory.dlf := append-kernel | pad-to (BLOCKSIZE) | \
append-rootfs | pad-rootfs | check-size (IMAGE_SIZE) | \
--
2.24.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 0/3] x86: upgrade bootloader on sysupgrade
After gotten bit more familiar with OpenWrt, I found less intrusive method to implement upgrading of bootloader, instead of rewriting image generation code like in my previous attempt [1]. It had some value in itself, so if anyone will request it, I'll respin these patches as separate series in near future. To expand a bit the explanation "Why this series?", please consult [2] and the conversation in that letter. 1. https://patchwork.ozlabs.org/cover/1024165 2. https://patchwork.ozlabs.org/cover/1000625 Changes in v3: rebase on top of master Changes in v2: x86: add bootloader upgrade on sysupgrade: move bootloader upgrade to function as suggested by Petr ??tetiar, extend commit message x86: add preinit hook for bootloader upgrade rewrite commit message Tomasz Maciej Nowak (3): x86: image: cleanup before creating image x86: add bootloader upgrade on sysupgrade x86: add preinit hook for bootloader upgrade package/boot/grub2/Makefile | 5 .../lib/preinit/81_upgrade_bootloader | 19 ++ .../x86/base-files/lib/upgrade/platform.sh| 25 +++ target/linux/x86/image/Makefile | 9 --- 4 files changed, 55 insertions(+), 3 deletions(-) create mode 100644 target/linux/x86/base-files/lib/preinit/81_upgrade_bootloader -- 2.24.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 1/3] x86: image: cleanup before creating image
There can be some leftovers from other image recipes, if the same directory names are used and multiply image types are selected. Therefore remove directories used in the recipe, before contents for the image are prepared. Signed-off-by: Tomasz Maciej Nowak --- target/linux/x86/image/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/target/linux/x86/image/Makefile b/target/linux/x86/image/Makefile index eb0db417a3..2838b3139c 100644 --- a/target/linux/x86/image/Makefile +++ b/target/linux/x86/image/Makefile @@ -60,6 +60,7 @@ ifneq ($(CONFIG_GRUB_IMAGES),) define Image/Build/grub2 # left here because the image builder doesnt need these + rm -fR $(KDIR)/root.grub $(KDIR)/grub2 $(INSTALL_DIR) $(KDIR)/root.grub/boot/grub $(KDIR)/grub2 $(CP) $(KDIR)/bzImage $(KDIR)/root.grub/boot/vmlinuz grub-mkimage \ @@ -93,6 +94,7 @@ ifneq ($(CONFIG_GRUB_IMAGES),) endif define Image/Build/iso + rm -fR $(KDIR)/root.grub $(KDIR)/grub2 $(INSTALL_DIR) $(KDIR)/root.grub/boot/grub $(KDIR)/grub2 $(CP) $(KDIR)/bzImage $(KDIR)/root.grub/boot/vmlinuz grub-mkimage \ -- 2.24.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 3/3] x86: add preinit hook for bootloader upgrade
This commit fills the void for current OpenWrt installations which will
be still on old bootloader version even after "x86: add bootloader
upgrade on sysupgrade", since it performs bootloader upgrade only on
sysupgrade. To keep all OpenWrt deploynents on the same GRUB version,
add preinit hook, which will perform upgrade of the bootloader on first
boot after sysupgrade.
It's temporary solution and should be deleted, when the first release
including this hook will no longer be supported by OpenWrt team.
We can assume that all installations should be on current bootolader
version and from there sysupgrade routine will be sufficient.
Signed-off-by: Tomasz Maciej Nowak
---
.../lib/preinit/81_upgrade_bootloader | 19 +++
.../x86/base-files/lib/upgrade/platform.sh| 3 ++-
2 files changed, 21 insertions(+), 1 deletion(-)
create mode 100644
target/linux/x86/base-files/lib/preinit/81_upgrade_bootloader
diff --git a/target/linux/x86/base-files/lib/preinit/81_upgrade_bootloader
b/target/linux/x86/base-files/lib/preinit/81_upgrade_bootloader
new file mode 100644
index 00..3a4e756b1e
--- /dev/null
+++ b/target/linux/x86/base-files/lib/preinit/81_upgrade_bootloader
@@ -0,0 +1,19 @@
+#!/bin/sh
+
+upgrade_bootloader() {
+ local diskdev
+
+ . /lib/upgrade/common.sh
+
+ if [ ! -f /boot/grub/upgraded ] && export_bootdevice &&
export_partdevice diskdev 0; then
+ echo "(hd0) /dev/$diskdev" > /tmp/device.map
+ /usr/sbin/grub-bios-setup \
+ -m "/tmp/device.map" \
+ -d "/boot/grub" \
+ -r "hd0,msdos1" \
+ "/dev/$diskdev" \
+ && touch /boot/grub/upgraded
+ fi
+}
+
+[ "$INITRAMFS" = "1" ] || boot_hook_add preinit_main upgrade_bootloader
diff --git a/target/linux/x86/base-files/lib/upgrade/platform.sh
b/target/linux/x86/base-files/lib/upgrade/platform.sh
index 8be96dfcd4..53c751861c 100644
--- a/target/linux/x86/base-files/lib/upgrade/platform.sh
+++ b/target/linux/x86/base-files/lib/upgrade/platform.sh
@@ -60,7 +60,8 @@ platform_do_bootloader_upgrade() {
-m "/tmp/device.map" \
-d "/tmp/boot/boot/grub" \
-r "hd0,msdos1" \
- "/dev/$diskdev"
+ "/dev/$diskdev" \
+ && touch /boot/grub/upgraded
umount /tmp/boot
fi
--
2.24.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 2/3] x86: add bootloader upgrade on sysupgrade
Currently bootloader always stays on the same version as when first
written to boot medium (not true if partition layout changed, which will
trigger sysupgrade process to write full disk image). That creates
inconveniences as it always stays with same features or/and bugs. Users
wishing to add support to additional modules or new version, would need
to write the whole image, potentially destroying previous system
configuration. To fix these, this commit adds additional routine to
sysupgrade which upgrades unconditionally the bootloader to the latest
state provided by OpenWrt.
Signed-off-by: Tomasz Maciej Nowak
---
package/boot/grub2/Makefile | 5
.../x86/base-files/lib/upgrade/platform.sh| 24 +++
target/linux/x86/image/Makefile | 7 +++---
3 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/package/boot/grub2/Makefile b/package/boot/grub2/Makefile
index 1f92ba9250..b26ef64ca4 100644
--- a/package/boot/grub2/Makefile
+++ b/package/boot/grub2/Makefile
@@ -82,6 +82,11 @@ define Host/Configure
$(Host/Configure/Default)
endef
+define Package/grub2/install
+ $(INSTALL_DIR) $(1)/usr/sbin
+ $(INSTALL_BIN) $(PKG_BUILD_DIR)/grub-bios-setup $(1)/usr/sbin/
+endef
+
define Package/grub2-editenv/install
$(INSTALL_DIR) $(1)/usr/sbin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/grub-editenv $(1)/usr/sbin/
diff --git a/target/linux/x86/base-files/lib/upgrade/platform.sh
b/target/linux/x86/base-files/lib/upgrade/platform.sh
index 3b6c25877f..8be96dfcd4 100644
--- a/target/linux/x86/base-files/lib/upgrade/platform.sh
+++ b/target/linux/x86/base-files/lib/upgrade/platform.sh
@@ -1,3 +1,5 @@
+RAMFS_COPY_BIN='grub-bios-setup'
+
platform_check_image() {
local diskdev partdev diff
[ "$#" -gt 1 ] && return 1
@@ -44,6 +46,26 @@ platform_copy_config() {
fi
}
+platform_do_bootloader_upgrade() {
+ local bootpart
+ local diskdev="$1"
+
+ if export_partdevice bootpart 1; then
+ mkdir -p /tmp/boot
+ mount -o rw,noatime "/dev/$bootpart" /tmp/boot
+ echo "(hd0) /dev/$diskdev" > /tmp/device.map
+
+ echo "Upgrading bootloader on /dev/$diskdev..."
+ grub-bios-setup \
+ -m "/tmp/device.map" \
+ -d "/tmp/boot/boot/grub" \
+ -r "hd0,msdos1" \
+ "/dev/$diskdev"
+
+ umount /tmp/boot
+ fi
+}
+
platform_do_upgrade() {
local diskdev partdev diff
@@ -92,4 +114,6 @@ platform_do_upgrade() {
#copy partition uuid
echo "Writing new UUID to /dev/$diskdev..."
get_image "$@" | dd of="/dev/$diskdev" bs=1 skip=440 count=4 seek=440
conv=fsync
+
+ platform_do_bootloader_upgrade "$diskdev"
}
diff --git a/target/linux/x86/image/Makefile b/target/linux/x86/image/Makefile
index 2838b3139c..373f2396b7 100644
--- a/target/linux/x86/image/Makefile
+++ b/target/linux/x86/image/Makefile
@@ -66,11 +66,11 @@ ifneq ($(CONFIG_GRUB_IMAGES),)
grub-mkimage \
-p /boot/grub \
-d $(STAGING_DIR_HOST)/lib/grub/i386-pc \
- -o $(KDIR)/grub2/core.img \
+ -o $(KDIR)/root.grub/boot/grub/core.img \
-O i386-pc \
-c ./grub-early.cfg \
$(GRUB2_MODULES)
- $(CP) $(STAGING_DIR_HOST)/lib/grub/i386-pc/*.img $(KDIR)/grub2/
+ $(CP) $(STAGING_DIR_HOST)/lib/grub/i386-pc/*.img
$(KDIR)/root.grub/boot/grub/
echo '(hd0) $(BIN_DIR)/$(IMG_COMBINED)-$(1).img' >
$(KDIR)/grub2/device.map
sed \
-e 's#@SERIAL_CONFIG@#$(strip $(GRUB_SERIAL_CONFIG))#g' \
@@ -80,6 +80,7 @@ ifneq ($(CONFIG_GRUB_IMAGES),)
-e 's#@TITLE@#$(GRUB_TITLE)#g' \
./grub.cfg > $(KDIR)/root.grub/boot/grub/grub.cfg
-$(CP) $(STAGING_DIR_ROOT)/boot/. $(KDIR)/root.grub/boot/
+ grub-bios-setup -V | cut -d' ' -f3 > $(KDIR)/root.grub/boot/grub/version
PADDING="1" SIGNATURE="$(IMG_PART_SIGNATURE)" PATH="$(TARGET_PATH)"
$(SCRIPT_DIR)/gen_image_generic.sh \
$(BIN_DIR)/$(IMG_COMBINED)-$(1).img \
$(CONFIG_TARGET_KERNEL_PARTSIZE) $(KDIR)/root.grub \
@@ -87,7 +88,7 @@ ifneq ($(CONFIG_GRUB_IMAGES),)
256
grub-bios-setup \
--device-map="$(KDIR)/grub2/device.map" \
- -d "$(KDIR)/grub2" \
+ -d "$(KDIR)/root.grub/boot/grub" \
-r "hd0,msdos1" \
"$(BIN_DIR)/$(IMG_COMBINED)-$(1).img"
endef
--
2.24.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][libubox] blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Hello,
On Sun, Jan 12, 2020 at 01:09:57PM +0100, Petr Štetiar wrote:
> > @@ -35,10 +35,16 @@ static bool blobmsg_check_name(const struct blob_attr
> > *attr, size_t len, bool na
> > char *limit = (char *) attr + len;
> > const struct blobmsg_hdr *hdr;
> >
> > + if (len < sizeof(struct blob_attr) + sizeof(struct blobmsg_hdr))
> > + return false;
> > +
>
> why is this change needed? If I'm reading it correctly, then
> blobmsg_check_name
> is only called from blobmsg_check_attr_len and there is already much stricter
> guard:
> bool blobmsg_check_attr_len(const struct blob_attr *attr, bool name, size_t
> len)
> {
> if (len < sizeof(struct blob_attr))
> return false;
>
> if (!blobmsg_check_name(attr, len, name))
> return false;
>
I wasn't sure what the best placement for the check would be, so I put it into
the blobmsg_check_name function.
My rationale however was that the existing check in blobmsg_check_attr_len
checks whether we have enough data to call blobmsg_check_name at all, as it
uses attr as a blob_attr struct. The check was added because sizeof(struct
blob_attr) is only 4, as it contains a uint32_t and a flexible array member.
The size of the struct containing the flexible array member is as if it was
omitted when doing a sizeof of the struct, as specified by the C standards from
C99 upwards if I recall correctly. Therefore, another len check in
blobmsg_check_name is added to check if there is enough data in attr->data so
that it makes sense to call blob_data(attr), as otherwise, if the struct has
only the first 4 bytes filled in, the flexible array attr->data is empty, so
hdr->namelen will access unused memory which causes the oob read.
Here is the xxd output for the crash file that causes the invalid read when
passed as data to blobmsg_parse_array with a len of 4:
xxd crash-a3585b70f1c7ffbdec10f6dadc964336118485c4
: 0300 0004
Here is the relevant valgrind output, the main function here simply reads the
input and passes it to blobmsg_parse_array:
==10829== Invalid read of size 2
==10829== at 0x109DFC: blobmsg_namelen (blobmsg.h:74)
==10829== by 0x109446: blobmsg_check_name (blobmsg.c:42)
==10829== by 0x1092DD: blobmsg_check_attr_len (blobmsg.c:79)
==10829== by 0x109A63: blobmsg_parse_array (blobmsg.c:159)
==10829== by 0x10A7BA: main (blobmsg.c:412)
==10829== Address 0x4a2e2b4 is 0 bytes after a block of size 4 alloc'd
==10829== at 0x483877F: malloc (vg_replace_malloc.c:309)
==10829== by 0x10A773: main (blobmsg.c:408)
The same issue appears with the same input file for blobmsg_parse.
> > hdr = blob_data(attr);
> > if (name && !hdr->namelen)
> > return false;
> >
> > + if (len < sizeof(struct blob_attr) + sizeof(struct blobmsg_hdr) +
> > blobmsg_namelen(hdr) + 1)
> > + return false;
>
> Didn't checked it in detail yet, but isn't it almost the same as the check few
> lines bellow, just written differently?
> > if ((char *) hdr->name + blobmsg_namelen(hdr) > limit)
> > return false;
>
> ...
>
You are correct, it is almost the same, however it prevents another
invalid read below, in blobmsg.c:48:
if (hdr->name[blobmsg_namelen(hdr)] != 0)
return false;
I assume that this checks whether hdr->name is a null terminated
string. However, namelen seems to store the result returned as if it was
returned by strlen,
and the limit check doesn't seem to include the terminating null byte,
although I suppose modifying that check would definitely be better than
having two checks. The check would then look like this:
if ((char *) hdr->name + blobmsg_namelen(hdr) + 1 > limit)
return false;
Here is the xxd of the file that caused the issue to appear:
: 0300 0003 ..
Here is the relevant valgrind output:
==6076== Invalid read of size 1
==6076== at 0x1094B8: blobmsg_check_name (blobmsg.c:48)
==6076== by 0x1092DD: blobmsg_check_attr_len (blobmsg.c:79)
==6076== by 0x109A63: blobmsg_parse_array (blobmsg.c:159)
==6076== by 0x10A7BA: main (blobmsg.c:412)
==6076== Address 0x4a2e2b6 is 0 bytes after a block of size 6 alloc'd
==6076== at 0x483877F: malloc (vg_replace_malloc.c:309)
==6076== by 0x10A773: main (blobmsg.c:408)
> > @@ -191,7 +197,11 @@ int blobmsg_parse(const struct blobmsg_policy *policy,
> > int policy_len,
> > }
> >
> > __blob_for_each_attr(attr, data, len) {
> > + if (len < sizeof(struct blob_attr) + sizeof(struct blobmsg_hdr))
> > + return -1;
>
> If there is such problem, then this should be probably fixed directly in
> __blob_for_each_attr so we possibly protect other __blob_for_each_attr
> users[1].
Can you maybe provide a patch? I'd be happy to test it and let you
know what the results are.
Regards,
Juraj
___
Re: [OpenWrt-Devel] [RFC] commit message in YAML format for new devices
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Paul, On Mon, Jan 13, 2020 at 9:13 AM Paul Spooren wrote: > > Hi, > > On 1/12/20 1:05 PM, Martin Blumenstingl wrote: > > Hi Paul, > > > > On Sun, Jan 12, 2020 at 10:47 PM Paul Spooren wrote: > >> Hi all, > >> > >> some time ago I created a (now outdated) device overview[0] based on > >> YAML meta data. This approach could simplify maintaining an device > >> overview and device specific pages[1]. > >> > >> All commits adding new devices already include most relevant information > >> for creating the overview. However it would be convenient if developers > >> would format their commit messages in a generic format, therefore I'd > >> propose the following: > >> > >> Every commit message for newly added devices must contain a number of > >> hardware information and steps for an initial installation. > >> The hardware information should contain at least the following > >> information, maybe more: > >> > >> SoC, flash, ram, wifi, LEDs, buttons, USB, serial, vendor, model, device > >> tree ID, Ethernet ports > > can we automate this somehow? > > the device tree files already contain most of that information. > > If you have a tool to extract such data or ideas on how to create such, > that'd be great. I don't have such a tool my idea was that most of the data is already available in the .dts files (or .dtb files, I haven't really thought about the up-/downsides): - SoC - flash size - RAM size - (wifi can be detected on some devices where wifi is either part of the SoC or the PCI(e) wifi chip is described in the .dts) - buttons - serial console (existence of such) - model - Ethernet ports - USB controller(s) this data can be parsed periodically to ensure that the TOH is up-to-date, for example if a missing LED is added after the initial submission of the device. there are probably downsides when going this route, but I have not thought these through yet (because I don't have time to implement a tool which would do the parsing) > As an alternative I could also create a shell script that extracts data > on a running machine, but that might miss some details. that would be another solution the downside I see compared to .dts/.dtb parsing is that you need access to the device to update the TOH. but I don't know whether this is relevant for the use-case that we're discussing Martin --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][libubox] blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Juraj Vijtiuk [2020-01-14 22:11:18]:
> Here is the xxd output for the crash file that causes the invalid read when
> passed as data to blobmsg_parse_array with a len of 4:
>
> xxd crash-a3585b70f1c7ffbdec10f6dadc964336118485c4
> : 0300 0004
Thanks for sharing.
> Here is the relevant valgrind output, the main function here simply reads
> the input and passes it to blobmsg_parse_array:
>
> ==10829== Invalid read of size 2
> ==10829== at 0x109DFC: blobmsg_namelen (blobmsg.h:74)
> ==10829== by 0x109446: blobmsg_check_name (blobmsg.c:42)
> ==10829== by 0x1092DD: blobmsg_check_attr_len (blobmsg.c:79)
> ==10829== by 0x109A63: blobmsg_parse_array (blobmsg.c:159)
> ==10829== by 0x10A7BA: main (blobmsg.c:412)
> ==10829== Address 0x4a2e2b4 is 0 bytes after a block of size 4 alloc'd
> ==10829== at 0x483877F: malloc (vg_replace_malloc.c:309)
> ==10829== by 0x10A773: main (blobmsg.c:408)
That malloc is important here, one has to use dynamically allocated buffer and
Valgrind in order to see this OOB read access. There's already similar crash
from the previous runs, but without malloc'ed buffer Valgrind doesn't spot
that, lesson learned.
xxd tests/fuzz/corpus/crash-75b146c4e6fac64d3e62236b27c64b50657bab2a
: 0300 0002
> I assume that this checks whether hdr->name is a null terminated
> string. However, namelen seems to store the result returned as if it was
> returned by strlen,
> and the limit check doesn't seem to include the terminating null byte,
> although I suppose modifying that check would definitely be better than
> having two checks. The check would then look like this:
>
> if ((char *) hdr->name + blobmsg_namelen(hdr) + 1 > limit)
> return false;
Ok, makes sense, I'll check that.
> > > __blob_for_each_attr(attr, data, len) {
> > > + if (len < sizeof(struct blob_attr) + sizeof(struct
> > > blobmsg_hdr))
> > > + return -1;
> >
> > If there is such problem, then this should be probably fixed directly in
> > __blob_for_each_attr so we possibly protect other __blob_for_each_attr
> > users[1].
>
> Can you maybe provide a patch? I'd be happy to test it and let you
> know what the results are.
Ok.
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] New OpenWrt logo proposal [Was: Re: [RFC]new "corporate identity" for OpenWrt & static rendering]
Petr Štetiar [2020-01-08 22:47:28]: Next voting round[1] for next 3 days, this time really final, I promise :-) 1. https://forum.openwrt.org/t/help-pre-select-new-openwrt-project-logo-in-the-poll/52674 -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
