Re: Edgerouter X Support still possible in 24.10?
Tim Lunn [2024-11-06 18:17:45]: Hi Tim, > Way back in April I created a PR [1] for Edgerouter-X, adjusting the > partition layouts so this device could support 6,x kernels. At the time it > had a couple of reviews but never got merged. Is there any chance this can > still be merged now with 24.10 having been branched? Or is it now too late > and support for this hardware will just drop away? thanks and sorry for the details, I've just merged it. Feel free to prepare the backport into 24.10 (don't forget to use `git cherry-pick -x` method) and I'll merge after the dust in main branch settles a bit. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Upcoming buildbot and GPG signing changes in snapshots/24.10
Petr Štetiar [2024-11-05 10:39:44]: Hi, > just a quick update – I'll soon be updating Buildbot to the latest version > we've been preparing and testing. Here are the notable changes: forgot to mention previously: * switch from `master` to `main` branch deployed, openwrt.git already uses `main` branch, feeds not yet > * for snapshots and the 24.10 release, we will replace the >current RSA-4096 key with an Ed25519-based key (0x1D53D1877742E911), >supported by a Nitrokey3 dongle[1]. Pending successful testing, this >will also apply to the 23.05 release in the near future. Seems to be ticking fine, Nitrokey3 reports: 2024-11-07 06:24:43 scdaemon[3798545] signatures created so far: 1845 thus I've just enabled it for 23.05 as well. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Upcoming buildbot and GPG signing changes in snapshots/24.10
Hi, just a quick update – I'll soon be updating Buildbot to the latest version we've been preparing and testing. Here are the notable changes: * preparation for opkg to apk transition (APK not yet enabled) * a single buildmaster container will now handle both phase1 and phase2 buildmasters * for snapshots and the 24.10 release, we will replace the current RSA-4096 key with an Ed25519-based key (0x1D53D1877742E911), supported by a Nitrokey3 dongle[1]. Pending successful testing, this will also apply to the 23.05 release in the near future. 1. https://git.openwrt.org/?p=keyring.git;a=commit;h=6b42a5c8b7dc049b899869b2a1b94daf69ceb2f5 Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
What is missing for opkg -> apk switch [Was: Re: OpenWrt 24.XX release plan]
Hi, > I understood that index based trust is now impemented in APK: > https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/11008 yep, I've tested that and this part works fine. Although having my QA hat on, there might be probably one missed use case with `apk verify` which is probably not using the package index (yet?) for the verification (as `apk add` does): root@OpenWrt:/tmp# apk verify packages.adb packages.adb: OK root@OpenWrt:/tmp# apk verify 464xlat-13.apk 464xlat-13.apk: UNTRUSTED signature > What else is missing? * ImageBuilder (IB) seems to be broken https://lists.openwrt.org/pipermail/openwrt-devel/2024-September/043186.html * packages CDX SBOMs are missing (we've SBOM only for images x86/64/openwrt-x86-64.bom.cdx.json) * apk version compat in few packages > If on the buildbot side everything is ready to do the switch, then lets > do it as soon as possible I'd say. Yes, buildbot part is prepared, tested and I would say ready for the apk switch. IMO we should really first enable it on the `main` branch and eventually later in `openwrt-24.10` once we're confident, that its release ready (apk itself is release ready, just our integration needs a bit more of testing and love). I've following on my TODO list towards apk switch proposal: 1. Extend GitHub CI action with a test for the ImageBuilder as we're not aware about the current breakage, prevent future regressions, probably continue in https://github.com/openwrt/actions-shared-workflows/pull/5 2. Fix the IB 3. Fix the SBOM generation (perhaps try to QA this part on CI as well?) I'll start with 1. this/next week, hopefully. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 24.XX release plan
Hauke Mehrtens [2024-09-21 11:51:19]: Hi, > We should already start building up the build infrastructure for a 24.10 > branch now. > @ynezz: What is needed for that? tl;dr basically just the openwrt-24.10 branches in the Git repositories Rough procedure is here https://openwrt.org/docs/guide-developer/releases/buildbot-major-releases Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: State of APK package manger integration
Paul Spooren [2024-08-11 20:34:09]: Hi, > Some time has passed and there are further news for the APK migration: awesome progress, thanks a lot to all of you pushing this forward! :-) > If you run one of those images, please give APK a spin and see how it’s > doing. A simple example would b to run the following: FYI seems like ImageBuilder still needs some love, I've tested both: https://buildbot.aparcar.org/targets/x86/64/openwrt-imagebuilder-x86-64.Linux-x86_64.tar.zst https://downloads.staging.openwrt.org/snapshots/targets/x86/64/openwrt-imagebuilder-x86-64.Linux-x86_64.tar.zst and they both seems to fail the basic `make image` smoke test: $ make image Building images for x86 - Generic x86/64 Packages: apk-mbedtls base-files busybox ca-bundle dnsmasq dropbear e2fsprogs firewall4 fstools grub2-bios-setup kernel kmod-amazon-ena kmod-amd-xgbe kmod-bnx2 kmod-button-hotplug kmod-dwmac-intel kmod-e1000 kmod-e1000e kmod-forcedeth kmod-fs-vfat kmod-igb kmod-igc kmod-ixgbe kmod-nft-offload kmod-r8169 kmod-tg3 libc libgcc libustream-mbedtls logd mkf2fs mtd netifd nftables odhcp6c odhcpd-ipv6only partx-utils ppp ppp-mod-pppoe procd procd-seccomp procd-ujail uci uclient-fetch urandom-seed urngd Package list missing or not up-to-date, generating it. Building package index... ERROR: *.apk: No such file or directory ERROR: 1 errors, not creating index make[3]: *** [Makefile:172: package_index] Error 99 make[2]: *** [Makefile:196: package_reload] Error 2 make[1]: *** [Makefile:150: _call_image] Error 2 make: *** [Makefile:310: image] Error 2 Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mpc85xx/p1010 buildboot issue
Paweł Dembicki [2024-08-23 12:15:03]:
[ adding Christian and Luiz to the CC: loop ]
Hi,
> Buildbot had some issue with mpc85xx/p1010 subtarget:
> https://buildbot.openwrt.org/images/#/builders/231
>
> It looks like only `osuosl-vm5-dock-02` can build this subtarget.
> Could someone look at this issue?
seems to be some race condition in the build system being exposed on a boxes
with a specific I/O performance?
[ ! -d
"/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da"
] || rm -rf
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da
/builder/shared-workdir/build/staging_dir/host/bin/mksquashfs4
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/target-dir-68b329da
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/root.squashfs+pkg=68b329da
-nopad -noappend -root-owned -comp xz -Xpreset 9 -Xe -Xlc 0 -Xlp 2 -Xpb 2
-Xbcj powerpc -b 256k -p '/dev d 755 0 0' -p '/dev/console c 600 0 0 5 1'
-no-xattrs
mkdir
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da
[ ! -d
"/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da"
] || rm -rf
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da
Parallel mksquashfs: Using 6 processors
Creating 4.0 filesystem on
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/root.squashfs+pkg=68b329da,
block size 262144.
Pseudo file "dev" exists in source filesystem
"/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/target-dir-68b329da/dev".
Ignoring, exclude it (-e/-ef) to override.
[| ] 0/818
0%cp -fpR
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47/.config
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da
mkdir
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da
rm -f
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da/.config.prev
mkdir: cannot create directory
'/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da':
File exists
make[4]: *** [Makefile:24:
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/simpleImage.ws-ap3715i-initramfs.68b329da]
Error 1
make[4]: *** Waiting for unfinished jobs
mv
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da/.config
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da/.config.old
mv: failed to access
'/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da/.config.old':
Not a directory
make[4]: *** [Makefile:27:
/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/simpleImage.br200-wp-initramfs.68b329da]
Error 1
which leads me to the commit 97fd059e7e6a ("image: respect
TARGET_PER_DEVICE_ROOTFS for initramfs") and I would be tempted to fix it via:
--- a/include/kernel-defaults.mk
+++ b/include/kernel-defaults.mk
@@ -158,7 +158,7 @@ endef
define Kernel/PrepareConfigPerRootfs
[ ! -d "$(1)" ] || rm -rf $(1)
- mkdir $(1)
+ mkdir -p $(1)
$(CP) $(LINUX_DIR)/.config $(1)
endef
but reading the reasoning in the commit:
"To handle this, we prepare a config for each rootfs and we generate the
images under lock to prevent problem with parallel execution."
it might not be actually desired, that devices are racing between each other
and doing that "rm -rf $(1)" ? So maybe some additional locking or even better
per device/rootfs directory would make more sense?
Cheers,
Petr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Enforcing package source code integrity checks [Was: Re: Conclusions from CVE-2024-3094 (libxz disaster)]
[removed openwrt-adm@ from the Cc: loop] Petr Štetiar [2024-04-01 14:49:46]: > Perhaps this package source code integrity checks should be mandatory, not > optional? BTW I looked into this a bit and these are likely breakages caused by the recent APK releated changes: $ curl -s https://buildbot.openwrt.org/images/api/v2/logs/1157227/raw | grep Wrong mdio-netlink-0~1.3.1.tar.xz: Wrong hash (probably caused by .gitattributes), expecting 97dfd25d8cdf5994eeb8cb0a5862c993b8aef373b280bca567d41d4113f494a9, got f72f170941430eb793902fc3f736839e362d53136bf0459aa98cd1b1152ad5e2 v4l2loopback-0~v0.12.7.tar.xz: Wrong hash (probably caused by .gitattributes), expecting e5e5d897bdaa7f2fb0b897e503cecaeee234fcdc7f2f138aae501ef742f5b2b2, got 09fcc9a66c820855136fae517c8102564eed7070dd07c272eb14bf2af9b536a3 usb-serial-xr_usb_serial_common-2023.03.21~90ad5301.tar.xz: Wrong hash (probably caused by .gitattributes), expecting 0cea56120542d3d546028d17389a3419ca930448005a9208728c40583ccf027d, got ca9e4f48a1a71e8d8e595ce8981a876d11a7d3d0f67b9e68c7825730f2f8756a dahdi-linux-2023.09.21~1bb9088f.tar.xz: Wrong hash (probably caused by .gitattributes), expecting b32eb405d64c981f64922840f616cf362636ccc93506986c0b92bd4dcca5ab30, got ca88184419f85e87e9b8fd89132a0cf441625230f694954c9a3315247c4adc4a yet we still seems to be happily producing binary packages with those theoretically tainted sources. My understanding of the situation: 1. tarball is downloaded from sources.openwrt.org, but the package hash doesn't match (might be corrupted or malicious tarball) 2. tarball is deleted, Git clone is performed and source code tarball recreated 3. [ here is the possible blind spot, tarball hash is not checked again, although it should be ] 4. build continues using Git cloned source tree from 2., which in case of PKG_SOURCE_VERSION being a Git tag is not trustworthy enough How to approach that? A. Add additional post Git clone hash check (implement 3. above) and fail the build if the package hash still doesn't match. B. Turn the current hash check warnings into errors by default, making it opt-out via config option, so if you enjoy JiaTanning, then be our guest. C. Forbid usage of Git tags in PKG_SOURCE_VERSION, but I find that a bit harsh. D. Combination of the above E. ? Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
xz inadequate for a long term tarball reproducibility? [Was: [openwrt/openwrt] unetd: fix PKG_MIRROR_HASH]
LEDE Commits [2024-04-03 07:29:21]: Hi, thanks a lot for a great commit message, really appreciate it! :-) Just to get a complete picture, I've additional questions, sorry. > nbd pushed a commit to openwrt/openwrt.git, branch main: > https://git.openwrt.org/2070049c1cafa52224c946a6c334bf9fea4f549b > > commit 2070049c1cafa52224c946a6c334bf9fea4f549b > Author: Paul Spooren > AuthorDate: Wed Apr 3 13:04:36 2024 +0200 > > unetd: fix PKG_MIRROR_HASH > > Our CI on GitHub as well as my local machine generates a different > PKG_MIRROR_HASH from what Felix uploaded the other day. Felix, can you provide more details about the host OS/compiler/version of the xz used for this tarball creation? > After receiving Felix file, both have indeed different hashes, however > when unpackaged via `xz -d` both have the same tarball content. Paul, can you be more specific which `xz -d` is that? From the OpenWrt tools `staging_dir/host/bin/xz` or from your host? For example: $ staging_dir/host/bin/xz --version xz (XZ Utils) 5.4.6 liblzma 5.4.6 > Below the checksums to compare: > > a62bef497078c7b825f11fc8358c1a43f5db3e6d4b97812044f7653d60747d5b > dl/unetd-2024.03.31~80645766.tar.xz > fbdac59581742bf208c18995b1d69d9848c93bfce487e57ba780d959e0d62fc4 > dl/unetd-2024.03.31~80645766_felix.tar.xz > > After unpacking: > > a7189cae90bc600abf3a3bff3620dc17a9143be8c27d27412de6eb66a1cf1b7d > dl/unetd-2024.03.31~80645766.tar > a7189cae90bc600abf3a3bff3620dc17a9143be8c27d27412de6eb66a1cf1b7d > dl/unetd-2024.03.31~80645766_felix.tar > > The tarball with the wrong hash was accidentally generated without the xz > revert to version 5.4.6 interesting, would it be possible to upload `unetd-2024.03.31~80645766_felix.tar.xz` somewhere, so anyone interested could take a look? Thanks! BTW reminds me of https://www.nongnu.org/lzip/xz_inadequate.html Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Conclusions from CVE-2024-3094 (libxz disaster)
Daniel Golle [2024-04-03 01:11:41]:
Hi,
> > In this case, they were targeting specific audience and this attack vector
> > was
> > cheapest/fastest, so the source code origin doesn't really matter.
>
> I tend to slightly disagree, because an attacker will always chose
> what ever means are necessary or sufficient. Using tarballs instead of
> checkouts increases the attack surface in the sense that validating
> the tarball content is extra work for package maintainers.
I've noticed, that Debian for example imports upstream package tarballs into
their GitLab instance, so one would argue, that the Git diff is easily
available to package maintainers, yet they've happily included the
backdoor[1]. The package version bumps are usually huge, thus impossible to
review properly.
> > > Why do we need to rely one proprietary hacks such as Gibhub codeload
> > > just to safe a few megabytes of traffic and a few seconds of build
> > > time?
> >
> > Ok, I don't like GH either, but I find this irrelevant, origin of the source
> > code is not a problem, the content is the problem.
>
> ... and that crazy m4 script had to be noticed. As a diff one would ask:
> Why was that change necessary?
This was our case, jumping from v5.4.6 to v5.6.1, right? So just take a look
at the diff now:
git diff --stat v5.4.6..v5.6.1 | grep changed,
404 files changed, 26865 insertions(+), 17129 deletions(-)
$ git diff --stat v5.4.6..v5.6.1 -- ':!windows/' ':!po/' ':!docs/'
':!.github/' ':!po4a/' | grep changed,
357 files changed, 10544 insertions(+), 4529 deletions(-)
So realistically, to review that amount of changes somehow more properly, this
is huge amount of work, if you really want to question purpose of every
change, verify it, then this is like 16k lines, so lets say, that you can do
1-2k a day properly, thus around a week of work? Who have such resources and
dedication?
And even after that rigid review, I'm not sure if I would catch that famous
CMakeLists.txt '.' Landlock sabotage:
+#include
+.
+void my_sandbox(void)
looking at the commit 328c52da8a2b ("Build: Fix Linux Landlock feature test in
Autotools and CMake builds.") alone, I still have a problem to spot it.
> They unpack the release tarballs into a git repo, so that makes the diff
> more visible and obvious again for maintainers. That would get the best
> of both worlds (at a significant resource pricetag, though...)
Providing the diff is not a problem, finding someone who would review the diff
_properly_ is a problem.
> But the m4 hackery which is excessive and seemingly unnecessary.
In this case, it would be hidden somewhere in between other 16-40k lines of
changes, so hardly spottable?
1.
https://salsa.debian.org/debian/xz-utils/-/blob/debian/unstable/m4/build-to-host.m4?ref_type=heads#L63
Cheers,
Petr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Conclusions from CVE-2024-3094 (libxz disaster)
Daniel Golle [2024-03-30 15:30:49]: Hi, > In many ways, we are already better I would probably avoid such bold statements and would be more humble, since you never know why OpenWrt wasn't directly targeted. > I believe that the current tendency to use tarballs rather than > (reproducible!) git checkouts is also problematic to begin with. Git checkouts are currently problematic as well, IIRC the build is going to happily use whatever Git is happy with. I mean, if the hash of the downloaded tarball source code doesn't match, then the tarball is removed and Git clone is performed, new source code tarball is produced, but the tarball hash is not going to be checked again. Perhaps this package source code integrity checks should be mandatory, not optional? > So why not **always** use that instead of potentially shady and hard to > verify tarballs? In this case, they were targeting specific audience and this attack vector was cheapest/fastest, so the source code origin doesn't really matter. > Why do we need to rely one proprietary hacks such as Gibhub codeload > just to safe a few megabytes of traffic and a few seconds of build > time? Ok, I don't like GH either, but I find this irrelevant, origin of the source code is not a problem, the content is the problem. > There are even too many problems to reproduce even those supposedly > automated Github-generated tarballs. Nobody actually checks that. FYI we do on the CI https://github.com/openwrt/actions-shared-workflows/blob/main/.github/workflows/reusable_build.yml#L224 > 9bd7d8b, c7c2257, 77368ec, 86994e1, 954142f, 4c5d910, 21f713d, ... > Probably all of those have trivial causes and there isn't anything > malicious going on there. I agree, I guess, that in some cases it might point to a subtle bug somewhere in the source code tarball packaging path (host kernel, tools, container?), maybe another backdoor in the works/testing? :P Anyway, we should perhaps consider treating this situations in supply chain more seriously, so perhaps in this cases of package hash failures, we need to document it better, with more details in the commit message and maybe even better, gather always more evidence in a separate GH issue, so its possible to reconstruct the complete picture if we really find out 2 years later, that it was something malicious going on somewhere? Whatever it might be. > Always using git checkouts instead of tarballs would also makes it > much easier for maintainers to at least have a quick look at the > changes made in an upstream project between versions (a quick scroll > over 'git diff oldtag..newtag' or even just 'git log --stat > oldtag..newtag' doesn't take much more time than manually validating a Although I mostly (always?) doing that Git diff/log, during bumps/reviews, I'm sorry, but I'm not able to spot such masked backdoors :-) > release tarball GPG signature in most cases, if there even is any...). And speaking about the signatures: openwrt.git $ ~/bin/git-signed-commits-stats.sh "1 year ago" Total commits: 3267 (since 1 year ago) Good signatures: 94 (2.00%) Unsigned commits: 2456 (75.00%) Bad signatures: 0 (0%) Unknown signature status: 717 (21.00%) (script source https://gist.github.com/ynezz/e6f4219b7be20fa0f44b0f3832c26d59) > Hiding a malicious change in a commit is infinitely harder than hiding it in > a tarball. Harder? Yes. Impossible? No. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: padding of large 16-32GB images [Was: Re: [PATCH 2/5] build: image: Add pad-to and pad-rootfs-squashfs helpers]
Nishant Sharma [2024-02-29 20:11:19]: Hi, > dd > if=/home/devuser/auto-build/hopbox-os/hopbox-openwrt/build_dir/target-x86_64_musl/linux-x86_64/tmp/hopbox-arthur-23.05.2.1-x86-64-generic-squashfs-rootfs.img.gz > > of=/home/devuser/auto-build/hopbox-os/hopbox-openwrt/build_dir/target-x86_64_musl/linux-x86_64/tmp/hopbox-arthur-23.05.2.1-x86-64-generic-squashfs-rootfs.img.gz.new > bs=16642998272 conv=sync > > dd: memory exhausted by input buffer of size 16642998272 bytes (16 GiB) can you check https://patchwork.ozlabs.org/project/openwrt/patch/20240401102511.495791-1-yn...@true.cz/ ? Thanks! Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] image.mk: fix dd memory exhaustion during padding of large images
This commit adjusts the Image/pad-to function within image.mk to improve memory management when padding large images. Previously, the dd command was used with a block size (bs) directly derived from the target padding size. This could lead to inefficiencies or memory exhaustion issues when dealing with very large images. To address this, a conditional has been introduced: If the desired padding size exceeds 1MiB (1048576 bytes), dd now operates with a block size of 1MiB and calculates the necessary count to achieve the desired padding. This approach aims to balance memory usage and performance by avoiding excessively large block sizes in memory-intensive operations. For padding sizes of 1MiB or less, the original behavior is preserved, using the specified padding size as the block size. This change ensures more reliable and efficient image padding, particularly in environments with limited memory resources. References: https://github.com/openwrt/openwrt/pull/2862 Reported-by: Nishant Sharma Suggested-by: shir474 Signed-off-by: Petr Štetiar --- include/image.mk | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/include/image.mk b/include/image.mk index 4b6acbe1aad6..2586f29160f6 100644 --- a/include/image.mk +++ b/include/image.mk @@ -163,7 +163,13 @@ DTC_FLAGS += $(DTC_WARN_FLAGS) DTCO_FLAGS += $(DTC_WARN_FLAGS) define Image/pad-to - dd if=$(1) of=$(1).new bs=$(2) conv=sync + if [ $(2) -gt 1048576 ]; then \ + dd if=$(1) of=$(1).new \ + bs=1048576 count=$(shell expr $(2) / 1048576) \ + conv=sync ; \ + else \ + dd if=$(1) of=$(1).new bs=$(2) conv=sync ; \ + fi mv $(1).new $(1) endef ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Project statement about xz 5.6.1 (CVE-2024-3094)
Hi, tl;dr OpenWrt seems to be not affected by the CVE-2024-3094 As you may be aware, malicious code was identified[1] in the xz upstream tarballs starting from version 5.6.0. The development snapshots of OpenWrt were utilizing this compromised library version. Fortunately, the snapshots builds relied on source code tarballs from GitHub releases, which are generated automatically. These contained only the dormant segment of the malicious code. The crucial component that would activate the backdoor during the build process was not detected in the scrutinized tarball archives. For those interested, the source tarballs employed in the official OpenWrt snapshot builds are still accessible at http://sources.openwrt.org/xz-5.6.1.tar.xz.backdoored and http://sources.openwrt.org/xz-5.6.1.tar.bz2.backdoored, with their respective sha256sums: d300422649a0124b1121630be559c890ceedf32667d7064b8128933166c217c8 xz-5.6.1.tar.bz2 f334777310ca3ae9ba07206d78ed286a655aa3f44eec27854f740c26b2cd2ed0 xz-5.6.1.tar.xz Binary packages built using affected xz sources can be downloaded from https://mirror-03.infra.openwrt.org/snapshots/packages/xz-5.6.1-ipks.tar.gz, sha256sum is a376b30cc8afe2ebf92316b47c640e845cd76bef4f2c593ca22e6fc12deb580d. Timeline, 2024-03-29, CET timezone: 16:17 - Started investigating the issue 16:59 - Reverting the xz 5.6.1 package version bumps 17:11 - Moved affected sources/packages to .backdoored file suffixes on downloads.openwrt.org and sources.openwrt.org servers 19:08 - CDN cache invalidated as well 1. https://www.openwall.com/lists/oss-security/2024/03/29/4 Happy Easter! :-) Cheers, Petr signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: here we are again: real name 'discussion'
John Crispin [2024-03-26 21:10:03]:
Hi,
tl;dr check following kernel commit d4563201f33a ("Documentation: simplify and
clarify DCO contribution example language"), the diff:
-using your real name (sorry, no pseudonyms or anonymous contributions.)
+using a known identity (sorry, no anonymous contributions.)
> without a real name DCO is not assignable
There is official clarification[1] from Linux Foundation of the intended
meaning, to make it clear that real names are NOT required, only ability to
identify the person in the community:
The DCO requires the use of a real name that can be used to identify someone
in case there is an issue about a contribution they made. A real name does not
require a legal name, nor a birth name, nor any name that appears on an
official ID (e.g. a passport).
Your real name is the name you convey to people in the community for them to
use to identify you as you. The key concern is that your identification is
sufficient enough to contact you if an issue were to arise in the future about
your contribution. Your real name should not be an anonymous id or false name
that misrepresents who you are.
1. https://github.com/cncf/foundation/issues/383#issuecomment-1178254458
Cheers,
Petr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ustream-ssl ABI_VERSION usage
Jo-Philipp Wich [2024-02-12 14:09:27]: Hi, > Ideally all packages specifying an ABI version should ship versioned .so files > as well. I would like to point out, that ustream-ssl is dynamically loaded library[1], so we would need to pass that ABI information somehow to the clients, so they would be able to load correct/compatible version of dynlib, not exactly trivial. 1. https://lxr.openwrt.org/source/uclient/uclient-fetch.c#L516 Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [VOTE] New member proposal: Robimarko (Robert Marko)
Christian Marangi (Ansuel) [2024-01-30 19:15:54]: Hi, > Robert is active in OpenWrt since 2017 and with some recent stats, he > has more than 310 commits merged in OpenWrt. > He also have uncounted Reviewed-by tag on various PR and merged commits > and generally helps in everything related to IPQ (ipq806x, ipq40xx and > ipq807x) and some mvebu targets. > > He did the conversion of ipq40xx target to DSA and made possible the > introduction of the ipq807x target by sorting all the QSDK downstream > patch and pushing them upstream. > > With his help, also the ipq60xx is very close on getting merged and > actually used permitting support of even more device for OpenWrt. > > Also he is almost always reachable on IRC openwrt-devel and never had > a problem in coordinating and collaborating with him. > > I think Robert is a good addition to our team and would massively help > me (Ansuel) in maintaining each IPQ target and review all the related > PR on github and patchwork. > I would like to add Robert to the OpenWrt committers team. +1 Thanks for taking care of that! Cheers, Petr signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Buildbot infrastructure update
Hi, I would like to let you know, that we've prepared upgrade of the Buildbot based infrastructure and there is a plan to make those changes alive. We would like to bump master and workers in the upcoming days to the containers having following changes: prod: bump buildworker container to buildbot v3.9.0 and v10 tag[1] Changes since v9: * phase2: remove unused git_ssh plumbing * scripts: remove unused expire.sh * phase2: remove unused tree_expire option and steps * phase2: rsync: use --size-only instead of --checksum for sourceupload * phase2: use sha2rsync.pl for 'targetupload' * phase2: compute checksums * phase2: reduce verbosity of rsync and use rsync.sh helper * phase2: don't enable rsync compression where unnecessary * phase2: regroup common rsync options and add timeout * phase2: report ccache stats at end of build * Revert "phase2: use full git history for reproducibility" * phase2: use Interpolate instead of WithProperties * phase2: s/SetProperty/SetPropertyFromCommand/ * phase2: do not exceed nproc build concurrency * phase2: remove unused 'other_builds' property * phase1: treat all branches equally for building * phase1: raise priority of tag builds * docker,worker: install zstd While at at we're going to decomission the current buildbot master server: builds-01.infra.openwrt.org has address 136.243.8.135 builds-01.infra.openwrt.org has IPv6 address 2a01:4f8:211:2206::2 and switch to the new one: builds-06.infra.openwrt.org has address 65.109.91.159 builds-06.infra.openwrt.org has IPv6 address 2a01:4f9:3051:45d6::2 by changing the DNS records, so some glitches here and there are expected. 1. https://github.com/openwrt/buildbot/releases/tag/v10 Cheers, Petr signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433
Varadarajan Narayanan [2023-12-07 15:29:23]: Hi, > SoC : QCOM IPQ9574 > RAM : 2GB DDR4 > Flash : eMMC 8GB > WiFi: 1 x 2.4GHz > 1 x 5GHz > 1 x 6GHz BTW it doesn't build here: Applying openwrt.git/target/linux/ipq95xx/patches-6.1/0023-arm64-dts-qcom-add-few-more-reserved-memory-region.patch using plaintext: patching file arch/arm64/boot/dts/qcom/ipq6018.dtsi patching file arch/arm64/boot/dts/qcom/ipq8074.dtsi Hunk #1 FAILED at 85. 1 out of 1 hunk FAILED -- saving rejects to file arch/arm64/boot/dts/qcom/ipq8074.dtsi.rej Patch failed! Please fix openwrt.git/target/linux/ipq95xx/patches-6.1/0023-arm64-dts-qcom-add-few-more-reserved-memory-region.patch! Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
realtek/rtl838x: regression in f909059b74 caused by procd segfault in libubox
Hi,
daily runtime testing of snapshots on Zyxel GS-1900 just reported following
regression[1] this morning:
[ 14.307030] random: procd: uninitialized urandom read (4 bytes read)
...
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
...
[ 16.746253] do_page_fault(): sending SIGSEGV to procd for invalid write
access to 0008
[ 16.755678] epc = 77dfb3f7 in libubox.so.20231130[77df2000+1f000]
[ 16.762584] ra = 555c3531 in procd[555c+12000]
[ 16.768737] procd: Rebooting as procd has crashed
as it was booting fine on 65c50a2545 based snapshot yesterday, we've quite
narrow space:
$ git log --pretty="%h %s" 65c50a2545..f909059b74
f909059b7473 hostapd: use new udebug ubus api to make debug rings configurable
fdb92d2d6f2e ucode: update to Git HEAD (2023-11-30)
fc5267f7309f udebug: add more entries for the default config
38eeefd060f7 procd: update to Git HEAD (2023-11-28)
4cb0677600c7 ubox: update to Git HEAD (2023-11-30)
I suspect this might be caused by commit 38eeefd060f7 ("procd: update to Git
HEAD (2023-11-28)"), with following changes:
$ git log --pretty="%h %s" 2db836553e8..7e6c6efd6f
7e6c6efd6fbc udebug: add support for logging via udebug
d852f877920b service: Fix retriggering of init.d-scripts.
so just wild guessing, that commit 7e6c6efd6fbc ("udebug: add support for
logging via udebug") might be the culprit?
Comparing the output of both console logs, it seems, that "procd: - early -"
is not present, so maybe something around the new `procd_udebug_printf()`?
1.
https://ynezz.gitlab.io/-/openwrt-device-runtime-testing/-/jobs/5666500332/artifacts/console_zyxel-gs1900-initramfs.txt
Cheers,
Petr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Unbalanced prioritization in the images buildbot? (main branch deprioritized too much)
Thibaut [2023-11-14 14:25:50]: > I’m sorry, I must have missed the part where we advertised that master > snapshots are a maintained 'release' suitable for use in a > security-conscious context :) There is no difference actually, it applies to all branches/releases, so it really doesn't matter if you use main snapshot or 23.05.1 release. Once the commit lands in the corresponding branch (main, openwrt-23.05 or openwrt-22.03) then the packages are going to be built on buildbot and become available for `opkg upgrade`, so you don't need to wait for a tagged release to get certain fixes possible by a package upgrade. In other words, https://downloads.openwrt.org/releases/23.05.0/ that `packages` folder is a symlink to packages-23.05, populated by 23.05 snapshot builds. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
David Bauer [2023-11-14 10:02:36]: Hi, > Is there already a patch series / PR in the works? AFAIK there is just PR #13924 attempting to workaround #13886 > Otherwise, I'd look into that. Great, thanks! Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Unbalanced prioritization in the images buildbot? (main branch deprioritized too much)
Thibaut [2023-11-14 10:24:28]: Hi, > I don’t follow, what do security fixes have to do with snapshot builds? OpenWrt builds and deliver package fixes continuosly from the snapshot builds. > I don’t expect users (that includes myself) to keep constantly looking at > the git history to find if/when a CVE has been addressed in the snapshot > builds. You're not expected to do this, we send out security advisories if its important, where you can usually find recommended mitigations, like for example: https://forum.openwrt.org/c/announcements/14 https://lists.openwrt.org/pipermail/openwrt-announce/2022-October/33.html most of the fixes can be handled with `opkg update; opkg upgrade` Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Unbalanced prioritization in the images buildbot? (main branch deprioritized too much)
Thibaut [2023-11-13 22:20:28]: Hi, > GitPoller accepts a single poll interval. What you’re suggesting would > require separating each branch, i.e. returning to the previous situation. IIUC then you can have multiple GitPoller instances, so wouldn't something along this lines work? diff --git a/phase1/master.cfg b/phase1/master.cfg index 6f6c650cf54c..6cbd0c8d9609 100644 --- a/phase1/master.cfg +++ b/phase1/master.cfg @@ -341,15 +341,16 @@ populateTargets() # about source code changes. c["change_source"] = [] -c["change_source"].append( -GitPoller( -repo_url, -workdir=work_dir + "/work.git", -branches=branchNames, -pollAtLaunch=True, -pollinterval=300, +for branch in branchNames: +c["change_source"].append( +GitPoller( +repo_url, +branch=branch, +workdir=work_dir + "/work.git", +pollAtLaunch=True, +pollinterval=pollinterval_for_branch(branch), +) ) -) > Also note that even with a 24h poll interval you could still starve the > master builds. Sure, but meanwhile it would still allow to build quite a bunch of the master targets, so improving current situation. > or we switch to a periodic build schedule What about handling of security fixes in this once a week periodic build proposal? Going forward with this approach, we would still probably need some custom scheduler which would be able to skim through the commit content and trigger build when certain patterns are found, like a word 'security' or CVE number? > This would have the added benefit of ensuring *consistency* > across targets, i.e. ensuring that whichever commit is built is built on > *all* targets. I'm probably missing something, but what is this consistency good for? I would actually prefer to select say top X targets (ideally have them in testbeds for automatic runtime testing) and increase build priorities for those in phase1/phase2 builds, making sure, that we provide builds to actual users/testers first and build the rest afterwards. Those targets would be clearly marked as such in the source tree, for example: FEATURES+=ci-tier1 (or introduce some new variable?) we would need to define and document this selection process of course as well :) Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Unbalanced prioritization in the images buildbot? (main branch deprioritized too much)
Thibaut [2023-11-13 17:26:44]: Hi, > In any case, another way to tackle this problem would be to switch from > continuous builds that starve the build resources to periodic builds that > don’t (e.g. once a week), other options: * add more build workers :-) * use different GitPoller polling interval settings (master=5 minutes, 23.05=12 hours, 22.03=24 hours) Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
Paul Spooren [2023-11-13 13:30:10]: Hi, > How about we follow the approach of Alpine Linux[1] and offer a standard, an > extended and a virtual firmware for the x86/64 target? FYI that pull request added 27 firmware ASIC blobs, thus increased x86/64 image from 10 MiB to 41 MiB, but actually just 1 firmware ASIC blob mlxsw_spectrum-13.2010.1006.mfa2 (1.6MiB) is needed, so I would instead recommend to fix that mlx firmware package and call it a day? Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: SBOM Tool for OpenWRT to feed Dependency Track
Pfendtner Steffen [2022-10-18 14:38:56]: Hi, > We decided to publish our internal fork of the Timesys SBOM Tool we found on > github. You find our version at: https://github.com/ads-tec/sbom-openwrt thanks for sharing! BTW I took that output and drafted first version[1] by extending current image/package metadata handling. Its not finished, not ideal, but looks somehow usable already. Feedback welcome. Hauke Mehrtens [2022-10-25 00:32:21]: > Nice tool, do you have some "demo" output for a recent OpenWrt release > somewhere? BTW its really quite easy to setup[2] for toying purposes: curl -LO https://dependencytrack.org/docker-compose.yml docker-compose up -d then wait a bit for init and head to http://localhost:8080 > One advantage of uscan from my point of view is that I just have to open a > website to see the results for OpenWrt master and the maintained branches > and do not have to run some scripts and install some tooling myself. In the long term it would be perhaps nice to have DependencyTrack running at sca.openwrt.org, feeded automatically from buildbot. 1. https://github.com/openwrt/openwrt/pull/13800 2. https://docs.dependencytrack.org/getting-started/deploy-docker/#quickstart-docker-compose Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 0/5] bcm53xx: Support D-Link DIR-890L
Bjørn Mork [2023-08-01 08:51:03]: Hi, > Linus Walleij writes: > > > can also create a pull request on github if it helps? > > Probably not. BTW I'm doing both, mailing list to notify first pair of eyes not following GH closely, and PRs on GH to get another review attention and mainly to be somehow sure, that I don't introduce regressions as there is quite heavy CI machinery. > There's a "6 approving reviews" rule on github, and not > even close to that many active reviewers. Sp adding new devices via > pull requests seems impossible at the moment. Thats done on purpose, due to the current git.openwrt.org based workflow, basically to prevent accidental merging via GH as this would break Git repository sync. AFAIK GH simply doesn't allow us to disable those merge buttons, so this is our workaround. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 22.03 packages not building since 10 days
Sebastian Kemper [2023-07-20 20:54:33]: Hi, > Can a kind soul please check the build bots for 22.03 packages? We pushed > some security fixes about a week ago for pjsip and were hoping they'd be > packaged by now. thanks for the report, should be fixed now. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] toolchain: kernel-headers: fix check target for external Git trees
Executing following command currently fails:
$ make toolchain/kernel-headers/{download,check} V=sc FIXUP=1
...
include/kernel-version.mk:11: *** Missing kernel version/hash file for .
Please create include/kernel-. Stop.
So lets fix it by adding the necessary missing KERNEL_PATCHVER variable.
That additional kernel-build.mk include is needed to add another set of
missing variables:
$ make toolchain/kernel-headers/{download,check} V=sc FIXUP=1
...
Makefile:115: *** ERROR: Unknown pack format for file tmp/dl/. Stop.
Fixes: 0765466a42f4 ("kernel: split kernel version to dedicated files")
Signed-off-by: Petr Štetiar
---
toolchain/kernel-headers/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/toolchain/kernel-headers/Makefile
b/toolchain/kernel-headers/Makefile
index c1a8710a4fbe..5e3e459a96f5 100644
--- a/toolchain/kernel-headers/Makefile
+++ b/toolchain/kernel-headers/Makefile
@@ -23,7 +23,10 @@ ifneq ($(call qstrip,$(CONFIG_KERNEL_GIT_CLONE_URI)),)
PKG_SOURCE_VERSION:=$(call qstrip,$(CONFIG_KERNEL_GIT_REF))
PKG_MIRROR_HASH:=$(call qstrip,$(CONFIG_KERNEL_GIT_MIRROR_HASH))
ifdef CHECK
+ PLATFORM_DIR:=$(firstword $(wildcard $(TOPDIR)/target/linux/feeds/$(BOARD)
$(TOPDIR)/target/linux/$(BOARD)))
+ include $(PLATFORM_DIR)/Makefile
include $(INCLUDE_DIR)/kernel-version.mk
+ include $(INCLUDE_DIR)/kernel-build.mk
PKG_VERSION:=$(LINUX_VERSION)
else
PKG_SOURCE:=$(LINUX_SOURCE)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] toolchain: kernel-headers: remove debugging env dump
Remove debugging `env` dump left over as build environments might
contain some sensitive information, which then might leak into the build
logs.
Fixes: 2105acbe2804 ("kernel-headers: fix compile error caused by wrong host
include path when the toolchain is already built")
Signed-off-by: Petr Štetiar
---
toolchain/kernel-headers/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/toolchain/kernel-headers/Makefile
b/toolchain/kernel-headers/Makefile
index 5e3e459a96f5..8e3324816bfa 100644
--- a/toolchain/kernel-headers/Makefile
+++ b/toolchain/kernel-headers/Makefile
@@ -93,7 +93,6 @@ define Host/Prepare
endef
define Host/Configure
- env
yes '' | $(HOST_KMAKE) oldconfig
$(call Host/Configure/all)
$(call Host/Configure/post/$(ARCH))
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ipq807x: prpl-haze: fix sysupgrade flashing from bootloader
While flashing sysupgrade image from U-Boot, then the rootfs_data overlay filesystem formatting is left for the fstools during firstboot, but that wont work as mkfs.f2fs is missing in the sysupgrade image: mount_root: overlay filesystem in /dev/loop0 has not been formatted yet mount_root: no usable overlay filesystem found, using tmpfs overlay sh: mkfs.f2fs: not found FilesystemSize Used Available Use% Mounted on /dev/loop0 139.6M 46.9M 92.6M 34% /overlay Number Start (sector)End (sector) Size Code Name 20 98850 406349 150.1 MiB rootfs So lets fix it by adding f2fs support to the sysupgrade image. Signed-off-by: Petr Štetiar --- target/linux/qualcommax/image/ipq807x.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target/linux/qualcommax/image/ipq807x.mk b/target/linux/qualcommax/image/ipq807x.mk index 54f8caf5d7a2..555c723c5f42 100644 --- a/target/linux/qualcommax/image/ipq807x.mk +++ b/target/linux/qualcommax/image/ipq807x.mk @@ -115,7 +115,8 @@ define Device/prpl_haze DEVICE_MODEL := Haze DEVICE_DTS_CONFIG := config@hk09 SOC := ipq8072 - DEVICE_PACKAGES += ath11k-firmware-qcn9074 ipq-wifi-prpl_haze kmod-ath11k-pci + DEVICE_PACKAGES += ath11k-firmware-qcn9074 ipq-wifi-prpl_haze kmod-ath11k-pci \ + mkf2fs f2fsck kmod-fs-f2fs endef TARGET_DEVICES += prpl_haze ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH-22.03 01/10] ipq40xx: Support Chromium OS image-type creation
open...@aiyionpri.me [2023-04-07 15:23:39]:
Hi Jan,
> This series intends to support Google WiFi device 'Gale'.
IMHO it screams "a lot of regressions" in exchange for adding support for a
_single_ device into sixth stable release of 22.03, and considering that we've
23.05 already in the works, I'm sorry, but I'm going to reject this
contribution.
> I think I found all relevant commits and testing looked promising.
Looking at the ipq-wifi fallout, it looks like you've made some backports into
22.03 already?
> diff --git a/package/base-files/files/lib/upgrade/common.sh
> b/package/base-files/files/lib/upgrade/common.sh
> index 24ff77a8b3..5af061f6a4 100644
> --- a/package/base-files/files/lib/upgrade/common.sh
> +++ b/package/base-files/files/lib/upgrade/common.sh
> @@ -155,9 +155,11 @@ export_bootdevice() {
> fi
> done
> ;;
> + PARTUUID=----??0?/PARTNROFF=1 | \
> PARTUUID=----??02)
> uuid="${rootpart#PARTUUID=}"
> - uuid="${uuid%02}00"
> + uuid="${uuid%/PARTNROFF=1}"
> + uuid="${uuid%0?}00"
> for disk in $(find /dev -type b); do
> set -- $(dd if=$disk bs=1 skip=568 count=16
> 2>/dev/null | hexdump -v -e '8/1 "%02x "" "2/1 "%02x""-"6/1 "%02x"')
> if [ "$4$3$2$1-$6$5-$8$7-$9" = "$uuid" ]; then
sysupgrade path, very high regression potential, not a bugfix, so not going to
consider merging it.
> diff --git a/package/firmware/ipq-wifi/Makefile
> b/package/firmware/ipq-wifi/Makefile
> index be9b547cd0..74d789bdf6 100644
> --- a/package/firmware/ipq-wifi/Makefile
> +++ b/package/firmware/ipq-wifi/Makefile
> @@ -43,6 +43,7 @@ ALLWIFIBOARDS:= \
> glinet_gl-ap1300 \
> glinet_gl-b2200 \
> glinet_gl-s1300 \
> + google_wifi \
> linksys_ea8300 \
> linksys_mr8300-v0 \
> luma_wrtq-329acn \
This doesn't apply, looks like you're not even using 22.03 as a base for this
contribution?
> This effectively reverts upstream Linux commit 13e77747800e ("firmware:
> qcom: scm: Use atomic SCM for cold boot"), because Google WiFi boot
> firmwares don't support the atomic variant.
>
> This fixes SMP support for Google WiFi.
This is actually a fix, but needed just for the device being added, but still
might bring in some regression potential.
Cheers,
Petr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/5] Fix missing TLS v1.3 support with OpenSSL
Hi, current default official images on all devices are using mbedTLS 2.y which doesn't support TLS v1.3 (#12874), so lets fix it by using OpenSSL on devices which should have enough storage space to accomodate additional ~1.5MB (rough estimate didn't measured it). This is just my first quick attempt to implement one of the possible solutions, since I think, that using mbedTLS 3.y is not an option for backport into 23.05. Cheers, Petr Petr Štetiar (5): build: add GRAND_FLASH feature build: add WIRELESS_SUPPORT feature treewide: unify wireless feature handling target: grand flash devices should use OpenSSL treewide: mark grand_flash targets config/Config-build.in| 20 include/target.mk | 28 ++- scripts/target-metadata.pl| 2 + target/Config.in | 9 target/linux/airoha/Makefile | 2 +- target/linux/apm821xx/Makefile| 2 +- target/linux/apm821xx/image/sata.mk | 2 +- target/linux/apm821xx/nand/target.mk | 2 +- .../apm821xx/sata/profiles/00-default.mk | 2 +- .../archs38/generic/profiles/00-default.mk| 2 +- target/linux/archs38/generic/target.mk| 2 +- target/linux/armsr/Makefile | 2 +- target/linux/ath25/Makefile | 4 +- target/linux/ath79/Makefile | 2 +- target/linux/ath79/generic/target.mk | 2 - target/linux/ath79/image/generic-ubnt.mk | 2 +- target/linux/ath79/image/generic.mk | 10 ++-- target/linux/ath79/mikrotik/target.mk | 2 +- target/linux/ath79/nand/target.mk | 2 - target/linux/ath79/tiny/target.mk | 2 - target/linux/bcm27xx/Makefile | 3 +- target/linux/bcm27xx/image/Makefile | 8 +-- .../generic/profiles/101-Broadcom-wl.mk | 2 +- .../generic/profiles/105-Broadcom-none.mk | 2 +- .../generic/profiles/201-Broadcom-b44-wl.mk | 2 +- .../generic/profiles/205-Broadcom-b44-none.mk | 2 +- .../generic/profiles/211-Broadcom-tg3-wl.mk | 2 +- .../generic/profiles/215-Broadcom-tg3-none.mk | 2 +- .../generic/profiles/221-Broadcom-bgmac-wl.mk | 2 +- .../profiles/225-Broadcom-bgmac-none.mk | 2 +- .../bcm47xx/generic/profiles/PS-1208MFG.mk| 2 +- target/linux/bcm47xx/generic/target.mk| 4 +- .../legacy/profiles/101-Broadcom-wl.mk| 2 +- target/linux/bcm47xx/legacy/target.mk | 4 +- .../mips74k/profiles/102-Broadcom-wl.mk | 2 +- .../mips74k/profiles/103-Broadcom-none.mk | 2 +- target/linux/bcm47xx/mips74k/target.mk| 3 +- target/linux/bcm4908/Makefile | 2 +- target/linux/bcm53xx/generic/target.mk| 1 + target/linux/bcm53xx/image/Makefile | 9 ++-- target/linux/bcm63xx/Makefile | 2 +- target/linux/bcm63xx/image/Makefile | 10 ++-- target/linux/bcm63xx/profiles/default.mk | 2 +- target/linux/bmips/Makefile | 2 +- target/linux/bmips/image/Makefile | 4 +- target/linux/bmips/image/bcm63268.mk | 8 +-- target/linux/bmips/image/bcm6362.mk | 2 +- target/linux/gemini/Makefile | 2 +- target/linux/ipq40xx/Makefile | 4 +- target/linux/ipq806x/Makefile | 4 +- target/linux/ipq807x/Makefile | 4 +- target/linux/kirkwood/Makefile| 2 +- target/linux/kirkwood/image/Makefile | 49 --- target/linux/lantiq/Makefile | 2 +- target/linux/lantiq/image/amazonse.mk | 6 ++- target/linux/lantiq/image/ar9.mk | 18 +++ target/linux/lantiq/image/danube.mk | 29 +-- target/linux/lantiq/image/falcon.mk | 18 +-- target/linux/lantiq/image/tp-link.mk | 8 +-- target/linux/lantiq/image/vr9.mk | 39 --- target/linux/lantiq/image/xway_legacy.mk | 10 ++-- target/linux/layerscape/Makefile | 2 +- target/linux/malta/Makefile | 4 +- target/linux/mediatek/Makefile| 3 +- target/linux/mediatek/filogic/target.mk | 2 +- target/linux/mediatek/mt7622/target.mk| 2 +- target/linux/mpc85xx/Makefile | 4 +- target/linux/mvebu/Makefile | 2 +- target/linux/mvebu/image/cortexa53.mk | 10 +++- target/linux/mvebu/image/cortexa72.mk | 12 +++-- target/linux/mvebu/image/cortexa9.mk | 28 +++ target/linux/omap/Makefile| 2 +- target/linux/omap/profiles/00-default.mk | 3 +- target/linux/oxnas/Makefile | 2 +- target/linux/oxnas/image/ox810se.mk | 1 + target/linux/oxnas/image/ox820.mk | 10 ++-- target/linux/qoriq/Makefile | 3
[PATCH 4/5] target: grand flash devices should use OpenSSL
During the years we've learned it hard way, that we needed to make a lot of compromises while using flash space friendly micro TLS libraries like mbedTLS/wolfSSL in order to provide more or less up to date security features on most supported devices. Most of the recent and decent devices have plenty of storage space, so there is no need to make such compromises anymore and we could simply use battle tested OpenSSL on such targets by default as storage space increase is around 1.5 MiB, which is no brainer. So lets make it possible to use OpenSSL on grand flash devices and switch to libustream-openssl and wpad-basic-openssl by default there. This should have no functional change, the target needs to actually explicitly define `FEATURES := grand_flash` in order to have OpenSSL by default. References: #12874 Signed-off-by: Petr Štetiar --- config/Config-build.in | 20 include/target.mk | 24 ++-- target/Config.in | 3 +++ 3 files changed, 45 insertions(+), 2 deletions(-) diff --git a/config/Config-build.in b/config/Config-build.in index df2d9101ca99..10c77cafdc6b 100644 --- a/config/Config-build.in +++ b/config/Config-build.in @@ -130,6 +130,26 @@ menu "Global build settings" Useful for release builds, so that kernel issues can be debugged offline later. + choice + prompt "TLS provider" + default TLS_PROVIDER_MBEDTLS if !GRAND_FLASH + default TLS_PROVIDER_OPENSSL if GRAND_FLASH + help + This allows to select TLS provider. + + config TLS_PROVIDER_MBEDTLS + bool "mbedTLS" + select PACKAGE_libustream-mbedtls + + config TLS_PROVIDER_OPENSSL + bool "OpenSSL" + select PACKAGE_libustream-openssl + + config TLS_PROVIDER_WOLFSSL + bool "wolfSSL" + select PACKAGE_libustream-wolfssl + endchoice + menu "Kernel build options" source "config/Config-kernel.in" diff --git a/include/target.mk b/include/target.mk index 14c202d013d9..450823eb9280 100644 --- a/include/target.mk +++ b/include/target.mk @@ -38,10 +38,30 @@ DEFAULT_PACKAGES+=procd-ujail endif # mbedTLS wireless features handling +ifeq ($(CONFIG_TLS_PROVIDER_MBEDTLS),y) DEFAULT_PACKAGES+=libustream-mbedtls PACKAGE_NO_WIRELESS:=-wpad-basic-mbedtls -ifneq($(CONFIG_WIRELESS_SUPPORT),) -DEFAULT_PACKAGES+=wpad-basic-mbedtls + ifneq ($(CONFIG_WIRELESS_SUPPORT),) +DEFAULT_PACKAGES+=wpad-basic-mbedtls + endif +endif + +# OpenSSL and wireless features handling +ifeq ($(CONFIG_TLS_PROVIDER_OPENSSL),y) +DEFAULT_PACKAGES+=libustream-openssl +PACKAGE_NO_WIRELESS:=-wpad-basic-openssl + ifneq ($(CONFIG_WIRELESS_SUPPORT),) +DEFAULT_PACKAGES+=wpad-basic-openssl + endif +endif + +# wolfSSL wireless features handling +ifeq ($(CONFIG_TLS_PROVIDER_WOLFSSL),y) +DEFAULT_PACKAGES+=libustream-wolfssl +PACKAGE_NO_WIRELESS:=-wpad-basic-wolfssl + ifneq ($(CONFIG_WIRELESS_SUPPORT),) +DEFAULT_PACKAGES+=wpad-basic-wolfssl + endif endif # include seccomp ld-preload hooks if kernel supports it diff --git a/target/Config.in b/target/Config.in index 195f7161a89b..1099cd9c3db1 100644 --- a/target/Config.in +++ b/target/Config.in @@ -124,6 +124,9 @@ config USES_BOOT_PART config WIRELESS_SUPPORT bool + select PACKAGE_wpad-basic-mbedtls if TLS_PROVIDER_MBEDTLS + select PACKAGE_wpad-basic-openssl if TLS_PROVIDER_OPENSSL + select PACKAGE_wpad-basic-wolfssl if TLS_PROVIDER_WOLFSSL # Architecture selection ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 5/5] treewide: mark grand_flash targets
Select targets which should've plenty of storage to enable additional features like OpenSSL by default for example. References: #12874 Signed-off-by: Petr Štetiar --- target/linux/airoha/Makefile | 2 +- target/linux/armsr/Makefile | 2 +- target/linux/bcm27xx/Makefile| 3 ++- target/linux/bcm4908/Makefile| 2 +- target/linux/gemini/Makefile | 2 +- target/linux/ipq806x/Makefile| 2 +- target/linux/ipq807x/Makefile| 2 +- target/linux/layerscape/Makefile | 2 +- target/linux/malta/Makefile | 2 +- target/linux/mediatek/Makefile | 3 ++- target/linux/qoriq/Makefile | 3 ++- target/linux/rockchip/Makefile | 3 ++- target/linux/sifiveu/Makefile| 2 +- target/linux/sunxi/Makefile | 2 +- target/linux/tegra/Makefile | 3 ++- target/linux/uml/Makefile| 2 +- target/linux/x86/Makefile| 2 +- target/linux/zynq/Makefile | 2 +- 18 files changed, 23 insertions(+), 18 deletions(-) diff --git a/target/linux/airoha/Makefile b/target/linux/airoha/Makefile index 723bec8cd434..61b47b0ca2ba 100644 --- a/target/linux/airoha/Makefile +++ b/target/linux/airoha/Makefile @@ -4,7 +4,7 @@ ARCH:=arm BOARD:=airoha BOARDNAME:=Airoha ARM CPU_TYPE:=cortex-a7 -FEATURES:=dt squashfs nand ramdisk gpio source-only +FEATURES:=dt squashfs nand ramdisk gpio source-only grand_flash KERNEL_PATCHVER:=5.15 diff --git a/target/linux/armsr/Makefile b/target/linux/armsr/Makefile index b34500ed8a59..aabf3570e163 100644 --- a/target/linux/armsr/Makefile +++ b/target/linux/armsr/Makefile @@ -7,7 +7,7 @@ include $(TOPDIR)/rules.mk BOARD:=armsr BOARDNAME:=Arm SystemReady (EFI) compliant FEATURES:=fpu pci pcie rtc usb boot-part rootfs-part -FEATURES+=cpiogz ext4 ramdisk squashfs targz vmdk +FEATURES+=cpiogz ext4 ramdisk squashfs targz vmdk grand_flash KERNEL_PATCHVER:=6.1 diff --git a/target/linux/bcm27xx/Makefile b/target/linux/bcm27xx/Makefile index 3f9efb9f008a..5fa090324c08 100644 --- a/target/linux/bcm27xx/Makefile +++ b/target/linux/bcm27xx/Makefile @@ -8,7 +8,8 @@ include $(TOPDIR)/rules.mk ARCH:=arm BOARD:=bcm27xx BOARDNAME:=Broadcom BCM27xx -FEATURES:=audio boot-part display ext4 fpu gpio rootfs-part rtc squashfs usb usbgadget wireless +FEATURES:=audio boot-part display ext4 fpu gpio +FEATURES+=rootfs-part rtc squashfs usb usbgadget wireless grand_flash SUBTARGETS:=bcm2708 bcm2709 bcm2710 bcm2711 KERNEL_PATCHVER:=6.1 diff --git a/target/linux/bcm4908/Makefile b/target/linux/bcm4908/Makefile index 2d848b50c69a..59fece1f94ab 100644 --- a/target/linux/bcm4908/Makefile +++ b/target/linux/bcm4908/Makefile @@ -5,7 +5,7 @@ include $(TOPDIR)/rules.mk ARCH:=aarch64 BOARD:=bcm4908 BOARDNAME:=Broadcom BCM4908 (ARMv8A CPUs Brahma-B53) -FEATURES:=squashfs nand usb gpio +FEATURES:=squashfs nand usb gpio grand_flash CPU_TYPE:=cortex-a53 SUBTARGETS:=generic diff --git a/target/linux/gemini/Makefile b/target/linux/gemini/Makefile index 284d1247cb23..4d533cb96da3 100644 --- a/target/linux/gemini/Makefile +++ b/target/linux/gemini/Makefile @@ -7,7 +7,7 @@ include $(TOPDIR)/rules.mk ARCH:=arm BOARD:=gemini BOARDNAME:=Cortina Systems CS351x -FEATURES:=squashfs pci rtc usb dt gpio display ext4 rootfs-part boot-part +FEATURES:=squashfs pci rtc usb dt gpio display ext4 rootfs-part boot-part grand_flash CPU_TYPE:=fa526 SUBTARGETS:=generic diff --git a/target/linux/ipq806x/Makefile b/target/linux/ipq806x/Makefile index 3ebf17c933f6..b47df88ee56f 100644 --- a/target/linux/ipq806x/Makefile +++ b/target/linux/ipq806x/Makefile @@ -5,7 +5,7 @@ include $(TOPDIR)/rules.mk ARCH:=arm BOARD:=ipq806x BOARDNAME:=Qualcomm Atheros IPQ806X -FEATURES:=squashfs fpu ramdisk wireless +FEATURES:=squashfs fpu ramdisk wireless grand_flash CPU_TYPE:=cortex-a15 CPU_SUBTYPE:=neon-vfpv4 SUBTARGETS:=generic chromium diff --git a/target/linux/ipq807x/Makefile b/target/linux/ipq807x/Makefile index a16ecf4c8abc..8e1567afdf03 100644 --- a/target/linux/ipq807x/Makefile +++ b/target/linux/ipq807x/Makefile @@ -3,7 +3,7 @@ include $(TOPDIR)/rules.mk ARCH:=aarch64 BOARD:=ipq807x BOARDNAME:=Qualcomm Atheros IPQ807x -FEATURES:=squashfs ramdisk fpu nand rtc emmc wireless +FEATURES:=squashfs ramdisk fpu nand rtc emmc wireless grand_flash KERNELNAME:=Image dtbs CPU_TYPE:=cortex-a53 SUBTARGETS:=generic diff --git a/target/linux/layerscape/Makefile b/target/linux/layerscape/Makefile index 23672602529e..735971226953 100644 --- a/target/linux/layerscape/Makefile +++ b/target/linux/layerscape/Makefile @@ -9,7 +9,7 @@ BOARDNAME:=NXP Layerscape KERNEL_PATCHVER:=5.15 -FEATURES:=squashfs nand usb pcie gpio fpu ubifs ext4 rootfs-part boot-part +FEATURES:=squashfs nand usb pcie gpio fpu ubifs ext4 rootfs-part boot-part grand_flash SUBTARGETS:=armv8_64b armv7 define Target/Description diff --git a/target/linux/malta/Makefile b/target/linux/malta/Makefile index 537c2966a233..13306752f99b 100644 --- a/target/linux/malta/Makefile +++ b/target/linux/malta/Makefile @@ -8,7
[PATCH 2/5] build: add WIRELESS_SUPPORT feature
So we can clearly mark targets having wireless support.
Signed-off-by: Petr Štetiar
---
scripts/target-metadata.pl | 1 +
target/Config.in | 3 +++
2 files changed, 4 insertions(+)
diff --git a/scripts/target-metadata.pl b/scripts/target-metadata.pl
index aa81301dc5f2..f25df0809671 100755
--- a/scripts/target-metadata.pl
+++ b/scripts/target-metadata.pl
@@ -49,6 +49,7 @@ sub target_config_features(@) {
/^usb$/ and $ret .= "\tselect USB_SUPPORT\n";
/^usbgadget$/ and $ret .= "\tselect USB_GADGET_SUPPORT\n";
/^virtio$/ and $ret .= "\tselect VIRTIO_SUPPORT\n";
+ /^wireless$/ and $ret .= "\tselect WIRELESS_SUPPORT\n";
}
return $ret;
}
diff --git a/target/Config.in b/target/Config.in
index b1c99b63000a..195f7161a89b 100644
--- a/target/Config.in
+++ b/target/Config.in
@@ -122,6 +122,9 @@ config USES_ROOTFS_PART
config USES_BOOT_PART
bool
+config WIRELESS_SUPPORT
+ bool
+
# Architecture selection
config aarch64
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/5] build: add GRAND_FLASH feature
So we can mark targets which have enough flash space to accomodate
certain features.
Signed-off-by: Petr Štetiar
---
scripts/target-metadata.pl | 1 +
target/Config.in | 3 +++
2 files changed, 4 insertions(+)
diff --git a/scripts/target-metadata.pl b/scripts/target-metadata.pl
index e1d4ef242b86..aa81301dc5f2 100755
--- a/scripts/target-metadata.pl
+++ b/scripts/target-metadata.pl
@@ -21,6 +21,7 @@ sub target_config_features(@) {
/^ext4$/ and $ret .= "\tselect USES_EXT4\n";
/^fpu$/ and $ret .= "\tselect HAS_FPU\n";
/^gpio$/ and $ret .= "\tselect GPIO_SUPPORT\n";
+ /^grand_flash$/ and $ret .= "\tselect GRAND_FLASH\n";
/^jffs2$/ and $ret .= "\tselect USES_JFFS2\n";
/^jffs2_nand$/ and $ret .= "\tselect USES_JFFS2_NAND\n";
/^legacy-sdcard$/ and $ret .= "\tselect
LEGACY_SDCARD_SUPPORT\n";
diff --git a/target/Config.in b/target/Config.in
index ac0f1f9826bf..b1c99b63000a 100644
--- a/target/Config.in
+++ b/target/Config.in
@@ -88,6 +88,9 @@ config LOW_MEMORY_FOOTPRINT
config SMALL_FLASH
bool
+config GRAND_FLASH
+ bool
+
config NOMMU
bool
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/3] treewide: fix shell errors during dump stage
Fixes following issues:
bash: -c: line 1: `echo 1686820180 |
/staging_dir/host/bin/mkhash md5 | cut -b1-8'
bash: -c: line 1: `echo 1686820180 |
/staging_dir/host/bin/mkhash md5 | sed -E
's/(.{8})(.{4})(.{4})(.{4})(.{10})../\1-\2-\3-\4-\500/''
bash: -c: line 1: syntax error near unexpected token `|'
bash: line 1: *1024*1024: syntax error: operand expected (error token is
"*1024*1024")
bash: line 1: (64 + ): syntax error: operand expected (error token is ")")
expr: syntax error: missing argument after '+'
Signed-off-by: Petr Štetiar
---
include/image.mk | 4
target/linux/layerscape/image/Makefile | 3 +++
target/linux/mediatek/image/filogic.mk | 2 ++
target/linux/mediatek/image/mt7622.mk | 2 ++
target/linux/mediatek/image/mt7623.mk | 4
5 files changed, 15 insertions(+)
diff --git a/include/image.mk b/include/image.mk
index fae4d32a8bb9..fde0e0ea4fd7 100644
--- a/include/image.mk
+++ b/include/image.mk
@@ -40,8 +40,10 @@ IMG_PREFIX_VERCODE:=$(if
$(CONFIG_VERSION_CODE_FILENAMES),$(call sanitize,$(VERS
IMG_PREFIX:=$(VERSION_DIST_SANITIZED)-$(IMG_PREFIX_VERNUM)$(IMG_PREFIX_VERCODE)$(IMG_PREFIX_EXTRA)$(BOARD)$(if
$(SUBTARGET),-$(SUBTARGET))
IMG_ROOTFS:=$(IMG_PREFIX)-rootfs
IMG_COMBINED:=$(IMG_PREFIX)-combined
+ifeq ($(DUMP),)
IMG_PART_SIGNATURE:=$(shell echo $(SOURCE_DATE_EPOCH)$(LINUX_VERMAGIC) |
$(MKHASH) md5 | cut -b1-8)
IMG_PART_DISKGUID:=$(shell echo $(SOURCE_DATE_EPOCH)$(LINUX_VERMAGIC) |
$(MKHASH) md5 | sed -E 's/(.{8})(.{4})(.{4})(.{4})(.{10})../\1-\2-\3-\4-\500/')
+endif
MKFS_DEVTABLE_OPT := -D $(INCLUDE_DIR)/device_table.txt
@@ -167,7 +169,9 @@ define Image/pad-to
mv $(1).new $(1)
endef
+ifeq ($(DUMP),)
ROOTFS_PARTSIZE=$(shell echo $$(($(CONFIG_TARGET_ROOTFS_PARTSIZE)*1024*1024)))
+endif
define Image/pad-root-squashfs
$(call Image/pad-to,$(KDIR)/root.squashfs,$(if
$(1),$(1),$(ROOTFS_PARTSIZE)))
diff --git a/target/linux/layerscape/image/Makefile
b/target/linux/layerscape/image/Makefile
index 52dc532c34f2..bf6f33e5a026 100644
--- a/target/linux/layerscape/image/Makefile
+++ b/target/linux/layerscape/image/Makefile
@@ -8,8 +8,11 @@ include $(INCLUDE_DIR)/image.mk
LS_SD_KERNELPART_SIZE = 40
LS_SD_KERNELPART_OFFSET = 16
LS_SD_ROOTFSPART_OFFSET = 64
+
+ifeq ($(DUMP),)
LS_SD_IMAGE_SIZE = $(shell echo $$((($(LS_SD_ROOTFSPART_OFFSET) + \
$(CONFIG_TARGET_ROOTFS_PARTSIZE)
+endif
# The limitation of flash sysupgrade.bin is 1MB dtb + 16MB kernel + 32MB rootfs
LS_SYSUPGRADE_IMAGE_SIZE = 49m
diff --git a/target/linux/mediatek/image/filogic.mk
b/target/linux/mediatek/image/filogic.mk
index 6323a05de2a6..9511fe052f51 100644
--- a/target/linux/mediatek/image/filogic.mk
+++ b/target/linux/mediatek/image/filogic.mk
@@ -130,7 +130,9 @@ define Device/bananapi_bpi-r3
pad-to 64M | append-image
squashfs-sysupgrade.itb | check-size |\
) \
gzip
+ifeq ($(DUMP),)
IMAGE_SIZE := $$(shell expr 64 + $$(CONFIG_TARGET_ROOTFS_PARTSIZE))m
+endif
KERNEL := kernel-bin | gzip
KERNEL_INITRAMFS := kernel-bin | lzma | \
fit lzma $$(KDIR)/image-$$(firstword $$(DEVICE_DTS)).dtb with-initrd |
pad-to 64k
diff --git a/target/linux/mediatek/image/mt7622.mk
b/target/linux/mediatek/image/mt7622.mk
index 040ef957db9a..e162a5df95bd 100644
--- a/target/linux/mediatek/image/mt7622.mk
+++ b/target/linux/mediatek/image/mt7622.mk
@@ -93,7 +93,9 @@ define Device/bananapi_bpi-r64
pad-to 46080k | append-image
squashfs-sysupgrade.itb | check-size |\
) \
gzip
+ifeq ($(DUMP),)
IMAGE_SIZE := $$(shell expr 45 + $$(CONFIG_TARGET_ROOTFS_PARTSIZE))m
+endif
KERNEL := kernel-bin | gzip
KERNEL_INITRAMFS := kernel-bin | lzma | fit lzma
$$(DTS_DIR)/$$(DEVICE_DTS).dtb with-initrd | pad-to 128k
IMAGE/sysupgrade.itb := append-kernel | fit gzip
$$(DTS_DIR)/$$(DEVICE_DTS).dtb external-static-with-rootfs | append-metadata
diff --git a/target/linux/mediatek/image/mt7623.mk
b/target/linux/mediatek/image/mt7623.mk
index 5828c4d763d9..2c4402da6619 100644
--- a/target/linux/mediatek/image/mt7623.mk
+++ b/target/linux/mediatek/image/mt7623.mk
@@ -96,7 +96,9 @@ define Device/bananapi_bpi-r2
KERNEL := kernel-bin | gzip
KERNEL_INITRAMFS_SUFFIX := -recovery.itb
KERNEL_INITRAMFS := kernel-bin | gzip | fit gzip
$$(DTS_DIR)/$$(DEVICE_DTS).dtb with-initrd
+ifeq ($(DUMP),)
IMAGE_SIZE := $$(shell expr 48 + $$(CONFIG_TARGET_ROOTFS_PARTSIZE))m
+endif
IMAGE/sysupgrade.itb := append-kernel | fit gzip
$$(DTS_DIR)/$$(DEVICE_DTS).dtb external-static-with-rootfs | append-metadata
ARTIFACT/preloader.bin := mt7623-mbr emmc |\
pad-to 2k | append-preloader $$(UBOOT_TARGET)
@
[PATCH 1/3] target.mk: silence CPU_TYPE doesn't correspond to a known type
Following command: $ ./scripts/dump-target-info.pl targets currently generates bunch of following warnings: include/target.mk:269: CPU_TYPE "cortex-a15" doesn't correspond to a known type just because there is no CPU_CFLAGS_cortexa-15 defined for that CPU and there is no value in this warning, so lets acknowledge such CPU_TYPEs and do not print those warnings. Signed-off-by: Petr Štetiar --- include/target.mk | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/include/target.mk b/include/target.mk index b5e3e7ff6fde..1783f8f94f9d 100644 --- a/include/target.mk +++ b/include/target.mk @@ -264,9 +264,13 @@ ifeq ($(DUMP),1) CPU_TYPE ?= riscv64 CPU_CFLAGS_riscv64:=-mabi=lp64d -march=rv64imafdc endif + DONOT_WARN_CPU_TYPES=arm1176jzf-s arm926ej-s cortex-a15 cortex-a5 cortex-a7 cortex-a72 \ +cortex-a8 cortex-a9 fa526 mpcore xscale ifneq ($(CPU_TYPE),) ifndef CPU_CFLAGS_$(CPU_TYPE) - $(warning CPU_TYPE "$(CPU_TYPE)" doesn't correspond to a known type) + ifeq (,$(findstring $(CPU_TYPE),$(DONOT_WARN_CPU_TYPES))) +$(warning CPU_TYPE "$(CPU_TYPE)" doesn't correspond to a known type) + endif endif endif DEFAULT_CFLAGS=$(strip $(CPU_CFLAGS) $(CPU_CFLAGS_$(CPU_TYPE)) $(CPU_CFLAGS_$(CPU_SUBTYPE))) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/3] scan.mk: do not silence output of dump phase
Make it easier to spot currently hidden issues:
$ make defconfig V=sc
...
Collecting target info: target/linux/airohabash: -c: line 1: syntax error near
unexpected token `|'
bash: -c: line 1: `echo 1686815253 |
staging_dir/host/bin/mkhash md5 | cut -b1-8'
bash: -c: line 1: syntax error near unexpected token `|'
bash: -c: line 1: `echo 1686815253 |
staging_dir/host/bin/mkhash md5 | sed -E
's/(.{8})(.{4})(.{4})(.{4})(.{10})../\1-\2-\3-\4-\500/''
...
Signed-off-by: Petr Štetiar
---
include/scan.mk | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/scan.mk b/include/scan.mk
index 33a5832ff5f2..2e0ee0c96099 100644
--- a/include/scan.mk
+++ b/include/scan.mk
@@ -50,7 +50,8 @@ define PackageDir
$$(call progress,Collecting $(SCAN_NAME) info:
$(SCAN_DIR)/$(2)) \
echo Source-Makefile: $(SCAN_DIR)/$(2)/Makefile; \
$(if $(3),echo Override: $(3),true); \
- $(NO_TRACE_MAKE) --no-print-dir -r DUMP=1 FEED="$(call
feedname,$(2))" -C $(SCAN_DIR)/$(2) $(SCAN_MAKEOPTS) 2>/dev/null || { \
+ $(if $(findstring
c,$(OPENWRT_VERBOSE)),$(MAKE),$(NO_TRACE_MAKE) --no-print-dir) -r DUMP=1
FEED="$(call feedname,$(2))" -C $(SCAN_DIR)/$(2) $(SCAN_MAKEOPTS) \
+ $(if $(findstring c,$(OPENWRT_VERBOSE)),,2>/dev/null)
|| { \
mkdir -p "$(TOPDIR)/logs/$(SCAN_DIR)/$(2)"; \
$(NO_TRACE_MAKE) --no-print-dir -r DUMP=1 FEED="$(call
feedname,$(2))" -C $(SCAN_DIR)/$(2) $(SCAN_MAKEOPTS) >
$(TOPDIR)/logs/$(SCAN_DIR)/$(2)/dump.txt 2>&1; \
$$(call progress,ERROR: please fix
$(SCAN_DIR)/$(2)/Makefile - see logs/$(SCAN_DIR)/$(2)/dump.txt for details\n) \
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Switching 22.03 build base to Debian 11 as well [Was: Re: Upgrading buildbot and switching to Debian 11]
Hi, > Petr Štetiar [2023-05-15 17:35:04]: > > > FYI, just started moving master buildbot server to a new hardware and will > > move snapshot builds there first to iron out any remaining issues. > > > > While at it I'm updating it to the latest buildbot 3.8.0 release and > > switching > > base container images from Debian 10 to Debian 11[1]: > > > > "Debian 10 LTS support ends on 6/2024, so it makes no sense to use it as > > a base for 23.05 release, so lets switch to Debian 11 which should've > > LTS support till 6/2026." > > > > I'll try to keep you updated during transition. > > So snapshot phase1/images just finished one full build cycle on the new > setup[1] and images should be ready for download and testing. > > Currently phase2/packages are being crunched[2] and should should be > available in ~12h or so. > > The next steps are roughly following: > > * prepare the infra for 23.05 > * migrate over 22.03 it has been a month already, so it seems like a switch to Debian 11 as a base went fine, without regressions, so IMO we're probably good to go and use the same Debian 11 base for 22.03 as well? Any objections? BTW speaking about Debian 11, I was made aware on IRC, that there is Debian 12 around the corner: < dwfreed> also, before putting in all this effort to move to debian 11, why not wait a month or so and move to debian 12 once the post-release dust settles? < dwfreed> it literally releases in a 3 days (barring last minute emergencies, Debian 12 will be released on the 10th) < dwfreed> realistically, you could most likely move to debian 12 now < dwfreed> most of the post release bugs are going to be in desktop, which is obviously not applicable here Since we're still in RC phase for 23.05 it might be worth considering? Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
armvirt -> armsr target rename [Was: Re: EFI / SystemReady support for OpenWrt on arm64]
Hi, FYI there is an ongoing effort[1] to rename armvirt target to armsr (Arm SystemReady) armvirt/32 becomes armsr/armv7 (title: 32-bit (armv7) machines) armvirt/64 becomes armsr/armv8 (title: 64-bit (armv8) machines) BOARDNAME:=Arm SystemReady compliant (EFI) armv7/armv8 subtarget seems like a good fit for possibly upcoming armv9. Should you've any objections or better ideas, please speak now otherwise I'm going to merge this during a weekend, there is a plan[2] already to backport this new naming scheme into the 23.05 as well. 1. https://github.com/openwrt/openwrt/pull/12832 2. https://github.com/openwrt/openwrt/pull/12817 Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Packages buildbot is erratic, both master and 23.05 packages fail often
Hannu Nyman [2023-06-03 11:27:03]: > Petr Štetiar kirjoitti 2.6.2023 klo 22.07: > > So having following in buildbot log: > > > > 2023-06-01 23:53:12+ [-] command timed out: 3600 seconds without > > output running [b'make', b'-j7', b'IGNORE_ERRORS=n m y', b'BUILD_LOG=1', > > b'CONFIG_AUTOREMOVE=y', b'CONFIG_SIGNED_PACKAGES='], attempting to kill > > 2023-06-01 23:53:12+ [-] trying to kill process group 1528179 > > > > I've looked at the system logs around that time and found following: > > > > Jun 01 22:23:19 audit[3844576]: AVC apparmor="DENIED" operation="mkdir" > > info="Failed name lookup - name too long" > > error=-36 profile="docker-default" > > > > name="/shared-workdir/build/sdk/build_dir/hostpkg/gettext-0.21.1/gettext-tools/confdir3/confdir3/confdir3/confdir3...[snip > > very long repeating pattern]... > > confdir3/confdir3/confdir3/confdir3/confdir3" pid=3844576 > > comm="conftest" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 > > Jun 01 22:23:45 kernel: conftest[3855174]: segfault at 0 ip > > 7fe9581067e7 sp 7ffd94ca2118 error 4 in > > libc-2.31.so[7fe958085000+159000] > > ... > > > > Since the host is shared with other 3 build workers I can't be sure, that it > > originated from that timeouted build. > > > > Looking at that observation about gettext and recursive "confdir3/", it is > plausible that gettext has problem that manifests in some builds, or trouble > with parallelism on some occasions. I looked into this further and its probably harmless (?) error caused by the Docker default Apparmor profile in configure checks around max path: tar-1.34/m4/getcwd-path-max.m4:#define DIR_NAME "confdir3" tar-1.34/configure:#define DIR_NAME "confdir3" I think it's harmless as its present on all other build workers as well. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Packages buildbot is erratic, both master and 23.05 packages fail often
Thibaut [2023-06-03 14:23:14]: Hi, > I wouldn’t pay too much attention to this build failure until the space > problems are resolved. the timeout issues are happening on the dual CPU servers, they've more disk space, so IMO it's something else in the play. > Running out of space can wreck havoc in many different ways and we may simply > be looking at side effects (possibly across containers) of that. I've restructured the OSUOSL OpenStack/VM based build workers yesterday, so hopefully out of space problems should be solved. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Packages buildbot is erratic, both master and 23.05 packages fail often
Thibaut [2023-06-03 14:18:07]: Hi, > Then again, it may also be a side effect of running out of space (possibly a > looped symlink?) Filesystem Size Used Avail Use% Mounted on /dev/mapper/lvm-builder 295G 168G 112G 61% /builder looks fine. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Packages buildbot is erratic, both master and 23.05 packages fail often
Thibaut [2023-06-02 11:09:48]: Hi, > the build is actually hung. dmesg might have more info. So having following in buildbot log: 2023-06-01 23:53:12+ [-] command timed out: 3600 seconds without output running [b'make', b'-j7', b'IGNORE_ERRORS=n m y', b'BUILD_LOG=1', b'CONFIG_AUTOREMOVE=y', b'CONFIG_SIGNED_PACKAGES='], attempting to kill 2023-06-01 23:53:12+ [-] trying to kill process group 1528179 I've looked at the system logs around that time and found following: Jun 01 22:23:19 audit[3844576]: AVC apparmor="DENIED" operation="mkdir" info="Failed name lookup - name too long" error=-36 profile="docker-default" name="/shared-workdir/build/sdk/build_dir/hostpkg/gettext-0.21.1/gettext-tools/confdir3/confdir3/confdir3/confdir3...[snip very long repeating pattern]... confdir3/confdir3/confdir3/confdir3/confdir3" pid=3844576 comm="conftest" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 Jun 01 22:23:45 kernel: conftest[3855174]: segfault at 0 ip 7fe9581067e7 sp 7ffd94ca2118 error 4 in libc-2.31.so[7fe958085000+159000] Jun 01 22:23:45 kernel: Code: 00 00 00 48 39 d1 0f 82 47 67 06 00 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 10 0f 82 fa 00 00 00 48 83 fa 20 0f 87 3f 01 00 00 <0f> 10 06 0f 10 4c 16 f0 0f 11 07 0f 11 4c 17 f0 c3 0f 1f 84 00 00 Since the host is shared with other 3 build workers I can't be sure, that it originated from that timeouted build. > I’m happy to share my config if interested, it’s not a very complex setup. That would be appreciated, thanks! > I’m confused with that sentence: the du step shows 36G used, but df says all > 60G are full; which suggests something *outside* of the build directory is > eating space? I just got following on openwrt-23.05 and osuosl-dock-02 build worker: 16Gdl 36Gshared-workdir 14Gshared-workdir/build/sdk/staging_dir 13Gshared-workdir/build/sdk/build_dir 8.6Gshared-workdir/build/sdk/tmp/go-build And looking at the other snapshot packages buildworkers, situation is similar on some of them: 17Gosuosl-dock-09/dl 17Gosuosl-dock-10/dl 17Gosuosl-dock-11/dl 17Gosuosl-dock-12/dl 38Gosuosl-dock-09/shared-workdir/build 35Gosuosl-dock-10/shared-workdir/build 3.3G osuosl-dock-11/shared-workdir/build 7.1G osuosl-dock-12/shared-workdir/build So probably some cruft accumulated in the shared-workdir for some reason, will dig deeper once I find some time. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Packages buildbot is erratic, both master and 23.05 packages fail often
Thibaut [2023-06-01 18:21:22]: Hi, > > There has been many timeouts of "3600 seconds without output" in master, > > These look like connectivity issues. I'm not sure, as there is a keep alive going on between master/worker so master would remove the worker quite sooner due to keep alive response timeout, wouldn't it? Putting asside some buildbot bugs of course. Workers osuosl-dock-09,10,11,12 are on one build host and osuosl-dock-05,06,07,08 are on the second build host, wouldn't they have same connectivity issues at the same time? I'm not saying it's not possible, there has been similar network issues in the past, so it might be it. > > and quite too many "out of space" errors in the 23.05 packages buildbot. > > 23.05 package builders are nearly all out of space, possibly due to > accumulated cruft in dl dir. from the quick look it seems like Rust has increased the disk space requirements in shared work directory. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Packages buildbot is erratic, both master and 23.05 packages fail often
Hannu Nyman [2023-06-01 19:11:13]: Hi, > * zabbix x13 (and borgbackup plus other python packages before it) seem to > be the typical last lines before he timeout failures... Random failures or > something due to recent changes ??? IIUC then from the buildbot master perspective it seems like the compilation got stuck somewhere for 1 hour, thats indeed quite strange. I don't remember seeing those errors previously. Anyway, as a quick fix attempt, I've now changed build worker CPU affinity, so each worker uses CPUs from the same NUMA node: NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,20,22 NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,21,23 -cpuset: 0-5 +cpuset: 0,2,4,6,8,10 We've 2 such hosts with 2x Xeon X5680 CPUs, having 4 build workers on each, using 6 CPUs for each build worker. So lets see if it improves the situation, I'll try to look at those build workers more closely now. > * with 23.05 the main problem seems to be "No space left on device"... I've noticed that as well, probably 23.05 is more disk space greedy and current 60GB allocation is not enough, so going to increase the disk size to fix that. I've just added 2x8 temporary build workers to cleanup the build queue and refresh the packages. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: EFI / SystemReady support for OpenWrt on arm64
Mathew McBride [2023-05-26 16:16:31]: Hi Mathew, > I am just wondering if anyone has any significant objections that would > stop this pull from being merged? (after I fix any current conflicts) we should support it, so we need to merge it. > 23.05 has branched and there is already a pull request for kernel 6.1 on > master ( https://github.com/openwrt/openwrt/pull/12705 ), which will force > a revision of this pull request. FYI it was merged. > I am willing to do the work for both branches but would like some > indication of any required changes first. Great, I don't see any such objections in the PR, so feel free to ping me once it's ready for 6.1, thanks! Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: target: Disable building devices with 8M, 16M and 32M RAM
Hi, > > There are plenty of very useful devices with 32M of RAM and OpenWrt is a > > life extender for them besides that work well. and you can still "use" those devices with 22.03 for another year or so. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Using Nitrokey 3A Mini for build artifact signing key storage
Petr Štetiar [2023-05-13 18:17:14]: Hi, > Current idea is to start using Nitrokey 3A Mini (nk3) USB security key for > this purpose, nk3 would contain single Ed25519 based signing key with 10 year > expiration, that means we're going to use single key for snapshot/release > signing. just provisioned the nk3 keys and pushed the public key[1], going to ship the keys to their designated destinations in the upcoming days. 1. https://git.openwrt.org/6b42a5c8b7dc049b899869b2a1b94daf69ceb2f5 Cheers, Petr signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Upgrading buildbot and switching to Debian 11
Petr Štetiar [2023-05-15 17:35:04]: Hi, > FYI, just started moving master buildbot server to a new hardware and will > move snapshot builds there first to iron out any remaining issues. > > While at it I'm updating it to the latest buildbot 3.8.0 release and switching > base container images from Debian 10 to Debian 11[1]: > > "Debian 10 LTS support ends on 6/2024, so it makes no sense to use it as > a base for 23.05 release, so lets switch to Debian 11 which should've > LTS support till 6/2026." > > I'll try to keep you updated during transition. So snapshot phase1/images just finished one full build cycle on the new setup[1] and images should be ready for download and testing. Currently phase2/packages are being crunched[2] and should should be available in ~12h or so. The next steps are roughly following: * prepare the infra for 23.05 * migrate over 22.03 * switch to https://buildbot.openwrt.org * decomission the old hardware, including the 21.02 build infra Thank you all involved for your support! 1. https://buildbot.staging.openwrt.org/images/ 2. https://buildbot.staging.openwrt.org/master/packages/ Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Upgrading buildbot and switching to Debian 11
Hi, FYI, just started moving master buildbot server to a new hardware and will move snapshot builds there first to iron out any remaining issues. While at it I'm updating it to the latest buildbot 3.8.0 release and switching base container images from Debian 10 to Debian 11[1]: "Debian 10 LTS support ends on 6/2024, so it makes no sense to use it as a base for 23.05 release, so lets switch to Debian 11 which should've LTS support till 6/2026." I'll try to keep you updated during transition. 1. https://github.com/openwrt/buildbot/pull/3/commits/f2c27d0084c9450e86e6534cc9ea2fcc92aa0828 Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Using Nitrokey 3A Mini for build artifact signing key storage
Hi, we're in the process of upgrading OpenWrt build infrastructure right now and there is a consensus, that its a good opportunity to improve handling of secret GnuPG keys used for build artifact signing. Current idea is to start using Nitrokey 3A Mini (nk3) USB security key for this purpose, nk3 would contain single Ed25519 based signing key with 10 year expiration, that means we're going to use single key for snapshot/release signing. Only 3 such identical nk3 dongles were provisioned[1], one nk3 dongle is going to be attached to the new buildbot master server, remaining two nk3 dongles are going to be kept as a backup (ynezz, jow). GnuPG master/secret keys are not available, only revocation certificate was generated, just in case. This new signing key 0xCAE438715492B555 available only from those three nk3 dongles was cross signed with 3 previous signing keys (snapshot, 21.02, 22.03): $ gpg --list-signatures 0xCAE438715492B555 pub ed25519/0xCAE438715492B555 2023-05-13 [C] [expires: 2033-05-10] Key fingerprint = E902 5ED8 43D0 FDC7 866F 7064 CAE4 3871 5492 B555 uid [ultimate] OpenWrt Build System (Nitrokey3) sig 30xCAE438715492B555 2023-05-13 OpenWrt Build System (Nitrokey3) sig 0xCD84BCED626471F1 2023-05-13 OpenWrt Build System (PGP key for unattended snapshot builds) sig 0xCD54E82DADB3684D 2023-05-13 OpenWrt Build System (GnuPGP key for 22.03 release builds) sig 0x88CA59E88F681580 2023-05-13 OpenWrt Build System (PGP key for 21.02 release builds) sub ed25519/0x78BBEC94A894C992 2023-05-13 [S] [expires: 2033-05-10] sig 0xCAE438715492B555 2023-05-13 OpenWrt Build System (Nitrokey3) nk3 dongle PIN is going to be available to all build infrastructure admins (needed after server restarts), admin PIN and reset PIN to folks having backup key dongles (ynezz, jow). Another handy feature of such dongles is `Signature counter`, thats a number which keeps track of the signatures performed with the stored signature key. It is only reset if a new signature key is created on or imported to the card. I would like to keep track of this signature counter in Rekor[2] transparency log, along with nk3 dongle serial number and other build artifact details being signed with that key. I'll follow up once that pull request enabling this feature is ready. 1. https://openwrt.org/docs/guide-developer/releases/provision-nitrokey3 2. https://docs.sigstore.dev/rekor/overview/ Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Regression in backport MEMREAD ioctl ? [Was: Re: mt7622: belkin-rt3200: r22602-42eeb22450: Kernel panic: kernel stack overflow]
Michał Kępień [2023-04-24 10:27:48]:
Hi Michał,
> > > Since the panic message includes mentions of a stack overflow, another
> > > idea would be to backport this upstream patch as well:
> > >
> > >
> > > https://lore.kernel.org/linux-mtd/20230417205654.1982368-1-a...@kernel.org/
> > >
> > > This patch has been reviewed, but it has not yet been merged anywhere.
> >
> > Please send a patch to the openwrt mailing list or create a pull request on
> > github.
>
> https://github.com/openwrt/openwrt/pull/12472
thanks a lot for your attempt, but unfortunately it didn't fixed the issue.
I've tried to revert commit fa4dc86 ("kernel: backport MEMREAD ioctl") and
that fixed the issue as Felix already hinted.
Cheers,
Petr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Regression in backport MEMREAD ioctl ? [Was: Re: mt7622: belkin-rt3200: r22602-42eeb22450: Kernel panic: kernel stack overflow]
Felix Fietkau [2023-04-21 12:03:23]: [ adding Michał and Christian to the mail loop] > On 21.04.23 09:11, Petr Štetiar wrote: > > Hi, > > > > I've just noticed, that daily CI runtime testing job on belkin-rt3200 > > failed[1] due to following: > > > > Insufficient stack space to handle exception! > > ESR: 0x9647 -- DABT (current EL) > > FAR: 0xffc008c47fe0 > > Task stack: [0xffc008c48000..0xffc008c4c000] > > IRQ stack: [0xffc008008000..0xffc00800c000] > > Overflow stack: [0xff801feb00a0..0xff801feb10a0] > > CPU: 1 PID: 1 Comm: swapper/0 Tainted: G S5.15.107 #0 > > Hardware name: Linksys E8450 (DT) > > pstate: 80c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > pc : dequeue_entity+0x0/0x250 > > lr : dequeue_task_fair+0x98/0x290 > > sp : ffc008c48030 > > x29: ffc008c48030 x28: 0001 x27: ff801feb6380 > > x26: 0001 x25: ff801feb6300 x24: ff868000 > > x23: 0001 x22: 0009 x21: > > x20: ff801feb6380 x19: ff868080 x18: 17a740a6 > > x17: ffc008bae748 x16: ffc008bae6d8 x15: > > x14: x13: x12: 000f0101 > > x11: 0449 x10: 0127 x9 : > > x8 : 0125 x7 : 00116da1 x6 : 00116da1 > > x5 : 001165a1 x4 : ff801feb6e00 x3 : > > x2 : 0009 x1 : ff868080 x0 : ff801feb6380 > > Kernel panic - not syncing: kernel stack overflow > > SMP: stopping secondary CPUs > > SMP: failed to stop secondary CPUs 0-1 > > Kernel Offset: disabled > > CPU features: 0x3000,0802 > > Memory Limit: none > > > > Last working version was r22580-e11d00d44c[2], and first failing version was > > yesterday 1416b9bbe9, so possibly the regression was introduced in one of > > the > > following commits: > > > > 1416b9bbe9d3 tools/dwarves: update to 1.25 > > 9931188edcbc kernel: fix up qrtr packaging after 5.15.107 bump > > f4989239cc91 kernel: bump 5.15 to 5.15.107 > > 89f6ac5fd1ad tools/cmake: update to 3.26.3 > > ab3f151aa874 mwlwifi: update to version 10.3.9.0-20230311 > > 5ec781c4448b bmips: pci-bcm6348: load IO resource from DT ranges > > 16b0cbbde057 bmips: drop unneeded ath9k fixup > > db4f158c0330 bmips: hg556a: switch to kmod-owl-loader > > 36150ff6ffb2 tools/bzip2: add `bzip2` binaries > > b691362d1dbe Revert "tools/bzip2: add `bzip2` binaries" > > f7f47b136991 mac80211: ath11k: replace 160MHz fix with upstream pending > > one > > 4ab4b9ea818d build: fix incorrect initramfs gzip compression > > 69bc620180d2 build: fix incorrect initramfs bzip2 compression > > 394d7134ec42 tools/bzip2: add `bzip2` binaries > > 5264296ce480 ath79: mikrotik: update kernel on NAND using Yafut > > 27acf2413e91 yafut: add a kernel update tool for MikroTik NAND > > fa4dc86e9808 kernel: backport MEMREAD ioctl > > e722b667c5a5 mac80211: update to v6.1.24 > > Since the crash happens right after snand driver initialization, I think the > most likely candidate is this one: > fa4dc86e9808 kernel: backport MEMREAD ioctl > > Maybe there are still some stack declarations of struct mtd_oob_ops left > that aren't fully initialized. thanks for looking into that Felix, Michał any idea what might be wrong here? Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
mt7622: belkin-rt3200: r22602-42eeb22450: Kernel panic: kernel stack overflow
Hi, I've just noticed, that daily CI runtime testing job on belkin-rt3200 failed[1] due to following: Insufficient stack space to handle exception! ESR: 0x9647 -- DABT (current EL) FAR: 0xffc008c47fe0 Task stack: [0xffc008c48000..0xffc008c4c000] IRQ stack: [0xffc008008000..0xffc00800c000] Overflow stack: [0xff801feb00a0..0xff801feb10a0] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G S5.15.107 #0 Hardware name: Linksys E8450 (DT) pstate: 80c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : dequeue_entity+0x0/0x250 lr : dequeue_task_fair+0x98/0x290 sp : ffc008c48030 x29: ffc008c48030 x28: 0001 x27: ff801feb6380 x26: 0001 x25: ff801feb6300 x24: ff868000 x23: 0001 x22: 0009 x21: x20: ff801feb6380 x19: ff868080 x18: 17a740a6 x17: ffc008bae748 x16: ffc008bae6d8 x15: x14: x13: x12: 000f0101 x11: 0449 x10: 0127 x9 : x8 : 0125 x7 : 00116da1 x6 : 00116da1 x5 : 001165a1 x4 : ff801feb6e00 x3 : x2 : 0009 x1 : ff868080 x0 : ff801feb6380 Kernel panic - not syncing: kernel stack overflow SMP: stopping secondary CPUs SMP: failed to stop secondary CPUs 0-1 Kernel Offset: disabled CPU features: 0x3000,0802 Memory Limit: none Last working version was r22580-e11d00d44c[2], and first failing version was yesterday 1416b9bbe9, so possibly the regression was introduced in one of the following commits: 1416b9bbe9d3 tools/dwarves: update to 1.25 9931188edcbc kernel: fix up qrtr packaging after 5.15.107 bump f4989239cc91 kernel: bump 5.15 to 5.15.107 89f6ac5fd1ad tools/cmake: update to 3.26.3 ab3f151aa874 mwlwifi: update to version 10.3.9.0-20230311 5ec781c4448b bmips: pci-bcm6348: load IO resource from DT ranges 16b0cbbde057 bmips: drop unneeded ath9k fixup db4f158c0330 bmips: hg556a: switch to kmod-owl-loader 36150ff6ffb2 tools/bzip2: add `bzip2` binaries b691362d1dbe Revert "tools/bzip2: add `bzip2` binaries" f7f47b136991 mac80211: ath11k: replace 160MHz fix with upstream pending one 4ab4b9ea818d build: fix incorrect initramfs gzip compression 69bc620180d2 build: fix incorrect initramfs bzip2 compression 394d7134ec42 tools/bzip2: add `bzip2` binaries 5264296ce480 ath79: mikrotik: update kernel on NAND using Yafut 27acf2413e91 yafut: add a kernel update tool for MikroTik NAND fa4dc86e9808 kernel: backport MEMREAD ioctl e722b667c5a5 mac80211: update to v6.1.24 1. https://ynezz.gitlab.io/-/openwrt-device-runtime-testing/-/jobs/4153023579/artifacts/console_belkin-rt3200-initramfs.txt 2. https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/4137718871 Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Additional container registry mirror [Was: Re: Sunsetting the Docker `openwrtorg` org (not `openwrt` org)]
Paul Spooren [2023-04-15 02:02:24]: Hi, > I’d simply disable it instead of no longer updating it, any other opinions? fine with me, thanks for taking care. I would simply announce it in several places, that there is a plan to sunset that namespace in 3-6 months, thus being nice and giving everyone some time to adjust their workflows. BTW I've recently experienced following from Hetzner.de ephemeral VPS in their Helsinki DC with IP address within AS24940: WARNING: Failed to pull image with policy "if-not-present": Error response from daemon: error parsing HTTP 403 response body: invalid character '<' looking for beginning of value: "403 Forbidden\nSince Docker is a US company, we must comply with US export control regulations. In an effort to comply with these, we now block all IP addresses that are located in Cuba, Iran, North Korea, Republic of Crimea, Sudan, and Syria. If you are not in one of these cities, countries, or regions and are blocked, please reach out to https://hub.docker.com/support/contact/\n\n" (manager.go:237:1s) From docker.com support I've got a response, that they're using maxmind.com service for this purpose and that Hetzner.de should fix that, but they don't fully understand the situation and/or don't care. Anyway, I'm seeing more and more such issues recently with Cloudflare/GCP/AWS as well, probably using similar IP flagging service, so perhaps we should consider using some additional container registry as a backup/mirror? So if the pull from one registry doesn't work, then folks could try a different one. I've not done any prior research about all viable options yet, but quay.io looks so far as my favorite option. Any objections/ideas? Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH netifd 1/2] treewide: fix multiple compiler warnings
Fixes bunch of clang-15/gcc-10 compiler warnings, mostly related to
blobmsg_for_each_attr() usage:
error: comparison of integers of different signs: 'int' and 'unsigned long'
[-Werror,-Wsign-compare]
error: comparison of integers of different signs: 'size_t' (aka 'unsigned
long') and 'int' [-Werror,-Wsign-compare]
error: format string is not a string literal [-Werror,-Wformat-nonliteral]
Cc: Hauke Mehrtens
Signed-off-by: Petr Štetiar
---
bonding.c | 2 +-
bridge.c | 5 +++--
config.c | 2 +-
extdev.c | 7 ---
interface-ip.c | 4 ++--
interface.c| 5 +++--
main.c | 1 +
proto-shell.c | 10 +-
proto.c| 6 +++---
system-linux.c | 2 +-
ubus.c | 2 +-
vlandev.c | 3 ++-
wireless.c | 6 +++---
13 files changed, 30 insertions(+), 25 deletions(-)
diff --git a/bonding.c b/bonding.c
index f4005de059b4..402c71cb7a89 100644
--- a/bonding.c
+++ b/bonding.c
@@ -353,7 +353,7 @@ bonding_config_init(struct device *dev)
{
struct bonding_device *bdev;
struct blob_attr *cur;
- int rem;
+ size_t rem;
bdev = container_of(dev, struct bonding_device, dev);
diff --git a/bridge.c b/bridge.c
index f6e3f4b95bdc..cc833298b134 100644
--- a/bridge.c
+++ b/bridge.c
@@ -782,7 +782,7 @@ bridge_hotplug_set_member_vlans(struct bridge_state *bst,
struct blob_attr *vlan
{
struct bridge_vlan *vlan;
struct blob_attr *cur;
- int rem;
+ size_t rem;
if (!vlans)
return;
@@ -1030,7 +1030,8 @@ bridge_config_init(struct device *dev)
struct bridge_state *bst;
struct bridge_vlan *vlan;
struct blob_attr *cur;
- int i, rem;
+ size_t rem;
+ int i;
bst = container_of(dev, struct bridge_state, dev);
diff --git a/config.c b/config.c
index 9bbda39d3fb5..e1c01e12994b 100644
--- a/config.c
+++ b/config.c
@@ -337,7 +337,7 @@ config_parse_vlan(struct device *dev, struct uci_section *s)
char *name_buf;
int name_len = 0;
int n_ports = 0;
- int rem;
+ size_t rem;
val = uci_lookup_option_string(uci_ctx, s, "vlan");
if (!val)
diff --git a/extdev.c b/extdev.c
index 5c5e76901d81..8d06228170e1 100644
--- a/extdev.c
+++ b/extdev.c
@@ -754,7 +754,7 @@ static void
__buf_add_all(struct blob_attr *attr)
{
struct blob_attr *cur;
- int rem;
+ size_t rem;
blobmsg_for_each_attr(cur, attr, rem)
blobmsg_add_field(&b, blobmsg_type(cur), blobmsg_name(cur),
blobmsg_data(cur),
@@ -1055,7 +1055,8 @@ error:
static void
__bridge_config_init(struct extdev_bridge *ebr)
{
- int rem, ret;
+ int ret;
+ size_t rem;
struct blob_attr *cur;
if (ebr->empty) {
@@ -1100,7 +1101,7 @@ extdev_config_init(struct device *dev)
}
static void
-extdev_buf_add_list(struct blob_attr *attr, int len, const char *name,
+extdev_buf_add_list(struct blob_attr *attr, size_t len, const char *name,
struct blob_buf *buf, bool array)
{
struct blob_attr *cur;
diff --git a/interface-ip.c b/interface-ip.c
index 7359db2696bc..a06a514b6dde 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -1429,7 +1429,7 @@ void
interface_add_dns_server_list(struct interface_ip_settings *ip, struct
blob_attr *list)
{
struct blob_attr *cur;
- int rem;
+ size_t rem;
blobmsg_for_each_attr(cur, list, rem) {
if (blobmsg_type(cur) != BLOBMSG_TYPE_STRING)
@@ -1461,7 +1461,7 @@ void
interface_add_dns_search_list(struct interface_ip_settings *ip, struct
blob_attr *list)
{
struct blob_attr *cur;
- int rem;
+ size_t rem;
blobmsg_for_each_attr(cur, list, rem) {
if (blobmsg_type(cur) != BLOBMSG_TYPE_STRING)
diff --git a/interface.c b/interface.c
index 89654f952c15..66e0e80d72ba 100644
--- a/interface.c
+++ b/interface.c
@@ -232,7 +232,8 @@ interface_add_data(struct interface *iface, const struct
blob_attr *data)
int interface_parse_data(struct interface *iface, const struct blob_attr *attr)
{
struct blob_attr *cur;
- int rem, ret;
+ size_t rem;
+ int ret;
iface->updated = 0;
@@ -517,7 +518,7 @@ static void
interface_add_assignment_classes(struct interface *iface, struct blob_attr
*list)
{
struct blob_attr *cur;
- int rem;
+ size_t rem;
blobmsg_for_each_attr(cur, list, rem) {
if (blobmsg_type(cur) != BLOBMSG_TYPE_STRING)
diff --git a/main.c b/main.c
index e5260b5eafa9..ec7b1be03633 100644
--- a/main.c
+++ b/main.c
@@ -64,6 +64,7 @@ netifd_delete_process(struct netifd_process *proc)
}
void
+__attribute__((format(printf, 2, 0)))
netifd_log_message(int priority, const char *format, ...)
{
va_list vl;
diff --git a/proto-shell.c b/proto-shell.c
index 9cdbc7fde362..bc3c41
[PATCH netifd 2/2] cmake: fix build by reordering the cflags definitions
I've noticed bunch of build errors being emitted by clang-15/gcc-10:
netifd.h:83:33: error: unused parameter 'level' [-Werror,-Wunused-parameter]
and it seems, that the order of definitions matters as -Wextra probably
enables previously disabled warnings like -Wno-unused-parameter.
So lets fix it, by reordering the cflags definitions.
Cc: Hauke Mehrtens
Fixes: 463a1207f076 ("netifd: Activate -Wextra compile warnings")
Signed-off-by: Petr Štetiar
---
CMakeLists.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index b87c300fcc22..5ad86954707b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -7,11 +7,12 @@ IF(NOT ${CMAKE_VERSION} LESS 3.0)
check_c_compiler_flag(-Wimplicit-fallthrough HAS_IMPLICIT_FALLTHROUGH)
ENDIF()
-ADD_DEFINITIONS(-Os -Wall -Werror --std=gnu99 -Wmissing-declarations
-Wno-unused-parameter -Wno-unused-but-set-parameter)
+ADD_DEFINITIONS(-Wall -Werror)
IF(CMAKE_C_COMPILER_VERSION VERSION_GREATER 6)
add_definitions(-Wextra -Werror=implicit-function-declaration)
add_definitions(-Wformat -Werror=format-security
-Werror=format-nonliteral)
ENDIF()
+ADD_DEFINITIONS(-Os --std=gnu99 -Wmissing-declarations -Wno-unused-parameter
-Wno-unused-but-set-parameter)
IF(HAS_IMPLICIT_FALLTHROUGH)
ADD_DEFINITIONS(-Wimplicit-fallthrough)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 22.03] toolchain: gcc: backport v11.3.0 fix for false positive VLA params warnings
From: Andrey Erokhin
If the vla parameter has a const specifier, the compiler will warn about
mismatched bounds:
$ cat mwe.c
extern void mwe(const int len, char buf[len]);
void mwe(const int len, char buf[len]) {}
$ make CFLAGS=-Wvla-parameter mwe.o
cc -Wvla-parameter -c -o mwe.o mwe.c
mwe.c:2:30: warning: argument 2 of type ‘char[len]’ declared with mismatched
bound ‘len’ [-Wvla-parameter]
2 | void mwe(const int len, char buf[len]) {}
| ~^~~~
mwe.c:1:37: note: previously declared as ‘char[len]’ with bound ‘len’
1 | extern void mwe(const int len, char buf[len]);
|~^~~~
On some code bases it might result in a lot of false positive warnings,
which can indeed be easily disabled, but on the other this workaround
might hide some real issues, so lets rather fix the compiler and make it
more reliable.
References: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101289
Signed-off-by: Andrey Erokhin
Signed-off-by: Petr Štetiar [commit message]
---
.../400-v11.3.0-bogus-Wvla-parameter.patch| 192 ++
1 file changed, 192 insertions(+)
create mode 100644
toolchain/gcc/patches/11.2.0/400-v11.3.0-bogus-Wvla-parameter.patch
diff --git
a/toolchain/gcc/patches/11.2.0/400-v11.3.0-bogus-Wvla-parameter.patch
b/toolchain/gcc/patches/11.2.0/400-v11.3.0-bogus-Wvla-parameter.patch
new file mode 100644
index ..443839f81b0e
--- /dev/null
+++ b/toolchain/gcc/patches/11.2.0/400-v11.3.0-bogus-Wvla-parameter.patch
@@ -0,0 +1,192 @@
+From 7d3f53c595e1766ca0494e5f56f33b0ce49b3bb4 Mon Sep 17 00:00:00 2001
+From: Martin Sebor
+Date: Thu, 15 Jul 2021 10:11:23 -0600
+Subject: [PATCH] Avoid -Wvla-parameter for nontrivial bounds [PR97548].
+
+Resolves:
+PR c/101289 - bogus -Wvla-paramater warning when using const for vla param
+PR c/97548 - bogus -Wvla-parameter on a bound expression involving a parameter
+
+gcc/c-family/ChangeLog:
+
+ PR c/101289
+ PR c/97548
+ * c-warn.c (warn_parm_array_mismatch): Use OEP_DECL_NAME.
+
+gcc/c/ChangeLog:
+
+ PR c/101289
+ PR c/97548
+ * c-decl.c (get_parm_array_spec): Strip nops.
+
+gcc/ChangeLog:
+
+ PR c/101289
+ PR c/97548
+ * fold-const.c (operand_compare::operand_equal_p): Handle OEP_DECL_NAME.
+ (operand_compare::verify_hash_value): Same.
+ * tree-core.h (OEP_DECL_NAME): New.
+
+gcc/testsuite/ChangeLog:
+
+ * gcc.dg/Wvla-parameter-12.c: New test.
+---
+ gcc/c-family/c-warn.c| 3 +-
+ gcc/c/c-decl.c | 1 +
+ gcc/fold-const.c | 33 --
+ gcc/testsuite/gcc.dg/Wvla-parameter-12.c | 36
+ gcc/tree-core.h | 7 -
+ 5 files changed, 69 insertions(+), 11 deletions(-)
+ create mode 100644 gcc/testsuite/gcc.dg/Wvla-parameter-12.c
+
+diff --git a/gcc/c-family/c-warn.c b/gcc/c-family/c-warn.c
+index 7414063aa11..250da89a829 100644
+--- a/gcc/c-family/c-warn.c
b/gcc/c-family/c-warn.c
+@@ -3646,7 +3646,8 @@ warn_parm_array_mismatch (location_t origloc, tree
fndecl, tree newparms)
+ /* The VLA bounds don't refer to other function parameters.
+Compare them lexicographically to detect gross mismatches
+such as between T[foo()] and T[bar()]. */
+-if (operand_equal_p (newbnd, curbnd, OEP_LEXICOGRAPHIC))
++if (operand_equal_p (newbnd, curbnd,
++ OEP_DECL_NAME | OEP_LEXICOGRAPHIC))
+ continue;
+
+ if (warning_at (newloc, OPT_Wvla_parameter,
+diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
+index 53b2b5b637d..ddef9c68fb7 100644
+--- a/gcc/c/c-decl.c
b/gcc/c/c-decl.c
+@@ -5862,6 +5862,7 @@ get_parm_array_spec (const struct c_parm *parm, tree
attrs)
+
+ /* Each variable VLA bound is represented by a dollar sign. */
+ spec += "$";
++ STRIP_NOPS (nelts);
+ vbchain = tree_cons (NULL_TREE, nelts, vbchain);
+ }
+
+diff --git a/gcc/fold-const.c b/gcc/fold-const.c
+index a1d08c74025..f5c19a0cfd4 100644
+--- a/gcc/fold-const.c
b/gcc/fold-const.c
+@@ -3506,11 +3506,26 @@ operand_compare::operand_equal_p (const_tree arg0,
const_tree arg1,
+
+ case tcc_declaration:
+ /* Consider __builtin_sqrt equal to sqrt. */
+- return (TREE_CODE (arg0) == FUNCTION_DECL
+-&& fndecl_built_in_p (arg0) && fndecl_built_in_p (arg1)
+-&& DECL_BUILT_IN_CLASS (arg0) == DECL_BUILT_IN_CLASS (arg1)
+-&& (DECL_UNCHECKED_FUNCTION_CODE (arg0)
+-== DECL_UNCHECKED_FUNCTION_CODE (arg1)));
++ if (TREE_CODE (arg0) == FUNCTION_DECL)
++ return (fndecl_built_in_p (arg0) && fndecl_built_in_p (arg1)
++ && DECL_BUILT_IN_CLASS (arg0) == DECL_BUILT_IN_CLAS
Re: Docker is sunsetting Free Team organizations
Etienne Champetier [2023-03-16 23:19:11]: Hi, > Those 3 repos seem active, do we mirror the content somewhere else ? we don't mirror it elsewhere. > (gitlab/github) > docker.io/openwrtorg/imagebuilder > docker.io/openwrtorg/sdk > docker.io/openwrtorg/rootfs BTW those `openwrtorg` ones are actually the "old" repositories, Paul managed to get openwrt namespace back https://hub.docker.com/u/openwrt > Do we want to apply for "Docker-Sponsored Open Source Program" > https://www.docker.com/community/open-source/application/ They've served us very well for ages, so I'm fine with that, no objections. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH uci 1/2] fuzz: Compile using libstd++
Hauke Mehrtens [2023-03-12 22:52:50]: Hi, > What libfuzzer did you use in your container in gitlab? I was using clang builds from apt.llvm.org[1]. > An automatic detection would be nice, but I have no idea how to do it. I found only https://gitlab.kitware.com/cmake/cmake/-/issues/18275 which has some ideas and further pointers, but unfortunately no copy&paste-able solution. Anyway, I wouldn't waste more time on this, simply push the patch as proposed and move on, we're all going to use that same tool container in the end, so it should always provide some common working starting point. 1. https://gitlab.com/ynezz/openwrt-ci/-/blob/master/docker/Dockerfile#L9 Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Reusable Github Actions and containers [Was: Re: [PATCH uci 2/2] CI: Add github action]
Hauke Mehrtens [2023-03-09 00:18:10]: Hi, thanks for taking care, LGTM for a start. I'll just provide my past experience, something to consider as we're likely going to bump into those in the long term, so ideally take them into the account in the long term. > clang 14 generates debug information in DWARF 5 format, but valgrind > 19.0 does not support that. Install valgrind 20.0 from experimental > which supports it. IMO we should aim for reproducible results, thus we should likely provide tools containers with a known versions inside, so anyone is able to get same results using the source code Git hash and tool container version. Your current approach is highly dynamic, so if you're lucky enough, you might get a green CI light in the PR branch as the pipeline was run for example 7 days ago, so you're going to merge it into the upstream branch, but then it's going to fail as meanwhile Debian has bumped several packages and you're going to get a CI pipeline failure. IMO there should be a tools container Git repository, where we could build, test and provide versioned containers, for example: ghcr.io/openwrt/ci-tools/native-testing/clang14:20230305 ghcr.io/openwrt/ci-tools/native-testing/clang15:20230305 ghcr.io/openwrt/ci-tools/native-testing/gcc-8:20230305 ghcr.io/openwrt/ci-tools/native-testing/gcc-11:20230305 ghcr.io/openwrt/ci-tools/native-testing/gcc-12:20230305 We want to test with with multiple compiler versions as those tested changes might be backported into stable branches, we should even consider to have stable branches in every project so we could CI test them there as well, folks would simply create a backport PR in the respective project. > +++ b/.github/workflows/test.yml > @@ -0,0 +1,83 @@ > +name: 'Run tests' We've like 30+ C projects which we should likely cover in the end, thus considering possible additional 2 stable branches in each, it's around 60+ of similar workflow files duplicated in various repositories. I would consider this future maintenance overhead (imagine just a simple change or a fix being propagated into 60+ repositories/branches), so I would recommend to create a shareable Github Action instead: uses: openwrt/gh-actions-ci-native env: CI_NATIVE_TOOLCHAIN: clang14 uses: openwrt/gh-actions-ci-sdk env: CI_TARGET_SDK_RELEASE: master CI_TARGET_SDK: ath79-generic CI_TARGET_BUILD_DEPENDS: uci You can take a look at the ucode project for a very dated, but still working GitHub example, some bits are even present in uci repsitory in the .gitlab-ci.yml file. > + - name: Checkout libubox > +uses: actions/checkout@v3 > +with: > + repository: openwrt/libubox > + path: libubox This looks like another source of unreliability, similar to the toolchain versions above. For the start, I would simply include all those dependencies in the native toolchain container, thus we would need to have separate containers for each branch: ghcr.io/openwrt/ci-tools/native-testing/clang14_snapshot:20230305 ghcr.io/openwrt/ci-tools/native-testing/clang14_openwrt-22.03:20230305 ghcr.io/openwrt/ci-tools/native-testing/clang14_openwrt-21.02:20230305 ghcr.io/openwrt/ci-tools/native-testing/distro_snapshot:20230305 (distro default gcc12) ghcr.io/openwrt/ci-tools/native-testing/distro_21.02:20230305 (gcc8) ghcr.io/openwrt/ci-tools/native-testing/distro_22.03:20230305 (gcc11) So in the end, ideally, interested developer can have the same CI failure/result locally and debug/fix it faster: $ git clone https://github.com/openwrt/uci && cd uci $ wget -q https://github.com/openwrt/some-project/raw/master/Makefile -O Makefile.ci $ make ci-prepare -f Makefile.ci $ podman run --rm --tty --interactive --volume $(pwd):/home/build/openwrt \ ghcr.io/openwrt/ci-tools/native-testing/clang14_snapshot:20230305 \ make ci-native-build -f Makefile.ci Have a nice weekend. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH uci 1/2] fuzz: Compile using libstd++
Hauke Mehrtens [2023-03-09 00:18:09]: Hi, > It looks like libfuzzer is compiled using libstd++ on Debian Bookworm > and not libc++. Using libc++ causes linking errors, use libstd++ > instead. so maybe this should be detected and decided at runtime? Otherwise this seems to just support Bookworm from now and thus fail to compile elsewhere? Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH netifd 2/2] bridge: bridge_dump_info: add dumping of bridge attributes
There are internal decisions being made using several bridge attributes
like for example in bridge_reload(), but those attributes are not
available for the outside inspection, thus hard to follow.
So lets make inspection easier and simply just add dumping of those
bridge attributes as well.
Signed-off-by: Petr Štetiar
---
bridge.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/bridge.c b/bridge.c
index 9ed7c985afef..c7ba6a785378 100644
--- a/bridge.c
+++ b/bridge.c
@@ -968,12 +968,15 @@ bridge_dump_vlan(struct blob_buf *b, struct bridge_vlan
*vlan)
static void
bridge_dump_info(struct device *dev, struct blob_buf *b)
{
+ struct bridge_config *cfg;
struct bridge_state *bst;
struct bridge_member *bm;
struct bridge_vlan *vlan;
void *list;
+ void *c;
bst = container_of(dev, struct bridge_state, dev);
+ cfg = &bst->config;
system_if_dump_info(dev, b);
list = blobmsg_open_array(b, "bridge-members");
@@ -987,6 +990,29 @@ bridge_dump_info(struct device *dev, struct blob_buf *b)
blobmsg_close_array(b, list);
+ c = blobmsg_open_table(b, "bridge-attributes");
+
+ blobmsg_add_u8(b, "stp", cfg->stp);
+ blobmsg_add_u32(b, "forward_delay", cfg->forward_delay);
+ blobmsg_add_u32(b, "priority", cfg->priority);
+ blobmsg_add_u32(b, "ageing_time", cfg->ageing_time);
+ blobmsg_add_u32(b, "hello_time", cfg->hello_time);
+ blobmsg_add_u32(b, "max_age", cfg->max_age);
+ blobmsg_add_u8(b, "igmp_snooping", cfg->igmp_snoop);
+ blobmsg_add_u8(b, "bridge_empty", cfg->bridge_empty);
+ blobmsg_add_u8(b, "multicast_querier", cfg->multicast_querier);
+ blobmsg_add_u32(b, "hash_max", cfg->hash_max);
+ blobmsg_add_u32(b, "robustness", cfg->robustness);
+ blobmsg_add_u32(b, "query_interval", cfg->query_interval);
+ blobmsg_add_u32(b, "query_response_interval",
cfg->query_response_interval);
+ blobmsg_add_u32(b, "last_member_interval", cfg->last_member_interval);
+ blobmsg_add_u8(b, "vlan_filtering", cfg->vlan_filtering);
+ blobmsg_add_u8(b, "stp_kernel", cfg->stp_kernel);
+ if (cfg->stp_proto)
+ blobmsg_add_string(b, "stp_proto", cfg->stp_proto);
+
+ blobmsg_close_table(b, c);
+
if (avl_is_empty(&dev->vlans.avl))
return;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH netifd 1/2] bridge: make it more clear why the config was applied
In some cases we see, that the bridge configuration was applied, but its
not exactly clear why it was done, so lets add a simple debugging output
which should provide currently missing clue.
Signed-off-by: Petr Štetiar
---
bridge.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/bridge.c b/bridge.c
index 7e61b9df8326..9ed7c985afef 100644
--- a/bridge.c
+++ b/bridge.c
@@ -1152,16 +1152,22 @@ bridge_reload(struct device *dev, struct blob_attr
*attr)
diff = 0;
uci_blob_diff(tb_dev, otb_dev, &device_attr_list, &diff);
- if (diff)
- ret = DEV_CONFIG_RESTART;
+ if (diff) {
+ ret = DEV_CONFIG_RESTART;
+ D(DEVICE, "Bridge %s device attributes has changed,
diff=0x%lx\n",
+ dev->ifname, diff);
+ }
blobmsg_parse(bridge_attrs, __BRIDGE_ATTR_MAX, otb_br,
blob_data(bst->config_data),
blob_len(bst->config_data));
diff = 0;
uci_blob_diff(tb_br, otb_br, &bridge_attr_list, &diff);
- if (diff & ~(1 << BRIDGE_ATTR_PORTS))
- ret = DEV_CONFIG_RESTART;
+ if (diff & ~(1 << BRIDGE_ATTR_PORTS)) {
+ ret = DEV_CONFIG_RESTART;
+ D(DEVICE, "Bridge %s attributes has changed,
diff=0x%lx\n",
+ dev->ifname, diff);
+ }
bridge_config_init(dev);
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH netifd 0/2] improve bridge configuration inspection
Hi, while debugging some bridge configuration issue I wasnt able to get a complete picture of the bridge configuration handling inside netifd out of the box, so I would like to propose following two relatively small changes which helped me better understand netifd internals by using just a debugging output and ubus. First patch is going to output bitset of changed device/bridge settings in debugging output, so one can find out why the bridge was reloaded. Second patch adds currently missing bridge attributes into the ubus bridge device status dump. Cheers, Petr Cc: Felix Fietkau Petr Štetiar (2): bridge: make it more clear why the config was applied bridge: bridge_dump_info: add dumping of bridge attributes bridge.c | 40 1 file changed, 36 insertions(+), 4 deletions(-) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] imx: add imx8 support
Tim Harvey [2023-03-09 12:19:24]: Hi, > Is there any reason to move them into target/linux/generic/backport-5.15? sorry for confusing you, but I've just meant to rename the patch files itself, so they contain bacported kernel version in their filename, making the patch origin explicit as it makes maintenance of the patches much easier. There is no need to move it into generic kernel folder and complicate stuff there. > I'm assuming you mean just add details above on how I'm booting in the > commit message? Yes, just imagine someone buying your board, without much prior knowledge and would use the commit message as the only source for booting that board with OpenWrt. BTW for the folks handling the wiki, the commit message is usually the only source of information. > The reason right now that I'm avoiding boot firmware is: > 1. There was pushback regarding the firmware-imx-8.15.bin license > required to build boot firmware (see > http://lists.openwrt.org/pipermail/openwrt-devel/2022-August/039247.html) Well, IMO its crystal clear, that NXP needs to fix this, we can't do much about it, unless you plan to host it on your servers :-) Anyway, it's clear, that there is some interest in this SoC and it would be helpful to have some common base for development, even in the source-only form. Thus I would simply like to merge partial support for this SoC once 23.y is branched, unless of course NACKed. Its really against FOSS spirit, we shouldn't promote such SoCs even in the source-only form, but I sincerely hope, that NXP is going to understand the situation and fix it before next OpenWrt release. If it turns out, that I was very naive, we should probably cast a vote and either keep it in source-only form or remove it. > This is due FEATURES having ubifs causing USES_UBIFS and > TARGET_ROOTFS_UBIFS getting set but because IMO this is likely due to a fact, that you've not defined any device in your image file, so you don't define `FILESYSTEMS` variable and thus the build system uses default `TARGET_FILESYSTEMS` which has `ubifs` defined. So I would probably try to just define a support for a single device with empty FILESYSTEMS variable and see how that works. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] imx: add imx8 support
Tim Harvey [2023-03-08 16:20:31]: Hi Tim, > Add imx8 support: > - add a cortexa53 subtarget > - move ARCH, KERNELNAME, and some FEATURES to cortexa7/cortexa9 subtargets > - add a small series of backports from 6.2 to fix hang on USB init and >add PCIe support mark those patches clearly as such v6.2 backports, for example: 0001-v6.2-soc-imx-gpcv2-allow-to-disable-individual-power-doma.patch > No device-specific targets or firmware images are created yet. Fine with me, but for the time being we should probably mark this subtarget as source-only, so we don't waste time on the buildbots as there is not much usable result yet. > The resulting openwrt-imx-cortexa53-vmlinux-initramfs has been booted on > Gateworks Venice boards and the imx8mm-evk using dtb's from $LINUX_DIR > and verifying usb, pci, mmc, and fec networking work. Nice, so it boots just fine without any additional post processing/blobs needed? As you're not adding bootloader, can add some information about the working combination in the commit message as well? Simply anything which would help anyone reproducing the result is welcome. > -FEATURES:=audio display fpu gpio pcie rtc usb usbgadget squashfs targz nand > ubifs boot-part rootfs-part > +FEATURES:=audio display fpu gpio pcie rtc usb usbgadget squashfs targz > boot-part rootfs-part Is there any specific reason to not have NAND feature available for a53 subtarget? `imx8 NAND` yields bunch of search results, so I'm wondering why are you bothering with removing this feature, seems like we would likely add it back in the near future anyway. > diff --git a/target/linux/imx/cortexa53/target.mk > b/target/linux/imx/cortexa53/target.mk > new file mode 100644 > index ..b9b32d182905 > --- /dev/null > +++ b/target/linux/imx/cortexa53/target.mk > @@ -0,0 +1,8 @@ > +ARCH:=aarch64 > +BOARDNAME:=NXP i.MX with Cortex-A53 (ARM64) > +CPU_TYPE:=cortex-a53 > +KERNELNAME:=Image dtbs FEATURES+=source-only Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH netifd] bridge: make it more clear why the config was applied
In some cases we see, that the bridge configuration was applied, but its
not exactly clear why it was done, so lets add a simple debugging output
which should provide currently missing clue.
Signed-off-by: Petr Štetiar
---
bridge.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/bridge.c b/bridge.c
index 7e61b9df8326..9ed7c985afef 100644
--- a/bridge.c
+++ b/bridge.c
@@ -1152,16 +1152,22 @@ bridge_reload(struct device *dev, struct blob_attr
*attr)
diff = 0;
uci_blob_diff(tb_dev, otb_dev, &device_attr_list, &diff);
- if (diff)
- ret = DEV_CONFIG_RESTART;
+ if (diff) {
+ ret = DEV_CONFIG_RESTART;
+ D(DEVICE, "Bridge %s device attributes has changed,
diff=0x%lx\n",
+ dev->ifname, diff);
+ }
blobmsg_parse(bridge_attrs, __BRIDGE_ATTR_MAX, otb_br,
blob_data(bst->config_data),
blob_len(bst->config_data));
diff = 0;
uci_blob_diff(tb_br, otb_br, &bridge_attr_list, &diff);
- if (diff & ~(1 << BRIDGE_ATTR_PORTS))
- ret = DEV_CONFIG_RESTART;
+ if (diff & ~(1 << BRIDGE_ATTR_PORTS)) {
+ ret = DEV_CONFIG_RESTART;
+ D(DEVICE, "Bridge %s attributes has changed,
diff=0x%lx\n",
+ dev->ifname, diff);
+ }
bridge_config_init(dev);
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Intention on moving board-2 blob to a separate repo
Ansuel Smith [2023-02-27 23:35:47]: Hi, > there is this idea of moving each board-2 blob to a separate repo the idea seems fine to me, I just don't understand this part, can you elaborate more on why do we need separate repositaory for each board? It seems to me, that a single repository should be good enough, is there anything I'm missing? Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Buildbot worker balancing between master and 22.03 ?
Hannu Nyman [2023-02-04 17:23:23]: Hi, > To my knowledge, no release builds are currently being compiled, so could a > few workers be re-assigned from 22.03 to master in order to shorten the > build frequency there, both regarding images and packages. should be better now. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: snapshots mvebu/cortexa9 possible regression in initramfs boot after acd8e94d20
Stijn Segers [2023-02-06 11:38:40]: Hi, > "Petr Štetiar" schreef op 6 februari 2023 11:26:35 CET: > >Hi, > > > >I've just noticed, that Omnia fails to boot latest initramfs snapshots[1]: > > > > ## Loading kernel from FIT Image at 0100 ... > > Using 'config-1' configuration > > Trying 'kernel-1' kernel subimage > > Description: ARM OpenWrt Linux-5.15.91 > > ...snip... > > Verifying Hash Integrity ... crc32+ sha1+ OK > > ## Loading fdt from FIT Image at 0100 ... > > Using 'config-1' configuration > > Trying 'fdt-1' fdt subimage > > Description: ARM OpenWrt cznic_turris-omnia device tree blob > > ...snip... > > Verifying Hash Integrity ... crc32+ sha1+ OK > > Booting using the fdt blob at 0x1543900 > > Uncompressing Kernel Image > > Loading Device Tree to 0fff8000, end 0dbe ... OK > > > > Starting kernel ... > > > >acd8e94d20 seems to be the last working revision[2], so 5.15.90 booted fine, > >5.15.91 didn't, so maybe thats the culprit? > > > FWIW, a backported 5.15.91 boots fine here on a WRT1200AC with 22.03. FYI I've reported issue with initramfs image as we don't flash devices during daily automatic runtime testing. Anyway it seems, that Georgi is observing similar symptomps on his device[1], so likely 8bc72ea7be3976 might be the real culprit here. 1. https://github.com/openwrt/openwrt/commit/8bc72ea7be3976711dacc09f0fdab061d6e5152a#commitcomment-99705611 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
snapshots mvebu/cortexa9 possible regression in initramfs boot after acd8e94d20
Hi, I've just noticed, that Omnia fails to boot latest initramfs snapshots[1]: ## Loading kernel from FIT Image at 0100 ... Using 'config-1' configuration Trying 'kernel-1' kernel subimage Description: ARM OpenWrt Linux-5.15.91 ...snip... Verifying Hash Integrity ... crc32+ sha1+ OK ## Loading fdt from FIT Image at 0100 ... Using 'config-1' configuration Trying 'fdt-1' fdt subimage Description: ARM OpenWrt cznic_turris-omnia device tree blob ...snip... Verifying Hash Integrity ... crc32+ sha1+ OK Booting using the fdt blob at 0x1543900 Uncompressing Kernel Image Loading Device Tree to 0fff8000, end 0dbe ... OK Starting kernel ... acd8e94d20 seems to be the last working revision[2], so 5.15.90 booted fine, 5.15.91 didn't, so maybe thats the culprit? 1. https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/3718348826/artifacts/external_file/console_turris-omnia-initramfs.txt 2. https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/3714932743#L66 Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Buildbot needs configuration? powerpc_8540 is now powerpc_8548 ?
Hannu Nyman [2023-01-15 16:13:51]: Hi, > Apparently the mpc85xx CPU type was changed from 8540 to 8548 on 29 Dec > 2022, causing the package architecture to be powerpc_8548 instead of > powerpc_8540, but noboby informed the packages buildbot, so it is still > trying to churn powerpc_8540 and naturally fails :-( > > PR: https://github.com/openwrt/openwrt/pull/11629 > commit: > https://github.com/openwrt/openwrt/commit/2cad88b99fdae9766de84e6c1cb56f111eb53748 > > Buildbot status for powerpc_8540: > https://buildbot.openwrt.org/master/packages/#/builders/14 > > Forum discussion: > https://forum.openwrt.org/t/opkg-update-fails-with-wget-error-8-repository-folder-missing-powerpc-8548/148425 thanks for the report, it looks like that commit should be reverted soon and thus fix this issue. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
Brian Norris [2023-01-09 11:51:53]:
> For my use, it feels like a simplified form (which only needs to be a
> stdin/stdout pipeline) would be pretty easy to inline into the
> caldata/firmware-loader script:
>
> ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));'
from my past experience, such oneliners usually endup in a hard to maintain
copy&pasta mess between targets/scripts, thus my initial idea was to simply
ship it for the start as target/linux/ipq806x/base-files/usr/bin/b64decode.uc,
thus allowing following usage:
- base64 -d "$source" > "$target_dir/data"
+ b64decode.uc "$source" > "$target_dir/data"
Once such decoding is needed in other parts/targets, we would simply just move
the script into target/linux/generic/base-files/usr/bin/b64decode.uc and call
it a day.
Cheers,
Petr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
Petr Štetiar [2023-01-09 11:50:37]:
Hi,
> BTW ucode has `b64dec()`[1] so perhaps another viable option.
>
> 1. https://github.com/jow-/ucode#663-b64decstr
wanted to refresh my ucode brain cells, so I've explored feasibility of that
suggestion and it seems to work just fine:
#!/usr/bin/ucode
import { stdin, open, error } from 'fs';
if (length(ARGV) == 0 && stdin.isatty()) {
warn("usage: b64decode [stdin|path]\n");
exit(1);
}
let fp = stdin;
let source = ARGV[0];
if (source) {
fp = open(source);
if (!fp) {
warn(`b64decode: unable to open ${source}:
${error()}\n`);
exit(1);
}
}
print(b64dec(fp.read("all")));
fp.close();
exit(0);
BTW it needs recent ucode with fs.stdin.isatty() support[1].
Thanks Jo for helping me making above script more idiomatic. IMO it looks more
human readable, portable and maintanable then that awk based solution.
1. https://github.com/jow-/ucode/commit/be30472bfdbbb410e8934b48a56d26c5c630d0f1
Cheers,
Petr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
Thibaut [2023-01-08 00:02:06]: > There might be an even easier/lighter way (short of enabling base64 in > busybox), AWK to the rescue: > https://github.com/shane-kerr/AWK-base64decode > > The code is clean and judging by the comment line 97, works with busybox awk. BTW ucode has `b64dec()`[1] so perhaps another viable option. 1. https://github.com/jow-/ucode#663-b64decstr Thibaut [2023-01-08 22:37:20]: > I wonder if it’s such a good idea to have discrepancies in busybox features > between targets? You're right, it's not a good idea. Brian Norris [2023-01-08 19:09:33]: > Thanks! That does indeed work for me. And I might just throw it into > target/linux/ipq806x/chromium/target.mk instead, since the generic > target won't be using base64. It works for me as well, but it's going to break some cases I've missed. Sorry for the noise. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
Brian Norris [2023-01-06 23:49:44]: Hi Brian, > I need to express a per-target dependency on the 'base64' utility, and > that's seemingly impossible to do for busybox. --- a/target/linux/ipq806x/Makefile +++ b/target/linux/ipq806x/Makefile @@ -15,6 +15,11 @@ KERNEL_PATCHVER:=5.15 KERNELNAME:=zImage Image dtbs include $(INCLUDE_DIR)/target.mk + +DEPENDS:= \ + +@BUSYBOX_DEFAULT_BASE64 + Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] at91: fix racy SD card image generation
We've few low spec (make -j3) build workers attached to the 22.03 buildbot instance which from time to time exhibit following build failure during image generation (shortened for brevity): + dd bs=512 if=root.ext4 of=openwrt-22.03...sdcard.img.gz.img dd: failed to open 'root.ext4': No such file or directory Thats happening likely due to the fact, that on buildbots we've `TARGET_PER_DEVICE_ROOTFS=y` which produces differently named filesystem image in the SD card image target dependency chain: make_ext4fs -L rootfs ... root.ext4+pkg=68b329da and that hardcoded `root.ext4` image filename becomes available from other Make targets in the later stages. So lets fix this issue by using IMAGE_ROOTFS Make variable which should contain proper path to the root filesystem image. Cc: Claudiu Beznea Signed-off-by: Petr Štetiar --- This should be then backported to 22.03 as thats where those buildbot issues happens currently. target/linux/at91/image/sam9x.mk | 2 +- target/linux/at91/image/sama5.mk | 2 +- target/linux/at91/image/sama7.mk | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/target/linux/at91/image/sam9x.mk b/target/linux/at91/image/sam9x.mk index 4de96097758d..409e43ca6e90 100644 --- a/target/linux/at91/image/sam9x.mk +++ b/target/linux/at91/image/sam9x.mk @@ -35,7 +35,7 @@ define Build/at91-sdcard ./gen_at91_sdcard_img.sh \ $@.img \ $@.boot \ - $(KDIR)/root.ext4 \ + $(IMAGE_ROOTFS) \ $(AT91_SD_BOOT_PARTSIZE) \ $(CONFIG_TARGET_ROOTFS_PARTSIZE) diff --git a/target/linux/at91/image/sama5.mk b/target/linux/at91/image/sama5.mk index 39db3e1cd022..7f4dd3316a88 100644 --- a/target/linux/at91/image/sama5.mk +++ b/target/linux/at91/image/sama5.mk @@ -39,7 +39,7 @@ define Build/at91-sdcard ./gen_at91_sdcard_img.sh \ $@.img \ $@.boot \ - $(KDIR)/root.ext4 \ + $(IMAGE_ROOTFS) \ $(AT91_SD_BOOT_PARTSIZE) \ $(CONFIG_TARGET_ROOTFS_PARTSIZE) diff --git a/target/linux/at91/image/sama7.mk b/target/linux/at91/image/sama7.mk index bf1704dfb337..8d6f67d80e63 100644 --- a/target/linux/at91/image/sama7.mk +++ b/target/linux/at91/image/sama7.mk @@ -35,7 +35,7 @@ define Build/at91-sdcard ./gen_at91_sdcard_img.sh \ $@.img \ $@.boot \ - $(KDIR)/root.ext4 \ + $(IMAGE_ROOTFS) \ $(AT91_SD_BOOT_PARTSIZE) \ $(CONFIG_TARGET_ROOTFS_PARTSIZE) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: LAN bridge is not working with 5.15.80 [Was: Re: [PATCH v2] mvebu: switch default kernel to 5.15]]
Jonas Gorski [2022-12-05 14:12:42]:
[adding Johnny to the Cc: loop]
Hi,
> Coming back to the original issue, I think there are only two viable
> (short-term) solutions for mvebu (and any other target affected):
>
> a) Set PTP_1588_CLOCK=y for mvebu, forcing it always on.
> b) Disallow PTP_1588_CLOCK for mvebu, preventing it from being enabled.
>
> so essentially treating it like a bool.
FYI Johnny has prepared #11522 ("generic: 5.15: allow MV88E6xxx built-in when
PTP disabled")[1], which IMO looks like a proper fix and I'm going to merge
it if nobody objects.
1. https://github.com/openwrt/openwrt/pull/11522
Cheers,
Petr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] build: fix for sourcing targets image config installed via feeds
Prasun Maiti [2022-11-16 16:33:33]: Hi Christian, > Sourcing of image/Config.in will not happen > When a target is installed from target/linux/feeds/ > > Signed-off-by: Prasun Maiti I've build tested this on OpenWrt 22.03 and it seems to not break anything, so since you've this patch assigned here is my: Acked-by: Petr Štetiar ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: LAN bridge is not working with 5.15.80 [Was: Re: [PATCH v2] mvebu: switch default kernel to 5.15]
Bjørn Mork [2022-12-03 15:56:49]:
> Petr Štetiar writes:
>
> > Indeed, it looks like a regression caused by upstream commit e5f31552674e
> > ("ethernet: fix PTP_1588_CLOCK dependencies") in conjuction with images
> > produced by our buildbots, which use `CONFIG_ALL_KMODS=y` config setting, so
> > it likely makes `PTP_1588_CLOCK=m` and thus `CONFIG_NET_DSA_MV88E6XXX=m`.
> >
> > This simple revert/workaround seems to fix it:
> >
> > diff --git a/drivers/net/dsa/mv88e6xxx/Kconfig
> > b/drivers/net/dsa/mv88e6xxx/Kconfig
> > index 7a2445a34eb7..634a48e6616b 100644
> > --- a/drivers/net/dsa/mv88e6xxx/Kconfig
> > +++ b/drivers/net/dsa/mv88e6xxx/Kconfig
> > @@ -2,7 +2,6 @@
> > config NET_DSA_MV88E6XXX
> > tristate "Marvell 88E6xxx Ethernet switch fabric support"
> > depends on NET_DSA
> > - depends on PTP_1588_CLOCK_OPTIONAL
> > select IRQ_DOMAIN
> > select NET_DSA_TAG_EDSA
> > select NET_DSA_TAG_DSA
>
> That look like it, yes.
>
> But the problem is much more generic, isn't it?
No, lets take a look at that PTP_1588_CLOCK_OPTIONAL:
config PTP_1588_CLOCK_OPTIONAL
tristate
default y if PTP_1588_CLOCK=n
default PTP_1588_CLOCK
help
Drivers that can optionally use the PTP_1588_CLOCK framework
should depend on this symbol to prevent them from being built
into vmlinux while the PTP support itself is in a loadable
module.
If PTP support is disabled, this dependency will still be
met, and drivers refer to dummy helpers.
From help text description it looks to me, that it's not tristate symbol at
all, it's boolean symbol and certainly shouldn't have `default PTP_1588_CLOCK`
as otherwise it's not doing what it's described on the box.
As we've now:
NET_DSA_MV88E6XXX=y
PTP_1588_CLOCK=m
PTP_1588_CLOCK_OPTIONAL=m
but we then endup with `CONFIG_NET_DSA_MV88E6XXX=m` which is not what
PTP_1588_CLOCK_OPTIONAL is supposed to be doing, right?
So IMO something like following is a proper fix:
config PTP_1588_CLOCK_OPTIONAL
- tristate
- default y if PTP_1588_CLOCK=n
- default PTP_1588_CLOCK
+ bool
+ default y if !PTP_1588_CLOCK=y
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: LAN bridge is not working with 5.15.80 [Was: Re: [PATCH v2] mvebu: switch default kernel to 5.15]
Bjørn Mork [2022-12-03 15:01:57]:
[adding Arnd to the Cc: loop]
> Petr Štetiar writes:
>
> > `CONFIG_NET_DSA_MV88E6XXX=m` so it might be related to initramfs?
>
> Isn't that a bit strange? I believe it should be built-in.
Indeed, it looks like a regression caused by upstream commit e5f31552674e
("ethernet: fix PTP_1588_CLOCK dependencies") in conjuction with images
produced by our buildbots, which use `CONFIG_ALL_KMODS=y` config setting, so
it likely makes `PTP_1588_CLOCK=m` and thus `CONFIG_NET_DSA_MV88E6XXX=m`.
This simple revert/workaround seems to fix it:
diff --git a/drivers/net/dsa/mv88e6xxx/Kconfig
b/drivers/net/dsa/mv88e6xxx/Kconfig
index 7a2445a34eb7..634a48e6616b 100644
--- a/drivers/net/dsa/mv88e6xxx/Kconfig
+++ b/drivers/net/dsa/mv88e6xxx/Kconfig
@@ -2,7 +2,6 @@
config NET_DSA_MV88E6XXX
tristate "Marvell 88E6xxx Ethernet switch fabric support"
depends on NET_DSA
- depends on PTP_1588_CLOCK_OPTIONAL
select IRQ_DOMAIN
select NET_DSA_TAG_EDSA
select NET_DSA_TAG_DSA
Cheers,
Petr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: LAN bridge is not working with 5.15.80 [Was: Re: [PATCH v2] mvebu: switch default kernel to 5.15]
Josef Schlehofer [2022-12-03 13:01:48]: > AFAIK There is a package kmod-ikconfig, which can be installed on the device > to check if the specific kernel option is enabled or not, which would answer > my question. ;-) ah, wasnt aware about that, thanks, so there it says `CONFIG_NET_DSA_MV88E6XXX=m` so it might be related to initramfs? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: LAN bridge is not working with 5.15.80 [Was: Re: [PATCH v2] mvebu: switch default kernel to 5.15]
Stijn Segers [2022-12-03 12:39:23]: Hi, > That was taken from Rui's commit adding 5.15 as a testing kernel for mvebu. well, "Run-tested on the following subtargets:" usually means, that this specific patch was tested on that target. So it is little bit misleading. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: LAN bridge is not working with 5.15.80 [Was: Re: [PATCH v2] mvebu: switch default kernel to 5.15]
Josef Schlehofer [2022-12-03 12:20:54]: Hi, > the output from ``zcat /proc/config.gz | grep CONFIG_NET_DSA_MV88E6XXX``? we don't ship config in kernels: target/linux/generic/config-5.15:# CONFIG_IKCONFIG_PROC is not set > Even though, in the config [1], it seems that it should be enabled, it was > actually not on the device itself. > > [1] > https://github.com/openwrt/openwrt/blob/master/target/linux/mvebu/config-5.15#L288 That CI is testing images from https://downloads.openwrt.org/snapshots/targets/mvebu/cortexa9/ so you can poke it yourself. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
LAN bridge is not working with 5.15.80 [Was: Re: [PATCH v2] mvebu: switch default kernel to 5.15]
Stijn Segers [2022-12-02 13:36:20]:
Hi,
> * cortexa9 (Turris Omnia - 03f41b1eb2f15ab06d5800274be6a67c64e2a629)
that is interesting, is the latest snapshot working for you?
I got notified this morning, that Turris Omnia CI job fails[1] as the CI DUT
bringup machinery is unable to confirm[2], that DUT's LAN network is available
after 60 seconds.
That availability check is simply doing following for 60 seconds and then gives
up:
$ ifstatus lan | jsonfilter -qe "@.up"
It seems, that indeed `br-lan` is broken:
root@OpenWrt:/# ifstatus lan
{
"up": false,
"pending": false,
"available": false,
"autostart": true,
"dynamic": false,
"proto": "static",
"device": "br-lan",
"data": {
},
"errors": [
{
"subsystem": "interface",
"code": "NO_DEVICE"
}
]
}
More details from the board:
root@OpenWrt:/# ubus call system board
{
"kernel": "5.15.80",
"hostname": "OpenWrt",
"system": "ARMv7 Processor rev 1 (v7l)",
"model": "Turris Omnia",
"board_name": "cznic,turris-omnia",
"rootfs_type": "initramfs",
"release": {
"distribution": "OpenWrt",
"version": "SNAPSHOT",
"revision": "r21380-5429411f73",
"target": "mvebu/cortexa9",
"description": "OpenWrt SNAPSHOT r21380-5429411f73"
}
}
root@OpenWrt:/# cat /etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdd1:d3b1:e703::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan0'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option device 'eth2'
option proto 'dhcp'
config interface 'wan6'
option device 'eth2'
option proto 'dhcpv6'
dmesg is visible in console_turris-omnia-initramfs.txt[2]. It seems really
like 5.15 regression as:
21.02 snapshot (5.4.225)
https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/3418109997
22.03 snapshot (5.10.156)
https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/341811
Passed the tests fine this morning. Re-run of the job failed as well, so it
should be reproducible issue:
https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/3418110003
1. https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/3418152314
2.
https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/3418152314/artifacts/external_file/console_turris-omnia-initramfs.txt
Cheers,
Petr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 22.03] mvebu: cortexa9: disable devices using broken mv88e6176 switch
Uwe Kleine-König [2022-12-01 12:17:31]: Hi Uwe, > On 12/1/22 10:52, Petr Štetiar wrote: > > Several users have reported, that devices using mv88e6176 switch are > > seriously broken, basically turning that switch into a hub. Until fixed > > those devices should be disabled. > > I wonder if disabling is a sane thing to do here. IMO it's a serious issue, so we've just following sane options: * fix it * remove support for those devices and make everyone aware > People running 22.03.2 won't be able to update Indeed, bummer, we're sorry about that, but the idea here is to make everyone aware and prevent more users from upgrading those devices to latest 22.03 release. > Isn't that worse than a slow network configuration? Quoting from https://github.com/openwrt/openwrt/issues/10997 "After upgrade from 21.02 eth switch start to forward all incoming traffic to all ports. I can see ALL traffic using tcpdump on computer connected to one port and all eth traffic leds are blinking always simultaneously. Same configuration on 21.02 works ok - VLANs and individual traffic are isolated." Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 22.03] mvebu: cortexa9: disable devices using broken mv88e6176 switch
Several users have reported, that devices using mv88e6176 switch are seriously broken, basically turning that switch into a hub. Until fixed those devices should be disabled. I've used TOH with "Switch 88E6176" filter, which provided me with the following list of likely affected devices: * Linksys WRT1200AC v1/v2, WRT1900AC v1/v2 * SolidRun ClearFog Pro * Turris Omnia That device list more or less corresponds with the list of devices mentioned in the linked bug reports. References: https://github.com/openwrt/openwrt/issues/11077 Signed-off-by: Petr Štetiar --- target/linux/mvebu/image/cortexa9.mk | 4 1 file changed, 4 insertions(+) diff --git a/target/linux/mvebu/image/cortexa9.mk b/target/linux/mvebu/image/cortexa9.mk index d9738903fb04..ac83e62e8a5c 100644 --- a/target/linux/mvebu/image/cortexa9.mk +++ b/target/linux/mvebu/image/cortexa9.mk @@ -66,6 +66,7 @@ define Device/cznic_turris-omnia DEVICE_IMG_NAME = $$(2) SUPPORTED_DEVICES += armada-385-turris-omnia BOOT_SCRIPT := turris-omnia + DEFAULT := n endef TARGET_DEVICES += cznic_turris-omnia @@ -114,6 +115,7 @@ define Device/linksys IMAGE/factory.img := append-kernel | pad-to (KERNEL_SIZE) | \ append-ubi | pad-to (PAGESIZE) KERNEL_SIZE := 6144k + DEFAULT := n endef define Device/linksys_wrt1200ac @@ -194,6 +196,7 @@ define Device/linksys_wrt32x KERNEL_SIZE := 6144k KERNEL := kernel-bin | append-dtb SUPPORTED_DEVICES += armada-385-linksys-venom linksys,venom + DEFAULT := y endef TARGET_DEVICES += linksys_wrt32x @@ -299,5 +302,6 @@ define Device/solidrun_clearfog-pro-a1 UBOOT := clearfog-u-boot-spl.kwb BOOT_SCRIPT := clearfog SUPPORTED_DEVICES += armada-388-clearfog armada-388-clearfog-pro + DEFAULT := n endef TARGET_DEVICES += solidrun_clearfog-pro-a1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 24 core buildbot server donation feasible
Dave Taht [2022-11-19 06:56:01]: Hi Dave, > And let me know, and I'll expedite with the manager in charge. thank you for making us aware, I've just filled that application form. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Add swig/host build dependency [Was: Re: [PATCH] uboot-mediatek: clean up build dependencies]
Daniel Golle [2022-11-17 17:01:43]: Hi, > Add swig/host to build dependencies. this doesn't looks like a cleanup as commit subject suggests, but rather contrary :-) Anyway, IIRC we've added swig as a "soft host" requirement on buildbots after this mail[2], so perhaps we should revisit that now and make it a hard host build prereq instead? Something like we do for `mkisofs` in target/linux/x86/Makefile? Otherwise it looks like we would need to move swig from packages feed into main repository and I'm not sure if we really want to do that. 1. https://git.openwrt.org/3776a9157532e694 2. http://lists.openwrt.org/pipermail/openwrt-devel/2021-January/033605.html Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
gpio fiddling from userspace [Was: Re: gpio-mt7621 offset fix for 5.10 kernel series]
Lukas Zeller [2022-10-18 23:10:48]: Hi, > I did investigate this in June on this list [1] and in the openwrt forum [2] > and tried to ask some questions about the right way to handle this, but > apparently it did not echo for some reason back then. IMO there should be `ugpiod` daemon available over ubus, probably written in ucode using libgpiod bindings. It should provide ubus events for GPIO inputs and should be able to control GPIO outputs using ubus calls. Bjørn Mork [2022-10-19 08:24:44]: > Sergio Paracuellos via openwrt-devel > writes: > > > This is the reason we have 'gpio-line-names' property so you can set > > up names for your pins and use it together with actual user space > > tools libgpiod and gpiod. Any other gpio user space library is > > considered deprecated in these days. > > Interesting. This property doesn't seem to be used much in OpenWrt if > my grep foo is good. It should probably be added at least to every > system where we want to access GPIOs from userspace? Yes, that is my[1] understanding as well. 1. https://github.com/openwrt/openwrt/pull/1366#issuecomment-444177376 -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] Refactoring OpenWrt's build infra
Thibaut [2022-10-05 17:56:17]: [adding Jo and Paul to Cc: loop] Hi, > Before I set on to revamp the system accordingly I want to ask if this > proposal seems like a Good Idea™ :) those above mentioned topics are on my TODO list for a long time already, so any help is more then appreciated, thanks! Since we're currently using buildbot repository as our main source for the production containers, I would like to suggest use of issues[1] there to track future plans and ongoing work transparently over there for obvious reasons. Other option might be mirroring of that GitLab buildbot repo to GitHub and use issues there instead if thats preferred. More food for thoughts: * We should replace currently HW EOL machine serving buildbot.openwrt.org - we're currently blocked with this by still pending OpenWrt.org account on Hetzner - this refactoring might be a good opportunity for tackling it * Filter out GitPoller build events originating from noop sources like the CI tooling[2] - IIRC those build events gets propagated down to 2nd stage/package builds as well * Rate/resource limits handling during scripts/feeds invocations - git.openwrt.org might be overloaded in certain time periods, leading to waste of build resources and false positive build results * python3/host: build install race condition with uboot/scripts/dtc/pylibfdt[3] is another such resource waste example * Use HSM backed storage for release/package signing keys * IIRC Paul (and probably more folks) find our buildbot based system arcane and would like to try using something more recent, like for example GitHub Actions instead - perhaps we should try to align with those ideas and consider factoring out the build steps into something more self-contained, build layer agnostic and thus reusable? - it just seems to me, that we're reinventing a wheels[4] * We should consider making our buildbot infra completely open, so anyone can reuse it and/or make it better 1. https://gitlab.com/openwrt/buildbot/-/issues/new 2. https://github.com/openwrt/openwrt/pull/10094#issuecomment-1170760326 3. https://github.com/openwrt/openwrt/pull/10407 4. https://github.com/openwrt/packages/issues/19241 Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Security Advisory 2022-10-04-1 - wolfSSL buffer overflow during a TLS 1.3 handshake (CVE-2022-39173)
DESCRIPTION In wolfSSL prior to version 5.5.1, malicious clients can cause a buffer overflow on server during a TLS protocol version 1.3 handshake. This occurs when an attacker supposedly resumes a previous TLS session. During the resumption Client Hello a Hello Retry Request must be triggered. Both Client Hellos are required to contain a list of duplicate cipher suites to trigger the buffer overflow. In total, two Client Hellos have to be sent: one in the resumed session, and a second one as a response to a Hello Retry Request message. CVE-2022-39173[0] has been assigned to this vulnerability, you can find the latest version of this advisory on our wiki[1]. REQUIREMENTS A malicious attacker would need to send a specially crafted TLS protocol version 1.3 packets to a network exposed service. In default configuration this applies to OpenWrt releases 21.02 and 22.03, which have LuCI web user interface exposed to local area network clients over HTTPS. This service is provided by uhttpd web server, which is using vulnerable libustream-wolfssl wrapper. Additionally it's possible to install several other server packages like lua-eco, libuhttpd-wolfssl, lighttpd-mod-wolfssl, openvpn-wolfssl, strongswan-mod-wolfssl which needs to be updated as well. MITIGATIONS You need to update the affected packages you're using with the command below. opkg update; opkg upgrade libwolfssl libustream-wolfssl; /etc/init.d/uhttpd restart Then verify, that you're running fixed version. opkg list-installed | grep wolfssl The above command should output following: On OpenWrt development snapshot: libustream-wolfssl20201210 - 2022-01-16-868fd881-1 libwolfssl5.5.1.e624513f - 5.5.1-stable-8 On OpenWrt 22.03 release: libustream-wolfssl20201210 - 2022-01-16-868fd881-2 libwolfssl5.5.1.ee39414e - 5.5.1-stable-3 On OpenWrt 21.02 release: libustream-wolfssl20201210 - 2022-01-16-868fd881-2 libwolfssl5.5.1.99a5b54a - 5.5.1-stable-2 The fix is contained in the following and later versions: * OpenWrt master: 2022-10-03 reboot-20859-gf1b7e1434f66 * OpenWrt 22.03: 2022-10-04 v22.03.0-87-g562894b39da3 * OpenWrt 21.02: 2022-10-05 v21.02.3-124-g8444302a92e6 AFFECTED VERSIONS To our knowledge, OpenWrt snapshot images are affected. OpenWrt stable release versions 22.03.0 and OpenWrt v21.02.3 are affected. Older versions of OpenWrt (e.g. OpenWrt 19.07, OpenWrt 18.06, OpenWrt 15.05 and LEDE 17.01) are end of life and not supported any more. CREDITS Thanks to Max at Trail of Bits for the report, "LORIA, INRIA, France" for research on tlspuffin and Kien Truong for helping us getting this diagnosed and fixed in OpenWrt[2,3]. REFERENCES 0. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-39173 1. https://openwrt.org/advisory/2022-10-04-1 2. https://github.com/openwrt/luci/issues/5962 3. https://github.com/wolfSSL/wolfssl/issues/5629 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 21.02 5/5] treewide: fix security issues by bumping all packages using libwolfssl
As wolfSSL is having hard time maintaining ABI compatibility between
releases, we need to manually force rebuild of packages depending on
libwolfssl and thus force their upgrade. Otherwise due to the ABI
handling we would endup with possibly two libwolfssl libraries in the
system, including the patched libwolfssl-5.5.1, but still have
vulnerable services running using the vulnerable libwolfssl-5.4.0.
So in order to propagate update of libwolfssl to latest stable release
done in commit ec8fb542ec3e4 ("wolfssl: fix TLSv1.3 RCE in uhttpd by
using 5.5.1-stable (CVE-2022-39173)") which fixes several remotely
exploitable vulnerabilities, we need to bump PKG_RELEASE of all
packages using wolfSSL library.
Signed-off-by: Petr Štetiar
(cherry picked from commit f1b7e1434f66a3cb09cb9e70b40add354a22e458)
(cherry picked from commit 562894b39da381264a34ce31e9334c8a036fa139)
---
package/libs/ustream-ssl/Makefile | 2 +-
package/network/services/hostapd/Makefile | 2 +-
package/utils/px5g-wolfssl/Makefile | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/package/libs/ustream-ssl/Makefile
b/package/libs/ustream-ssl/Makefile
index 7d9e830381dc..4f474978db77 100644
--- a/package/libs/ustream-ssl/Makefile
+++ b/package/libs/ustream-ssl/Makefile
@@ -1,7 +1,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=ustream-ssl
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL=$(PROJECT_GIT)/project/ustream-ssl.git
diff --git a/package/network/services/hostapd/Makefile
b/package/network/services/hostapd/Makefile
index e529a2efd34e..001bdb439e2e 100644
--- a/package/network/services/hostapd/Makefile
+++ b/package/network/services/hostapd/Makefile
@@ -7,7 +7,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=hostapd
-PKG_RELEASE:=40
+PKG_RELEASE:=41
PKG_SOURCE_URL:=http://w1.fi/hostap.git
PKG_SOURCE_PROTO:=git
diff --git a/package/utils/px5g-wolfssl/Makefile
b/package/utils/px5g-wolfssl/Makefile
index 90296008d687..264a12aa4dd6 100644
--- a/package/utils/px5g-wolfssl/Makefile
+++ b/package/utils/px5g-wolfssl/Makefile
@@ -5,7 +5,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=px5g-wolfssl
-PKG_RELEASE:=$(COMMITCOUNT)
+PKG_RELEASE:=$(COMMITCOUNT).1
PKG_LICENSE:=GPL-2.0-or-later
PKG_USE_MIPS16:=0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 21.02 2/5] wolfssl: bump to 5.4.0
From: Eneas U de Queiroz This version fixes two vulnerabilities: -CVE-2022-34293[high]: Potential for DTLS DoS attack -[medium]: Ciphertext side channel attack on ECC and DH operations. The patch fixing x86 aesni build has been merged upstream. Signed-off-by: Eneas U de Queiroz (cherry picked from commit 9710fe70a68e0a004b1906db192d7a6c8f810ac5) Signed-off-by: Christian Marangi (cherry picked from commit ade7c6db1e6c2c0c8d2338948c37cfa7429ebccc) --- package/libs/wolfssl/Makefile | 4 ++-- .../libs/wolfssl/patches/100-disable-hardening-check.patch| 2 +- package/libs/wolfssl/patches/200-ecc-rng.patch| 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile index 1324a439299b..d0a67e118be2 100644 --- a/package/libs/wolfssl/Makefile +++ b/package/libs/wolfssl/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=wolfssl -PKG_VERSION:=5.3.0-stable +PKG_VERSION:=5.4.0-stable PKG_RELEASE:=$(AUTORELEASE) PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION) -PKG_HASH:=1a3bb310dc01d3e73d9ad91b6ea8249d081016f8eef4ae8f21d3421f91ef1de9 +PKG_HASH:=dc36cc19dad197253e5c2ecaa490c7eef579ad448706e55d73d79396e814098b PKG_FIXUP:=libtool libtool-abiver PKG_INSTALL:=1 diff --git a/package/libs/wolfssl/patches/100-disable-hardening-check.patch b/package/libs/wolfssl/patches/100-disable-hardening-check.patch index 7e473b390bb2..d3ad2e27bc3e 100644 --- a/package/libs/wolfssl/patches/100-disable-hardening-check.patch +++ b/package/libs/wolfssl/patches/100-disable-hardening-check.patch @@ -1,6 +1,6 @@ --- a/wolfssl/wolfcrypt/settings.h +++ b/wolfssl/wolfcrypt/settings.h -@@ -2338,7 +2338,7 @@ extern void uITRON4_free(void *p) ; +@@ -2442,7 +2442,7 @@ extern void uITRON4_free(void *p) ; #endif /* warning for not using harden build options (default with ./configure) */ diff --git a/package/libs/wolfssl/patches/200-ecc-rng.patch b/package/libs/wolfssl/patches/200-ecc-rng.patch index f1f156a8aeac..2e09e6d273e3 100644 --- a/package/libs/wolfssl/patches/200-ecc-rng.patch +++ b/package/libs/wolfssl/patches/200-ecc-rng.patch @@ -11,7 +11,7 @@ RNG regardless of the built settings for wolfssl. --- a/wolfcrypt/src/ecc.c +++ b/wolfcrypt/src/ecc.c -@@ -11655,21 +11655,21 @@ void wc_ecc_fp_free(void) +@@ -12288,21 +12288,21 @@ void wc_ecc_fp_free(void) #endif /* FP_ECC */ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 21.02 3/5] wolfssl: bump to 5.5.0
From: Ivan Pavlov Remove upstreamed: 101-update-sp_rand_prime-s-preprocessor-gating-to-match.patch Some low severity vulnerabilities fixed OpenVPN compatibility fixed (broken in 5.4.0) Other fixes && improvements Signed-off-by: Ivan Pavlov (cherry picked from commit 3d88f26d74f7771b808082cef541ed8286c40491) (cherry picked from commit 0c8425bf11590afb0c6f1545b328ecb6ed4aee87) --- package/libs/wolfssl/Makefile | 4 ++-- .../libs/wolfssl/patches/100-disable-hardening-check.patch| 2 +- package/libs/wolfssl/patches/200-ecc-rng.patch| 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile index d0a67e118be2..ce66ec81eada 100644 --- a/package/libs/wolfssl/Makefile +++ b/package/libs/wolfssl/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=wolfssl -PKG_VERSION:=5.4.0-stable +PKG_VERSION:=5.5.0-stable PKG_RELEASE:=$(AUTORELEASE) PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION) -PKG_HASH:=dc36cc19dad197253e5c2ecaa490c7eef579ad448706e55d73d79396e814098b +PKG_HASH:=c34b74b5f689fac7becb05583b044e84d3b10d39f38709f0095dd5d423ded67f PKG_FIXUP:=libtool libtool-abiver PKG_INSTALL:=1 diff --git a/package/libs/wolfssl/patches/100-disable-hardening-check.patch b/package/libs/wolfssl/patches/100-disable-hardening-check.patch index d3ad2e27bc3e..01bb5974ba33 100644 --- a/package/libs/wolfssl/patches/100-disable-hardening-check.patch +++ b/package/libs/wolfssl/patches/100-disable-hardening-check.patch @@ -1,6 +1,6 @@ --- a/wolfssl/wolfcrypt/settings.h +++ b/wolfssl/wolfcrypt/settings.h -@@ -2442,7 +2442,7 @@ extern void uITRON4_free(void *p) ; +@@ -2445,7 +2445,7 @@ extern void uITRON4_free(void *p) ; #endif /* warning for not using harden build options (default with ./configure) */ diff --git a/package/libs/wolfssl/patches/200-ecc-rng.patch b/package/libs/wolfssl/patches/200-ecc-rng.patch index 2e09e6d273e3..d68ef7f3853a 100644 --- a/package/libs/wolfssl/patches/200-ecc-rng.patch +++ b/package/libs/wolfssl/patches/200-ecc-rng.patch @@ -11,7 +11,7 @@ RNG regardless of the built settings for wolfssl. --- a/wolfcrypt/src/ecc.c +++ b/wolfcrypt/src/ecc.c -@@ -12288,21 +12288,21 @@ void wc_ecc_fp_free(void) +@@ -12348,21 +12348,21 @@ void wc_ecc_fp_free(void) #endif /* FP_ECC */ @@ -37,7 +37,7 @@ RNG regardless of the built settings for wolfssl. --- a/wolfssl/wolfcrypt/ecc.h +++ b/wolfssl/wolfcrypt/ecc.h -@@ -650,10 +650,8 @@ WOLFSSL_API +@@ -650,10 +650,8 @@ WOLFSSL_ABI WOLFSSL_API void wc_ecc_fp_free(void); WOLFSSL_LOCAL void wc_ecc_fp_init(void); ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
