From yetanothergeek at gmail.com Mon May 1 14:24:58 2023 From: yetanothergeek at gmail.com (Jeff Pohlmeyer) Date: Mon, 1 May 2023 09:24:58 -0500 Subject: Busybox modprobe brings error "Invalid ELF header magic: !=ELF" In-Reply-To: References: <6fe13fa9-bc25-1aec-ac1f-59e34435be51@mayer-emi.at> <1c951152-2011-6184-10a4-95c51266c906@mayer-emi.at> Message-ID: On Fri, Apr 28, 2023 at 9:19?AM Jeff Pohlmeyer wrote: > On Fri, Mar 31, 2023 at 6:20?AM Denys Vlasenko wrote: > > Kernel does not auto-detect compressed modules. > > We need to call finit_module() with MODULE_INIT_COMPRESSED_FILE flag > > if module is compressed. > > > > Fixed it in git. Please try it now. > This is not working for me. > ... > But in the worst case (which seems to happen randomly), finit_module() > tries the MODULE_INIT_COMPRESSED_FILE flag and immediately receives a > SIGKILL, killing busybox and failing to load the module. (See > attachment for dmesg output.) > > This is on Artix Linux with their stock kernel 6.2.11. With the latest Artix kernel upgrade from 6.2.11 to 6.2.13, the random crashes seem to be fixed. MODULE_INIT_COMPRESSED_FILE is still failing, but at least now it isn't killing busybox. But the "Invalid ELF header magic" messages are still there. - Jeff From vda.linux at googlemail.com Tue May 2 12:31:30 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 2 May 2023 14:31:30 +0200 Subject: Busybox modprobe brings error "Invalid ELF header magic: !=ELF" In-Reply-To: References: <6fe13fa9-bc25-1aec-ac1f-59e34435be51@mayer-emi.at> <1c951152-2011-6184-10a4-95c51266c906@mayer-emi.at> Message-ID: On Mon, May 1, 2023 at 4:25?PM Jeff Pohlmeyer wrote: > On Fri, Apr 28, 2023 at 9:19?AM Jeff Pohlmeyer wrote: > > On Fri, Mar 31, 2023 at 6:20?AM Denys Vlasenko wrote: > > > > Kernel does not auto-detect compressed modules. > > > We need to call finit_module() with MODULE_INIT_COMPRESSED_FILE flag > > > if module is compressed. > > > > > > Fixed it in git. Please try it now. > > > This is not working for me. > > ... > > But in the worst case (which seems to happen randomly), finit_module() > > tries the MODULE_INIT_COMPRESSED_FILE flag and immediately receives a > > SIGKILL, killing busybox and failing to load the module. (See > > attachment for dmesg output.) > > > > This is on Artix Linux with their stock kernel 6.2.11. > > With the latest Artix kernel upgrade from 6.2.11 to 6.2.13, the random > crashes seem to be fixed. > > MODULE_INIT_COMPRESSED_FILE is still failing, but at least now it > isn't killing busybox. > > But the "Invalid ELF header magic" messages are still there. Hmm. So it works, there are just these annoying messages? Should we add an option to NOT try finit_module at all, and just decompress modules in userspace? From yetanothergeek at gmail.com Wed May 3 15:47:28 2023 From: yetanothergeek at gmail.com (Jeff Pohlmeyer) Date: Wed, 3 May 2023 10:47:28 -0500 Subject: Busybox modprobe brings error "Invalid ELF header magic: !=ELF" In-Reply-To: References: <6fe13fa9-bc25-1aec-ac1f-59e34435be51@mayer-emi.at> <1c951152-2011-6184-10a4-95c51266c906@mayer-emi.at> Message-ID: On Tue, May 2, 2023 at 7:31?AM Denys Vlasenko wrote: > On Mon, May 1, 2023 at 4:25?PM Jeff Pohlmeyer wrote: > > With the latest Artix kernel upgrade from 6.2.11 to 6.2.13, the random > > crashes seem to be fixed. > Hmm. So it works, there are just these annoying messages? Looks like I spoke too soon, the crash is still there with the 6.2.13 kernel if I test on a machine with 2GB of RAM. Out of curiosity I tried the 6.3.1 kernel from the Arch Linux testing repo and the situation is even worse, it crashes every single time, even on a machine with 16GB of RAM. > Should we add an option to NOT try finit_module at all, > and just decompress modules in userspace? I assume you mean a build-time option? That would solve the problem for me, but I would still like to hear from some other testers to confirm this isn't just something unique to my setup. - Jeff From primoz.fiser at norik.com Thu May 4 11:59:41 2023 From: primoz.fiser at norik.com (Primoz Fiser) Date: Thu, 4 May 2023 13:59:41 +0200 Subject: Busybox hwclock implement set/get RTC params Message-ID: <06c54cc8-1e72-e8db-7173-3bfa6021d7a9@norik.com> Hi all, currently we have a use-case on embedded Linux machine to set/get RTC clock params by using hwclock. The support for those set/get RTC params ioctl()s was introduced in mainline kernel v5.16 [1]. For example: $ hwclock --param-set bsm=0x2 $ hwclock --param-get bsm Since we are using busybox's hwclock implementation instead of util-linux's, we of-course cannot do that on that specific machine. We are also quite reluctant at the moment to switch to util-linux just to cover this specific use-case. On the other hand, util-linux got support for those set/get RTC params ioctl()s with [2]. So the questions are: 1) Does anyone perhaps already work on hwclock supporting set/get RTC params? 2) If we invest time implementing hwlock set/get RTC params, would you be willing to accept it? We would like to avoid developing a solution that won't be accepted into busybox upstream. 3) At this stage, looking at [2], do you see any potential issues when trying to support hwclock set/get RTC params on Busybox? Best regards, Primoz References: [1] https://lore.kernel.org/all/20211018151933.76865-1-alexandre.belloni at bootlin.com/ [2] https://github.com/util-linux/util-linux/pull/1570 -- Primoz Fiser | phone: +386-41-540-545 | ---------------------------------------------------------| Norik systems d.o.o. | https://www.norik.com | Your embedded software partner | email: info at norik.com | Slovenia, EU | phone: +386-41-540-545 | -------------- next part -------------- An HTML attachment was scrubbed... URL: From rep.dot.nop at gmail.com Sat May 6 13:03:30 2023 From: rep.dot.nop at gmail.com (Bernhard Reutner-Fischer) Date: Sat, 06 May 2023 15:03:30 +0200 Subject: Busybox hwclock implement set/get RTC params In-Reply-To: <06c54cc8-1e72-e8db-7173-3bfa6021d7a9@norik.com> References: <06c54cc8-1e72-e8db-7173-3bfa6021d7a9@norik.com> Message-ID: <4B62D125-1508-4811-AAC0-1A7C49110155@gmail.com> On 4 May 2023 13:59:41 CEST, Primoz Fiser wrote: >2) If we invest time implementing hwlock set/get RTC params, would you >be willing to accept it? We would like to avoid developing a solution >that won't be accepted into busybox upstream. I think it makes sense, yes. > >3) At this stage, looking at [2], do you see any potential issues when >trying to support hwclock set/get RTC params on Busybox? I would not put too much effort into supporting older kernels for this, just a simple version check, if you agree. thanks, From rep.dot.nop at gmail.com Sat May 6 21:40:06 2023 From: rep.dot.nop at gmail.com (Bernhard Reutner-Fischer) Date: Sat, 06 May 2023 23:40:06 +0200 Subject: [RFC PATCH] ip link: support for the CAN netlink In-Reply-To: References: <20230420193533.1963524-1-dario.binacchi@amarulasolutions.com> Message-ID: <32AAD054-5011-4D19-BFC9-3197DA2CA0E8@gmail.com> On 30 April 2023 11:52:26 CEST, Dario Binacchi wrote: >Hi Nikolaus, > >On Thu, Apr 27, 2023 at 11:28?AM Nikolaus Voss wrote: >> >> Hi Dario, >> >> I posted a more minimalistic approach > >This is the reason why I added the CONFIG_IPLINK_CAN option. >Anyway, I think we both agree that busybox lacks a CAN-type management >for the 'ip link' command Yes. So did anybody review the bigger patch? From vda.linux at googlemail.com Sun May 7 16:45:03 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 7 May 2023 18:45:03 +0200 Subject: [PATCH v5] readlink: more size optimization In-Reply-To: <20230425182237.369dad0f@devuan> References: <20230418122237.1820276-1-eblake@redhat.com> <7045c162-75e6-8dcf-3aae-311d13d7c4fa@gigawatt.nl> <20230425182237.369dad0f@devuan> Message-ID: > + > + fputs_stdout(buf); > + if (!(opt & 1)) > + bb_putchar('\n'); Let's not tempt libc to split the write into two syscalls. Applied, thank you From vda.linux at googlemail.com Sun May 7 16:56:50 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 7 May 2023 18:56:50 +0200 Subject: [PATCH] build system: Make it possible to build with 64bit time_t In-Reply-To: <20230420121317.444127-1-uwe@kleine-koenig.org> References: <20230420121317.444127-1-uwe@kleine-koenig.org> Message-ID: Applied, thank you! On Thu, Apr 20, 2023 at 2:13?PM Uwe Kleine-K?nig wrote: > > From: Uwe Kleine-K?nig > > On most 32bit architectures time_t (and a few other time related types) > are a signed 32bit wide integer type. > As a consequence they can only represent dates between > > Fri Dec 13 08:45:52 PM UTC 1901 > > (-0x80000000 seconds before Jan 1 1970) and > > Tue Jan 19 03:14:07 AM UTC 2038 > > (0x7fffffff seconds after Jan 1 1970). Given that some machines that are > built today have an expected lifetime of >15 years, this needs to be > extended. To to that, define the cpp symbol _TIME_BITS to 64 which > results in some magic in glibc to make time_t (and the few other time > related types) 64 bit wide. > > This new switch CONFIG_TIME64 is in the spirit of CONFIG_LFS and only > expected to have the expected effect with glibc. On musl for examples > time_t already defaults to 64bit wide types. > --- > Config.in | 10 ++++++++++ > Makefile.flags | 1 + > 2 files changed, 11 insertions(+) > > diff --git a/Config.in b/Config.in > index a98a8b15b854..214eba54630e 100644 > --- a/Config.in > +++ b/Config.in > @@ -108,6 +108,16 @@ config LFS > programs that can benefit from large file support include dd, gzip, > cp, mount, tar. > > +config TIME64 > + bool "Support 64bit wide time types" > + default y > + depends on LFS > + help > + Make times later than 2038 representable for several libc syscalls > + (stat, clk_gettime etc.). Note this switch is specific to glibc and has > + no effect on platforms that already use 64bit wide time types (i.e. all > + 64bit archs and some selected 32bit archs (currently riscv and x32)). > + > config PAM > bool "Support PAM (Pluggable Authentication Modules)" > default n > diff --git a/Makefile.flags b/Makefile.flags > index c34356230a9f..e17defbd00f9 100644 > --- a/Makefile.flags > +++ b/Makefile.flags > @@ -15,6 +15,7 @@ CPPFLAGS += \ > -include include/autoconf.h \ > -D_GNU_SOURCE -DNDEBUG \ > $(if $(CONFIG_LFS),-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64) \ > + $(if $(CONFIG_TIME64),-D_TIME_BITS=64) \ > -DBB_VER=$(squote)$(quote)$(BB_VER)$(quote)$(squote) > > CFLAGS += $(call cc-option,-Wall,) > > base-commit: e512aeb0fb3c585948ae6517cfdf4a53cf99774d > -- > 2.39.2 > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From uwe at kleine-koenig.org Sun May 7 18:25:53 2023 From: uwe at kleine-koenig.org (=?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?=) Date: Sun, 7 May 2023 20:25:53 +0200 Subject: [PATCH] build system: Make it possible to build with 64bit time_t In-Reply-To: References: <20230420121317.444127-1-uwe@kleine-koenig.org> Message-ID: <57db0e9c-bae1-0f1f-61e3-96def6d82708@kleine-koenig.org> Hi Denys, On 5/7/23 18:56, Denys Vlasenko wrote: > Applied, thank you! Thanks, that's great. While you are in the mood to apply patches, might I direct your attention to my earlier (and IMHO more relevant) patch titled "nslookup: ensure unique transaction IDs for the DNS queries" that I sent back in October? Best regards Uwe -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From raphael.melotte at mind.be Tue May 9 10:09:14 2023 From: raphael.melotte at mind.be (=?UTF-8?q?Rapha=C3=ABl=20M=C3=A9lotte?=) Date: Tue, 9 May 2023 12:09:14 +0200 Subject: [PATCH v4] seedrng: fix getrandom() detection for non-glibc libc Message-ID: <20230509100914.1539178-1-raphael.melotte@mind.be> glibc <= 2.24 does not provide getrandom(). A check for it has been added in 200a9669fbf6f06894e4243cccc9fc11a1a6073a and fixed in cb57abb46f06f4ede8d9ccbdaac67377fdf416cf. However, building with a libc other than glibc can lead to the same problem as not every other libc has getrandom() either: - uClibc provides it from v1.0.2 onwards, but requires to define _GNU_SOURCE (all versions - we already define it by default), and stddef to be included first (when using uClibc < 1.0.35 - we already include it through libbb.h). - musl libc has getrandom(), but only from version 1.1.20 onwards. As musl does not provide __MUSL__ or version information, it's not possible to check for it like we did for glibc. All of this makes it difficult (or impossible in case of musl) to check what we need to do to have getrandom() based on each libc versions. On top of that, getrandom() is also not available on older kernels. As an example, when using a 3.10 kernel with uClibc 1.0.26, getrandom() is declared so compiling works, but it fails at link time because getrandom() is not defined. To make it easier, take a similar approach to what was done for the crypt library: try to build a sample program to see if we have getrandom(). To keep it compatible with different versions of make (for reference see [1]), a variable for '#' is also introduced. Based on the new Makefile variable, we now either use the libc-provided getrandom() when it's available, or use our own implementation when it's not (like it was the case already for glibc < 2.25). This should fix compiling with many libc/kernel combinations. [1]: https://git.savannah.gnu.org/cgit/make.git/commit/?id=c6966b323811c37acedff05b576b907b06aea5f4 Signed-off-by: Rapha?l M?lotte --- Changes v3 -> v4: - use a variable for '#' for compatibility with GNU make 4.2.1 and earlier. Changes v2 -> v3: - fix _GNU_SOURCE define location Changes v1 -> v2: - move _GNU_SOURCE to bb_libtest.c - remove GRND_NONBLOCK Note that I was not able to test every single combination, but I could confirm it builds successfully for: uClibc 10.0.24, linux headers 3.10 (libc getrandom NOT used) uClibc 1.0.36, linux headers 4.9 (libc getrandom used) musl 1.1.16, linux headers 4.12 (libc getrandom NOT used) musl 1.2.1, linux headers (libc getrandom used) glibc 2.25, linux headers 4.10 (libc getrandom used) Makefile.flags | 12 ++++++++++++ miscutils/seedrng.c | 8 ++++---- 2 files changed, 16 insertions(+), 4 deletions(-) diff --git a/Makefile.flags b/Makefile.flags index 1cec5ba20..0d437303a 100644 --- a/Makefile.flags +++ b/Makefile.flags @@ -161,6 +161,18 @@ ifeq ($(RT_AVAILABLE),y) LDLIBS += rt endif +# GNU Make version 4.2.1 and earlier require number signs ('#') +# inside function invocations to be escaped, while versions 4.3+ +# require them to be unescaped. Use a variable for it so that it works +# for both versions: +C := \# +# Not all libc versions have getrandom, so check for it: +HAVE_GETRANDOM := $(shell printf '$Cdefine _GNU_SOURCE\n$Cinclude \n$Cinclude \nint main(void){char buf[256];\ngetrandom(buf,sizeof(buf),0);}' >bb_libtest.c; $(CC) $(CFLAGS) $(CFLAGS_busybox) -o /dev/null bb_libtest.c >/dev/null 2>&1 && echo "y"; rm bb_libtest.c) + +ifeq ($(HAVE_GETRANDOM),y) +CFLAGS += -DHAVE_GETRANDOM +endif + # libpam may use libpthread, libdl and/or libaudit. # On some platforms that requires an explicit -lpthread, -ldl, -laudit. # However, on *other platforms* it fails when some of those flags diff --git a/miscutils/seedrng.c b/miscutils/seedrng.c index 3bf6e2ea7..2f1e18c32 100644 --- a/miscutils/seedrng.c +++ b/miscutils/seedrng.c @@ -44,8 +44,10 @@ #include #include -/* Fix up glibc <= 2.24 not having getrandom() */ -#if defined(__GLIBC__) && __GLIBC__ == 2 && __GLIBC_MINOR__ <= 24 +/* Fix up some libc (e.g. glibc <= 2.24) not having getrandom() */ +#if defined HAVE_GETRANDOM +#include +#else /* No getrandom */ #include static ssize_t getrandom(void *buffer, size_t length, unsigned flags) { @@ -56,8 +58,6 @@ static ssize_t getrandom(void *buffer, size_t length, unsigned flags) return -1; # endif } -#else -#include #endif /* Apparently some headers don't ship with this yet. */ -- 2.39.1 From vda.linux at googlemail.com Tue May 9 17:33:08 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 9 May 2023 19:33:08 +0200 Subject: [PATCH] nslookup: ensure unique transaction IDs for the DNS queries In-Reply-To: <20221008172252.3970941-1-uwe@kleine-koenig.org> References: <20221008172252.3970941-1-uwe@kleine-koenig.org> Message-ID: Applied, thank you. On Sat, Oct 8, 2022 at 7:23?PM Uwe Kleine-K?nig wrote: > > The transaction IDs generated by res_mkquery() for both glibc and musl only > depends on the state of the monotonic clock. > For some machines (here: a TP-Link RE200 powered by a MediaTek MT7620A) > the monotonic clock has a coarse resolution (here: 20 ?s) and it can happen > that the requests for A and AAAA share the same transaction ID. > > In that case the mapping from received responses to the sent queries > doesn't work and name resolution fails as follows: > > # /bin/busybox nslookup heise.de > Server: 127.0.0.1 > Address: 127.0.0.1:53 > > Non-authoritative answer: > Name: heise.de > Address: 193.99.144.80 > > *** Can't find heise.de: No answer > > because the AAAA reply is dropped as a duplicate reply to the A query. > > To prevent this make sure the transaction IDs are unique. > --- > networking/nslookup.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/networking/nslookup.c b/networking/nslookup.c > index 6da97baf4216..61e3eb6052ab 100644 > --- a/networking/nslookup.c > +++ b/networking/nslookup.c > @@ -978,6 +978,10 @@ int nslookup_main(int argc UNUSED_PARAM, char **argv) > } > } > > + /* Ensure the Transaction IDs are unique */ > + for (rc = 1; rc < G.query_count; rc++) > + G.query[rc].query[1] = G.query[rc - 1].query[1] + 1; > + > for (rc = 0; rc < G.serv_count;) { > int c; > > -- > 2.37.2 > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From vda.linux at googlemail.com Tue May 9 17:33:40 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 9 May 2023 19:33:40 +0200 Subject: [PATCH] nslookup: ensure unique transaction IDs for the DNS queries In-Reply-To: <20221008172252.3970941-1-uwe@kleine-koenig.org> References: <20221008172252.3970941-1-uwe@kleine-koenig.org> Message-ID: On Sat, Oct 8, 2022 at 7:23?PM Uwe Kleine-K?nig wrote: > > The transaction IDs generated by res_mkquery() for both glibc and musl only > depends on the state of the monotonic clock. Hmm... did you report this to them? From vda.linux at googlemail.com Wed May 10 08:58:00 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 10 May 2023 10:58:00 +0200 Subject: [PATCH] nslookup: ensure unique transaction IDs for the DNS queries In-Reply-To: <20230509174842.GA20050@brightrain.aerifal.cx> References: <20221008172252.3970941-1-uwe@kleine-koenig.org> <20230509174842.GA20050@brightrain.aerifal.cx> Message-ID: On Tue, May 9, 2023 at 7:48?PM Rich Felker wrote: > On Tue, May 09, 2023 at 07:33:40PM +0200, Denys Vlasenko wrote: > > On Sat, Oct 8, 2022 at 7:23?PM Uwe Kleine-K?nig wrote: > > > > > > The transaction IDs generated by res_mkquery() for both glibc and musl only > > > depends on the state of the monotonic clock. > > > > Hmm... did you report this to them? > > Yes. It's not a fixable "problem" -- the libc res_mkquery can't know > when or in what context the caller intends to use the packet it > produces, so it can't be responsible for guaranteeing it can't have an > id collision. The space is way too small to avoid collisions in any > case. If we went out of our way (going stateful) to make the assigned > ids more sequential (not "independent"), we'd just be reducing the > (already weak) unpredictability without gaining a useful property. You miss the point. CLOCK_MONOTONIC may simply be too granular on some hardware - returning the same value for the duration of several milliseconds. In this case, musl's IDs will be the same for successive calls of res_mkquery() - not simply "insufficiently random". Maybe hash in the message bytes in addition to using current nanoseconds? (While we are at it. There is a *signed* division by 256 in the code, intended to mean "take the second byte": int id; ... chars[0] = id / 256; gcc quite often does NOT convert signed divisions to a simple shift. Maybe change id's type to "unsigned"? ). From ska-dietlibc at skarnet.org Wed May 10 11:36:07 2023 From: ska-dietlibc at skarnet.org (Laurent Bercot) Date: Wed, 10 May 2023 11:36:07 +0000 Subject: [PATCH] nslookup: ensure unique transaction IDs for the DNS queries In-Reply-To: References: <20221008172252.3970941-1-uwe@kleine-koenig.org> <20230509174842.GA20050@brightrain.aerifal.cx> Message-ID: >You miss the point. CLOCK_MONOTONIC may simply be too granular >on some hardware - returning the same value for the duration of >several milliseconds. Wait, what? Is that a thing? Is there actual hardware where CLOCK_MONOTONIC stalls for a noticeable period of time? That does not sound permitted by POSIX: > If the Monotonic Clock option is supported, all implementations shall support a clock_id of CLOCK_MONOTONIC defined in . This clock represents the monotonic clock for the system. For this clock, the value returned by clock_gettime() represents the amount of time (in seconds and nanoseconds) since an unspecified point in the past (for example, system start-up time, or the Epoch). This point does not change after system start-up time. Since it's the same language as in the definition of CLOCK_REALTIME, I've always interpreted that as CLOCK_MONOTONIC being mandated to have the same granularity as CLOCK_REALTIME. -- Laurent From David.Laight at ACULAB.COM Wed May 10 12:01:17 2023 From: David.Laight at ACULAB.COM (David Laight) Date: Wed, 10 May 2023 12:01:17 +0000 Subject: [PATCH] nslookup: ensure unique transaction IDs for the DNS queries In-Reply-To: References: <20221008172252.3970941-1-uwe@kleine-koenig.org> <20230509174842.GA20050@brightrain.aerifal.cx> Message-ID: <3fc828778e914a98b9a66b6590691793@AcuMS.aculab.com> From: Laurent Bercot > Sent: 10 May 2023 12:36 > > >You miss the point. CLOCK_MONOTONIC may simply be too granular > >on some hardware - returning the same value for the duration of > >several milliseconds. > > Wait, what? Is that a thing? Is there actual hardware where > CLOCK_MONOTONIC stalls for a noticeable period of time? > That does not sound permitted by POSIX: Some implementation will increment the nanoseconds on every call to avoid returning the same value. But the underlying timer might only change every 10ms (or more). Even though the output value has a nanosecond part. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From d+busybox at adaptive-enterprises.com Thu May 11 13:59:04 2023 From: d+busybox at adaptive-enterprises.com (David Leonard) Date: Thu, 11 May 2023 23:59:04 +1000 (AEST) Subject: [PATCH 1/2] od: fix -O Message-ID: <506r4932-981o-2q27-4080-q78nqnq2q83s@nqncgvir-ragrecevfrf.pbz> od with option -O (4-byte octal) was incorrectly displaying 2-byte decimal when built without CONFIG_DESKTOP --- coreutils/od.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/coreutils/od.c b/coreutils/od.c index 6f22331e0..dcf1bd6f6 100644 --- a/coreutils/od.c +++ b/coreutils/od.c @@ -166,7 +166,7 @@ static const char od_o2si[] ALIGN1 = { 0, 1, 2, 3, 5, 4, 6, 6, 7, 8, 9, 0xa, 0xb, 0xa, 0xa, - 0xb, 1, 8, 9, + 0xc, 1, 8, 9, }; int od_main(int argc, char **argv) MAIN_EXTERNALLY_VISIBLE; -- 2.34.1 From d+busybox at adaptive-enterprises.com Thu May 11 14:00:39 2023 From: d+busybox at adaptive-enterprises.com (David Leonard) Date: Fri, 12 May 2023 00:00:39 +1000 (AEST) Subject: [PATCH 2/2] od: add tests Message-ID: <1p80p08o-9o66-n1rr-7q57-8ps22q2071@nqncgvir-ragrecevfrf.pbz> * Added tests for od (non-DESKTOP little-endian) * Allow 'optional' to invert meaning of a config option with '!' --- testsuite/od.tests | 191 +++++++++++++++++++++++++++++++++++++++++++ testsuite/testing.sh | 10 +++ 2 files changed, 201 insertions(+) diff --git a/testsuite/od.tests b/testsuite/od.tests index 0880e0d2f..f6298a43c 100755 --- a/testsuite/od.tests +++ b/testsuite/od.tests @@ -6,6 +6,197 @@ # testing "test name" "commands" "expected result" "file input" "stdin" +input="$(printf '\001\002\003\nABC\xfe')" + +_le=$(printf '\0\1' | od -i | grep -q 256 && echo 1) +le () { [ $_le ] || SKIP=1; } + +optional !DESKTOP +testing "od -a (!DESKTOP)" \ + "od -a" \ +"\ +0000000 soh stx etx lf A B C fe +0000010 +" \ + "" "$input" + +optional !DESKTOP +testing "od -B (!DESKTOP)" \ + "od -B" \ +"\ +0000000 001001 005003 041101 177103 +0000010 +" \ + "" "$input" + +optional !DESKTOP +le +testing "od -o (!DESKTOP little-endian)" \ + "od -o" \ +"\ +0000000 001001 005003 041101 177103 +0000010 +" \ + "" "$input" + +optional !DESKTOP +testing "od -b (!DESKTOP)" \ + "od -b" \ +"\ +0000000 001 002 003 012 101 102 103 376 +0000010 +" \ + "" "$input" + +optional !DESKTOP +testing "od -c (!DESKTOP)" \ + "od -c" \ +"\ +0000000 001 002 003 \\\\n A B C 376 +0000010 +" \ + "" "$input" + +optional !DESKTOP +le +testing "od -d (!DESKTOP little-endian)" \ + "od -d" \ +"\ +0000000 00513 02563 16961 65091 +0000010 +" \ + "" "$input" + +optional !DESKTOP +le +testing "od -D (!DESKTOP little-endian)" \ + "od -D" \ +"\ +0000000 0167969281 4265820737 +0000010 +" \ + "" "$input" + +optional !DESKTOP +le +testing "od -e (!DESKTOP little-endian)" \ + "od -e" \ +"\ +0000000 -1.61218556514036e+300 +0000010 +" \ + "" "$input" + +optional !DESKTOP +le +testing "od -F (!DESKTOP little-endian)" \ + "od -F" \ +"\ +0000000 -1.61218556514036e+300 +0000010 +" \ + "" "$input" + +optional !DESKTOP +le +testing "od -f (!DESKTOP little-endian)" \ + "od -f" \ +"\ +0000000 6.3077975e-33 -6.4885867e+37 +0000010 +" \ + "" "$input" + +optional !DESKTOP +le +testing "od -H (!DESKTOP little-endian)" \ + "od -H" \ +"\ +0000000 0a030201 fe434241 +0000010 +" \ + "" "$input" + +optional !DESKTOP +le +testing "od -X (!DESKTOP little-endian)" \ + "od -X" \ +"\ +0000000 0a030201 fe434241 +0000010 +" \ + "" "$input" + +optional !DESKTOP +le +testing "od -h (!DESKTOP little-endian)" \ + "od -h" \ +"\ +0000000 0201 0a03 4241 fe43 +0000010 +" \ + "" "$input" + +optional !DESKTOP +le +testing "od -x (!DESKTOP little-endian)" \ + "od -x" \ +"\ +0000000 0201 0a03 4241 fe43 +0000010 +" \ + "" "$input" + +optional !DESKTOP +le +testing "od -I (!DESKTOP little-endian)" \ + "od -I" \ +"\ +0000000 167969281 -29146559 +0000010 +" \ + "" "$input" + +optional !DESKTOP +le +testing "od -L (!DESKTOP little-endian)" \ + "od -L" \ +"\ +0000000 167969281 -29146559 +0000010 +" \ + "" "$input" + +optional !DESKTOP +le +testing "od -i (!DESKTOP little-endian)" \ + "od -i" \ +"\ +0000000 513 2563 16961 -445 +0000010 +" \ + "" "$input" + +optional !DESKTOP +le +testing "od -O (!DESKTOP little-endian)" \ + "od -O" \ +"\ +0000000 01200601001 37620641101 +0000010 +" \ + "" "$input" + +optional !DESKTOP +le +testing "od -l (!DESKTOP little-endian)" \ + "od -l" \ +"\ +0000000 167969281 -29146559 +0000010 +" \ + "" "$input" + optional DESKTOP testing "od -b" \ "od -b" \ diff --git a/testsuite/testing.sh b/testsuite/testing.sh index f5b756947..95bb46dda 100644 --- a/testsuite/testing.sh +++ b/testsuite/testing.sh @@ -56,11 +56,21 @@ optional() { SKIP= while test "$1"; do + case $1 in + "!"*) + case "${OPTIONFLAGS}" in + *:${1#!}:*) SKIP=1; return;; + esac + shift + ;; + *) case "${OPTIONFLAGS}" in *:$1:*) ;; *) SKIP=1; return ;; esac shift + ;; + esac done } -- 2.34.1 From d+busybox at adaptive-enterprises.com Thu May 11 14:05:50 2023 From: d+busybox at adaptive-enterprises.com (David Leonard) Date: Fri, 12 May 2023 00:05:50 +1000 (AEST) Subject: [PATCH 2/2] od: add tests In-Reply-To: <1p80p08o-9o66-n1rr-7q57-8ps22q2071@nqncgvir-ragrecevfrf.pbz> References: <1p80p08o-9o66-n1rr-7q57-8ps22q2071@nqncgvir-ragrecevfrf.pbz> Message-ID: <529927s-30q2-ss7-5pq9-q93418n95098@nqncgvir-ragrecevfrf.pbz> On Fri, 12 May 2023, David Leonard wrote: > * Added tests for od (non-DESKTOP little-endian) > * Allow 'optional' to invert meaning of a config option with '!' Hmm, that patch seems to have been a bit mangled in transit. Attaching. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-od-add-tests.patch Type: text/x-diff Size: 5193 bytes Desc: 0002-od-add-tests.patch URL: From oliver+busybox at schinagl.nl Fri May 12 08:35:22 2023 From: oliver+busybox at schinagl.nl (Olliver Schinagl) Date: Fri, 12 May 2023 10:35:22 +0200 Subject: [PATCH] Extend I2C tools to read unlimited lengths Message-ID: <20230512083525.3164148-1-oliver+busybox@schinagl.nl> The I2C tools suggest they can do block read/writes using either 's'(mbus) or 'i'(2c) access. However the current code limits reads specifically to a single block, which depending on the driver, may limit this to even less bytes. Looking closer, we actually see that the commands to read via either access is really the same, where the only difference is, that SMBus access can at most read 32 bytes (but can read less) but cannot be told to read less, and I2C access can read up to 1 byte granularity. Everything else works the same, and thus the loop to read multiple bytes works for both cases equally well. This change thus also reduces the code a tiny bit, but makes it more readable at the least. Further more, while here, a little bit of cleanup. One cosmetic and one where instead of always returning -1 (which is horrible to debug when your console just tells you this) instead returns errno that ioctl had already set for us anyway. From oliver+busybox at schinagl.nl Fri May 12 08:35:23 2023 From: oliver+busybox at schinagl.nl (Olliver Schinagl) Date: Fri, 12 May 2023 10:35:23 +0200 Subject: [PATCH 1/3] i2c_tools: cosmetic: Avoid hardcoded values In-Reply-To: <20230512083525.3164148-1-oliver+busybox@schinagl.nl> References: <20230512083525.3164148-1-oliver+busybox@schinagl.nl> Message-ID: <20230512083525.3164148-2-oliver+busybox@schinagl.nl> From: Olliver Schinagl There is a define that indicates the needed value properly, so we should use that. Signed-off-by: Olliver Schinagl --- miscutils/i2c_tools.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/miscutils/i2c_tools.c b/miscutils/i2c_tools.c index da26f5e19..3a7df3b1e 100644 --- a/miscutils/i2c_tools.c +++ b/miscutils/i2c_tools.c @@ -252,7 +252,7 @@ static int32_t i2c_smbus_read_i2c_block_data(int fd, uint8_t cmd, data.block[0] = len; err = i2c_smbus_access(fd, I2C_SMBUS_READ, cmd, - len == 32 ? I2C_SMBUS_I2C_BLOCK_BROKEN : + len == I2C_SMBUS_BLOCK_MAX ? I2C_SMBUS_I2C_BLOCK_BROKEN : I2C_SMBUS_I2C_BLOCK_DATA, &data); if (err < 0) return err; -- 2.40.1 From oliver+busybox at schinagl.nl Fri May 12 08:35:25 2023 From: oliver+busybox at schinagl.nl (Olliver Schinagl) Date: Fri, 12 May 2023 10:35:25 +0200 Subject: [PATCH 3/3] i2c_tools: Read all data in both block reads In-Reply-To: <20230512083525.3164148-1-oliver+busybox@schinagl.nl> References: <20230512083525.3164148-1-oliver+busybox@schinagl.nl> Message-ID: <20230512083525.3164148-4-oliver+busybox@schinagl.nl> From: Olliver Schinagl The difference between I2C_SMBUS_BLOCK_DATA and I2C_SMBUS_I2C_BLOCK_DATA is that one takes as an argument, the number of bytes to read, whereas the other has an (internal) fixed block size. Both however are expected to return the number of bytes read into the buffer, as both functions do `return data.block[0];`. As such, there is nothing preventing us from using the same logic for both calls. Signed-off-by: Olliver Schinagl --- miscutils/i2c_tools.c | 47 ++++++++++++++++++------------------------- 1 file changed, 20 insertions(+), 27 deletions(-) diff --git a/miscutils/i2c_tools.c b/miscutils/i2c_tools.c index 166c9f6bb..135bd7d7d 100644 --- a/miscutils/i2c_tools.c +++ b/miscutils/i2c_tools.c @@ -768,35 +768,26 @@ int i2cset_main(int argc, char **argv) static int read_block_data(int buf_fd, int mode, int *block) { uint8_t cblock[I2C_SMBUS_BLOCK_MAX + I2CDUMP_NUM_REGS]; - int res, blen = 0, tmp, i; + int res, blen = 0; + + for (res = 0; res < I2CDUMP_NUM_REGS; res += blen) { + if (mode == I2C_SMBUS_I2C_BLOCK_DATA) + blen = i2c_smbus_read_i2c_block_data(buf_fd, res, + I2C_SMBUS_BLOCK_MAX, + cblock + res); + + if (mode == I2C_SMBUS_BLOCK_DATA) + blen = i2c_smbus_read_block_data(buf_fd, res, + cblock + res); - if (mode == I2C_SMBUS_BLOCK_DATA) { - blen = i2c_smbus_read_block_data(buf_fd, 0, cblock); if (blen <= 0) goto fail; - } else { - for (res = 0; res < I2CDUMP_NUM_REGS; res += tmp) { - tmp = i2c_smbus_read_i2c_block_data( - buf_fd, res, I2C_SMBUS_BLOCK_MAX, - cblock + res); - if (tmp <= 0) { - blen = tmp; - goto fail; - } - } - - if (res >= I2CDUMP_NUM_REGS) - res = I2CDUMP_NUM_REGS; - - for (i = 0; i < res; i++) - block[i] = cblock[i]; - - if (mode != I2C_SMBUS_BLOCK_DATA) - for (i = res; i < I2CDUMP_NUM_REGS; i++) - block[i] = -1; } - return blen; + for (int i = 0; i < ((res >= I2CDUMP_NUM_REGS) ? I2CDUMP_NUM_REGS : res); i++) + block[i] = cblock[i]; + + return res; fail: bb_error_msg_and_die("block read failed: %d", blen); @@ -812,7 +803,8 @@ static void dump_data(int bus_fd, int mode, unsigned first, " 0123456789abcdef"); for (i = 0; i < I2CDUMP_NUM_REGS; i += 0x10) { - if (mode == I2C_SMBUS_BLOCK_DATA && i >= blen) + if ((mode == I2C_SMBUS_BLOCK_DATA || mode == I2C_SMBUS_I2C_BLOCK_DATA) && + i >= blen) break; if (i/16 < first/16) continue; @@ -855,7 +847,7 @@ static void dump_data(int bus_fd, int mode, unsigned first, res = block[i+j]; } - if (mode == I2C_SMBUS_BLOCK_DATA && + if ((mode == I2C_SMBUS_BLOCK_DATA || mode == I2C_SMBUS_I2C_BLOCK_DATA) && i+j >= blen) { printf(" "); } else if (res < 0) { @@ -874,7 +866,8 @@ static void dump_data(int bus_fd, int mode, unsigned first, printf(" "); for (j = 0; j < 16; j++) { - if (mode == I2C_SMBUS_BLOCK_DATA && i+j >= blen) + if ((mode == I2C_SMBUS_BLOCK_DATA || mode == I2C_SMBUS_I2C_BLOCK_DATA) && + i+j >= blen) break; /* Skip unwanted registers */ if (i+j < first || i+j > last) { -- 2.40.1 From oliver+busybox at schinagl.nl Fri May 12 08:35:24 2023 From: oliver+busybox at schinagl.nl (Olliver Schinagl) Date: Fri, 12 May 2023 10:35:24 +0200 Subject: [PATCH 2/3] i2c_tools: Return proper errno from ioctl In-Reply-To: <20230512083525.3164148-1-oliver+busybox@schinagl.nl> References: <20230512083525.3164148-1-oliver+busybox@schinagl.nl> Message-ID: <20230512083525.3164148-3-oliver+busybox@schinagl.nl> From: Olliver Schinagl We shouldn't return -1 (the default error code for the ioctl) but instead return errno. Our big brother does the same, so we should follow suit. Signed-off-by: Olliver Schinagl --- miscutils/i2c_tools.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/miscutils/i2c_tools.c b/miscutils/i2c_tools.c index 3a7df3b1e..166c9f6bb 100644 --- a/miscutils/i2c_tools.c +++ b/miscutils/i2c_tools.c @@ -117,7 +117,10 @@ static int32_t i2c_smbus_access(int fd, char read_write, uint8_t cmd, args.size = size; args.data = data; - return ioctl(fd, I2C_SMBUS, &args); + if (ioctl(fd, I2C_SMBUS, &args)) + return -errno; + + return 0; } #if ENABLE_I2CGET || ENABLE_I2CSET || ENABLE_I2CDUMP || ENABLE_I2CDETECT -- 2.40.1 From nero at w1r3.net Sat May 13 13:27:13 2023 From: nero at w1r3.net (Nero) Date: Sat, 13 May 2023 13:27:13 +0000 Subject: coreutils/install cannot set setuid bits Message-ID: Hello, I'm using the BusyBox v1.35.0 shipped with Alpine Linux 3.17. I'm trying to use coreutils/install to install a program with setuid bit set, but the setuid bit ends up being stripped. strace on the `install` invocation: > chmod("/home/nero/.local/bin/brightness", 04111) = 0 > lchown("/home/nero/.local/bin/brightness", 0, 0) = 0 Destination access rights observed with: > $ stat -c %a /home/nero/.local/bin/brightness > 111 in coreutils/install.c, in install_main(), chmod is done first, lchown afterwards. But from Linux's chown(2): > When the owner or group of an executable file is changed by an > unprivileged user, the S_ISUID and S_ISGID mode bits are cleared. > POSIX does not specify whether this also should happen when root does > the chown(); the Linux behavior depends on the kernel version, and > since Linux 2.2.13, root is treated like other users. I checked against GNU coreutils 9.1, strace: > fchownat(3, "brightness", 0, 0, AT_SYMLINK_NOFOLLOW) = 0 > fchmodat(3, "brightness", 04111) = 0 Yields the expected result: > stat -c %a /home/nero/.local/bin/brightness > 4111 I think swapping the ordering of the chmod and lchown sections in coreutils/install.c, install_main() would fix what i think is a bug. Ideas? -- Nero From ksperling at apple.com Mon May 15 05:25:17 2023 From: ksperling at apple.com (Karsten Sperling) Date: Mon, 15 May 2023 17:25:17 +1200 Subject: [PATCH] ash: use-after-free in bash pattern substitution (resubmit) In-Reply-To: <186950C9-64AC-43EA-B038-0097DB70AE08@apple.com> References: <186950C9-64AC-43EA-B038-0097DB70AE08@apple.com> Message-ID: <188A4A4C-A44C-4A53-B24E-648AB3F1A47E@apple.com> Hi, just bumping this thread one last time. Please let me know if there is some contribution guideline I?m not following correctly, or if there is some other reason for not accepting this patch. Cheers, Karsten > On 18/04/2023, at 3:24 PM, Karsten Sperling wrote: > > Commit daa66ed6 fixed a number of use-after-free bugs in bash pattern substitution, however one "unguarded" STPUTC remained, which is fixed here. > > Signed-off-by: Karsten Sperling > --- > shell/ash.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/shell/ash.c b/shell/ash.c > index d2c5c5d50..51b627fcc 100644 > --- a/shell/ash.c > +++ b/shell/ash.c > @@ -7370,6 +7370,8 @@ subevalvar(char *start, char *str, int strloc, > char *restart_detect = stackblock(); > if (quotes && *loc == '\\') { > STPUTC(CTLESC, expdest); > + if (stackblock() != restart_detect) > + goto restart; > len++; > } > STPUTC(*loc, expdest); > -- 2.39.0 > From vda.linux at googlemail.com Thu May 18 14:50:16 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 18 May 2023 16:50:16 +0200 Subject: [PATCH] ash: use-after-free in bash pattern substitution (resubmit) In-Reply-To: <188A4A4C-A44C-4A53-B24E-648AB3F1A47E@apple.com> References: <186950C9-64AC-43EA-B038-0097DB70AE08@apple.com> <188A4A4C-A44C-4A53-B24E-648AB3F1A47E@apple.com> Message-ID: Applied, thank you. On Mon, May 15, 2023 at 7:26?AM Karsten Sperling wrote: > > Hi, just bumping this thread one last time. > > Please let me know if there is some contribution guideline I?m not following correctly, or if there is some other reason for not accepting this patch. > > Cheers, Karsten > > > > On 18/04/2023, at 3:24 PM, Karsten Sperling wrote: > > > > Commit daa66ed6 fixed a number of use-after-free bugs in bash pattern substitution, however one "unguarded" STPUTC remained, which is fixed here. > > > > Signed-off-by: Karsten Sperling > > --- > > shell/ash.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/shell/ash.c b/shell/ash.c > > index d2c5c5d50..51b627fcc 100644 > > --- a/shell/ash.c > > +++ b/shell/ash.c > > @@ -7370,6 +7370,8 @@ subevalvar(char *start, char *str, int strloc, > > char *restart_detect = stackblock(); > > if (quotes && *loc == '\\') { > > STPUTC(CTLESC, expdest); > > + if (stackblock() != restart_detect) > > + goto restart; > > len++; > > } > > STPUTC(*loc, expdest); > > -- 2.39.0 > > > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From vsfos at qq.com Fri May 19 07:07:05 2023 From: vsfos at qq.com (=?ISO-8859-1?B?dnNmb3M=?=) Date: Fri, 19 May 2023 15:07:05 +0800 Subject: Suspicious BUG in hush, while 'elif' has more commands than 1, only the first command is executed Message-ID: Tested on wsl ubuntu 22.04 and linux orangepi5 by executing scripts below: #!/bin/sh if false; then     : nothing elif echo 'test-1'; echo 'test-2' ; echo 'test-3'; then     echo "abcdefg-1" fi echo again if echo 'test-1'; echo 'test-2' ; echo 'test-3'; then     echo "abcdefg-1" fi Output will be like below on hush: test-1 again test-1 test-2 test-3 abcdefg-1 On bash, output will be test-1 test-2 test-3 abcdefg-1 again test-1 test-2 test-3 abcdefg-1 exec log: parse_and_run_stream: run_and_free_list run_and_free_list entered : run_list: 1st pipe with 1 cmds run_list start lvl 0   : rword=0 cond_code=0 last_rword=17   : run_pipe with 1 members   run_pipe start: members:1     : group:0 argv:'./test'     : pipe member './test' '  run_pipe return -1 (1 children started)   execing './test' parse_and_run_stream: run_and_free_list run_and_free_list entered : run_list: 1st pipe with 0 cmds run_list start lvl 0   : rword=0 cond_code=0 last_rword=17 run_list lvl 1 return 0 run_and_free_list return 0 parse_and_run_stream: run_and_free_list run_and_free_list entered : run_list: 1st pipe with 1 cmds run_list start lvl 0   : rword=0 cond_code=0 last_rword=17   : run_pipe with 1 members   run_pipe start: members:1     : group:71a768 argv:'NONE'     non-subshell group     : run_list     run_list start lvl 1       : rword=1 cond_code=0 last_rword=17       : run_pipe with 1 members       run_pipe start: members:1         : group:0 argv:'false'         : pipe member 'false' '      run_pipe return -1 (1 children started)       execing 'false'       : checkjobs exitcode 255       : rword=2 cond_code=255 last_rword=1       : rword=3 cond_code=255 last_rword=2       : run_pipe with 1 members       run_pipe start: members:1         : group:0 argv:'echo'         found builtin 'echo'         : builtin 'echo' 'test-1'... test-1       run_pipe return 0       : builtin/func exitcode 0       : rword=3 cond_code=0 last_rword=3     run_list lvl 2 return 0   run_pipe: return 0   : builtin/func exitcode 0   : rword=0 cond_code=0 last_rword=0 run_list lvl 1 return 0 run_and_free_list return 0 parse_and_run_stream: run_and_free_list run_and_free_list entered : run_list: 1st pipe with 1 cmds run_list start lvl 0   : rword=0 cond_code=0 last_rword=17   : run_pipe with 1 members   run_pipe start: members:1     : group:0 argv:'echo'     found builtin 'echo'     : builtin 'echo' 'again'... again   run_pipe return 0   : builtin/func exitcode 0   : rword=0 cond_code=0 last_rword=0 run_list lvl 1 return 0 run_and_free_list return 0 parse_and_run_stream: run_and_free_list run_and_free_list entered : run_list: 1st pipe with 1 cmds run_list start lvl 0   : rword=0 cond_code=0 last_rword=17   : run_pipe with 1 members   run_pipe start: members:1     : group:71a768 argv:'NONE'     non-subshell group     : run_list     run_list start lvl 1       : rword=1 cond_code=0 last_rword=17       : run_pipe with 1 members       run_pipe start: members:1         : group:0 argv:'echo'         found builtin 'echo'         : builtin 'echo' 'test-1'... test-1       run_pipe return 0       : builtin/func exitcode 0       : rword=1 cond_code=0 last_rword=1       : run_pipe with 1 members       run_pipe start: members:1         : group:0 argv:'echo'         found builtin 'echo'         : builtin 'echo' 'test-2'... test-2       run_pipe return 0       : builtin/func exitcode 0       : rword=1 cond_code=0 last_rword=1       : run_pipe with 1 members       run_pipe start: members:1         : group:0 argv:'echo'         found builtin 'echo'         : builtin 'echo' 'test-3'... test-3       run_pipe return 0       : builtin/func exitcode 0       : rword=2 cond_code=0 last_rword=1       : run_pipe with 1 members       run_pipe start: members:1         : group:0 argv:'echo'         found builtin 'echo'         : builtin 'echo' 'abcdefg-1'... abcdefg-1       run_pipe return 0       : builtin/func exitcode 0       : rword=5 cond_code=0 last_rword=2       : rword=0 cond_code=0 last_rword=5     run_list lvl 2 return 0   run_pipe: return 0   : builtin/func exitcode 0   : rword=0 cond_code=0 last_rword=0 run_list lvl 1 return 0 run_and_free_list return 0   : checkjobs_and_fg_shell exitcode 0   : rword=0 cond_code=0 last_rword=0 run_list lvl 1 return 0 run_and_free_list return 0 From the log, after the echo 'test-1' command, elif exited. The exit point is at here in run_list function: #if ENABLE_HUSH_IF if (cond_code) { if (rword == RES_THEN) { /* if false; then ... fi has exitcode 0! */ G.last_exitcode = rcode = EXIT_SUCCESS; /* "if From dario.binacchi at amarulasolutions.com Sun May 21 18:48:05 2023 From: dario.binacchi at amarulasolutions.com (Dario Binacchi) Date: Sun, 21 May 2023 20:48:05 +0200 Subject: [RFC PATCH] ip link: support for the CAN netlink In-Reply-To: <32AAD054-5011-4D19-BFC9-3197DA2CA0E8@gmail.com> References: <20230420193533.1963524-1-dario.binacchi@amarulasolutions.com> <32AAD054-5011-4D19-BFC9-3197DA2CA0E8@gmail.com> Message-ID: Hi all, On Sat, May 6, 2023 at 11:40?PM Bernhard Reutner-Fischer wrote: > > On 30 April 2023 11:52:26 CEST, Dario Binacchi wrote: > >Hi Nikolaus, > > > >On Thu, Apr 27, 2023 at 11:28?AM Nikolaus Voss wrote: > >> > >> Hi Dario, > >> > >> I posted a more minimalistic approach > > > >This is the reason why I added the CONFIG_IPLINK_CAN option. > > >Anyway, I think we both agree that busybox lacks a CAN-type management > >for the 'ip link' command > > Yes. So did anybody review the bigger patch? Not yet. In the meantime, my patches for MMU-less systems have been accepted in the following projects: can-utils: https://github.com/linux-can/can-utils/commit/5ed3b4ded6cf3e4de6fc8c8739b84231b0285b0e libmnl: https://git.netfilter.org/libmnl/commit/?id=80442c4e32cde0b27b471c5c9688ee8488f14bec buildroot: https://git.busybox.net/buildroot/commit/?id=edb184fe46d3406add0cecae0dc0e4be52dff79c https://git.busybox.net/buildroot/commit/?id=77314408813186716ef3cb73d65da13705842e41 This demonstrates that there was a need to address some gaps for MMU-less systems. I hope that BusyBox also fills this gap. Thanks and regards, Dario -- Dario Binacchi Senior Embedded Linux Developer dario.binacchi at amarulasolutions.com __________________________________ Amarula Solutions SRL Via Le Canevare 30, 31100 Treviso, Veneto, IT T. +39 042 243 5310 info at amarulasolutions.com www.amarulasolutions.com From vda.linux at googlemail.com Thu May 25 12:39:45 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 25 May 2023 14:39:45 +0200 Subject: Suspicious BUG in hush, while 'elif' has more commands than 1, only the first command is executed In-Reply-To: References: Message-ID: Thanks for the report. Fixed in git. On Fri, May 19, 2023 at 9:07?AM vsfos wrote: > > Tested on wsl ubuntu 22.04 and linux orangepi5 by executing scripts below: > > #!/bin/sh > if false; then > : nothing > elif echo 'test-1'; echo 'test-2' ; echo 'test-3'; then > echo "abcdefg-1" > fi > echo again > if echo 'test-1'; echo 'test-2' ; echo 'test-3'; then > echo "abcdefg-1" > fi > > Output will be like below on hush: > test-1 > again > test-1 > test-2 > test-3 > abcdefg-1 > > On bash, output will be > test-1 > test-2 > test-3 > abcdefg-1 > again > test-1 > test-2 > test-3 > abcdefg-1 > > exec log: > parse_and_run_stream: run_and_free_list > run_and_free_list entered > : run_list: 1st pipe with 1 cmds > run_list start lvl 0 > : rword=0 cond_code=0 last_rword=17 > : run_pipe with 1 members > run_pipe start: members:1 > : group:0 argv:'./test' > : pipe member './test' ' run_pipe return -1 (1 children started) > execing './test' > parse_and_run_stream: run_and_free_list > run_and_free_list entered > : run_list: 1st pipe with 0 cmds > run_list start lvl 0 > : rword=0 cond_code=0 last_rword=17 > run_list lvl 1 return 0 > run_and_free_list return 0 > parse_and_run_stream: run_and_free_list > run_and_free_list entered > : run_list: 1st pipe with 1 cmds > run_list start lvl 0 > : rword=0 cond_code=0 last_rword=17 > : run_pipe with 1 members > run_pipe start: members:1 > : group:71a768 argv:'NONE' > non-subshell group > : run_list > run_list start lvl 1 > : rword=1 cond_code=0 last_rword=17 > : run_pipe with 1 members > run_pipe start: members:1 > : group:0 argv:'false' > : pipe member 'false' ' run_pipe return -1 (1 children started) > execing 'false' > : checkjobs exitcode 255 > : rword=2 cond_code=255 last_rword=1 > : rword=3 cond_code=255 last_rword=2 > : run_pipe with 1 members > run_pipe start: members:1 > : group:0 argv:'echo' > found builtin 'echo' > : builtin 'echo' 'test-1'... > test-1 > run_pipe return 0 > : builtin/func exitcode 0 > : rword=3 cond_code=0 last_rword=3 > run_list lvl 2 return 0 > run_pipe: return 0 > : builtin/func exitcode 0 > : rword=0 cond_code=0 last_rword=0 > run_list lvl 1 return 0 > run_and_free_list return 0 > parse_and_run_stream: run_and_free_list > run_and_free_list entered > : run_list: 1st pipe with 1 cmds > run_list start lvl 0 > : rword=0 cond_code=0 last_rword=17 > : run_pipe with 1 members > run_pipe start: members:1 > : group:0 argv:'echo' > found builtin 'echo' > : builtin 'echo' 'again'... > again > run_pipe return 0 > : builtin/func exitcode 0 > : rword=0 cond_code=0 last_rword=0 > run_list lvl 1 return 0 > run_and_free_list return 0 > parse_and_run_stream: run_and_free_list > run_and_free_list entered > : run_list: 1st pipe with 1 cmds > run_list start lvl 0 > : rword=0 cond_code=0 last_rword=17 > : run_pipe with 1 members > run_pipe start: members:1 > : group:71a768 argv:'NONE' > non-subshell group > : run_list > run_list start lvl 1 > : rword=1 cond_code=0 last_rword=17 > : run_pipe with 1 members > run_pipe start: members:1 > : group:0 argv:'echo' > found builtin 'echo' > : builtin 'echo' 'test-1'... > test-1 > run_pipe return 0 > : builtin/func exitcode 0 > : rword=1 cond_code=0 last_rword=1 > : run_pipe with 1 members > run_pipe start: members:1 > : group:0 argv:'echo' > found builtin 'echo' > : builtin 'echo' 'test-2'... > test-2 > run_pipe return 0 > : builtin/func exitcode 0 > : rword=1 cond_code=0 last_rword=1 > : run_pipe with 1 members > run_pipe start: members:1 > : group:0 argv:'echo' > found builtin 'echo' > : builtin 'echo' 'test-3'... > test-3 > run_pipe return 0 > : builtin/func exitcode 0 > : rword=2 cond_code=0 last_rword=1 > : run_pipe with 1 members > run_pipe start: members:1 > : group:0 argv:'echo' > found builtin 'echo' > : builtin 'echo' 'abcdefg-1'... > abcdefg-1 > run_pipe return 0 > : builtin/func exitcode 0 > : rword=5 cond_code=0 last_rword=2 > : rword=0 cond_code=0 last_rword=5 > run_list lvl 2 return 0 > run_pipe: return 0 > : builtin/func exitcode 0 > : rword=0 cond_code=0 last_rword=0 > run_list lvl 1 return 0 > run_and_free_list return 0 > : checkjobs_and_fg_shell exitcode 0 > : rword=0 cond_code=0 last_rword=0 > run_list lvl 1 return 0 > run_and_free_list return 0 > > From the log, after the echo 'test-1' command, elif exited. > The exit point is at here in run_list function: > #if ENABLE_HUSH_IF > if (cond_code) { > if (rword == RES_THEN) { > /* if false; then ... fi has exitcode 0! */ > G.last_exitcode = rcode = EXIT_SUCCESS; > /* "if THEN cmd": skip cmd */ > continue; > } > } else { > if (rword == RES_ELSE || rword == RES_ELIF) { > /* "if then ... ELSE/ELIF cmd": > * skip cmd and all following ones */ > break; // <<<<---- here > } > } > #endif > Because echo returns 0, and current rword is elif. > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From vda.linux at googlemail.com Thu May 25 13:33:10 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 25 May 2023 15:33:10 +0200 Subject: [PATCH 2/2] od: add tests In-Reply-To: <529927s-30q2-ss7-5pq9-q93418n95098@nqncgvir-ragrecevfrf.pbz> References: <1p80p08o-9o66-n1rr-7q57-8ps22q2071@nqncgvir-ragrecevfrf.pbz> <529927s-30q2-ss7-5pq9-q93418n95098@nqncgvir-ragrecevfrf.pbz> Message-ID: Applied, thank you On Thu, May 11, 2023 at 4:06?PM David Leonard wrote: > > On Fri, 12 May 2023, David Leonard wrote: > > * Added tests for od (non-DESKTOP little-endian) > > * Allow 'optional' to invert meaning of a config option with '!' > > Hmm, that patch seems to have been a bit mangled in transit. Attaching. > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From reimu at sudomaker.com Thu May 25 14:03:58 2023 From: reimu at sudomaker.com (Reimu) Date: Thu, 25 May 2023 22:03:58 +0800 Subject: [PATCH] mount: add option to disable NFS completely Message-ID: This can save up to ~40 kbytes with uclibc and it helps a lot when you're building a very tiny busybox for embedded systems. --- ?util-linux/mount.c | 14 +++++++++++++- ?1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/util-linux/mount.c b/util-linux/mount.c index 4e65b6b46..1c3e2bf64 100644 --- a/util-linux/mount.c +++ b/util-linux/mount.c @@ -77,6 +77,17 @@ ?//config:?? ?Note that this option links in RPC support from libc, ?//config:?? ?which is rather large (~10 kbytes on uclibc). ?//config: +//config:config FEATURE_MOUNT_NFS_ALL +//config:?? ?bool "Support mounting NFS file systems on Linux >= 2.6.23" +//config:?? ?default y +//config:?? ?depends on MOUNT +//config:?? ?help +//config:?? ?Enable mounting of NFS file systems on Linux kernels with +//config:?? ?at least version 2.6.23. +//config: +//config:?? ?Disabling this option can save up to ~40 kbytes with uclibc +//config:?? ?if you have nothing else that requires getnameinfo(). +//config: ?//config:config FEATURE_MOUNT_CIFS ?//config:?? ?bool "Support mounting CIFS/SMB file systems" ?//config:?? ?default y @@ -2089,7 +2100,8 @@ static int singlemount(struct mntent *mp, int ignore_busy) ??? ?} ? ??? ?// Might this be an NFS filesystem? -?? ?if (!(vfsflags & (MS_BIND | MS_MOVE)) +?? ?if (ENABLE_FEATURE_MOUNT_NFS_ALL +?? ? && !(vfsflags & (MS_BIND | MS_MOVE)) ??? ? && (!mp->mnt_type || is_prefixed_with(mp->mnt_type, "nfs")) ??? ?) { ??? ??? ?char *colon = strchr(mp->mnt_fsname, ':'); -- 2.25.1 From David.Laight at ACULAB.COM Thu May 25 14:17:17 2023 From: David.Laight at ACULAB.COM (David Laight) Date: Thu, 25 May 2023 14:17:17 +0000 Subject: [PATCH] mount: add option to disable NFS completely In-Reply-To: References: Message-ID: From: Reimu > Sent: 25 May 2023 15:04 > > This can save up to ~40 kbytes with uclibc and it helps a lot when > you're building a very tiny busybox for embedded systems. > --- > ?util-linux/mount.c | 14 +++++++++++++- > ?1 file changed, 13 insertions(+), 1 deletion(-) > > diff --git a/util-linux/mount.c b/util-linux/mount.c > index 4e65b6b46..1c3e2bf64 100644 > --- a/util-linux/mount.c > +++ b/util-linux/mount.c > @@ -77,6 +77,17 @@ > ?//config:?? ?Note that this option links in RPC support from libc, > ?//config:?? ?which is rather large (~10 kbytes on uclibc). > ?//config: > +//config:config FEATURE_MOUNT_NFS_ALL > +//config:?? ?bool "Support mounting NFS file systems on Linux >= 2.6.23" > +//config:?? ?default y > +//config:?? ?depends on MOUNT > +//config:?? ?help > +//config:?? ?Enable mounting of NFS file systems on Linux kernels with > +//config:?? ?at least version 2.6.23. I don't think you need to reference the Linux kernel version. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From reimu at sudomaker.com Thu May 25 14:47:45 2023 From: reimu at sudomaker.com (Reimu) Date: Thu, 25 May 2023 22:47:45 +0800 Subject: [PATCH] mount: add option to disable NFS completely In-Reply-To: References: Message-ID: <91156831-3cd5-d4dd-8cc3-fa573e6f8e64@sudomaker.com> On 2023/5/25 22:17, David Laight wrote: > From: Reimu >> Sent: 25 May 2023 15:04 >> >> This can save up to ~40 kbytes with uclibc and it helps a lot when >> you're building a very tiny busybox for embedded systems. >> --- >> ?util-linux/mount.c | 14 +++++++++++++- >> ?1 file changed, 13 insertions(+), 1 deletion(-) >> >> diff --git a/util-linux/mount.c b/util-linux/mount.c >> index 4e65b6b46..1c3e2bf64 100644 >> --- a/util-linux/mount.c >> +++ b/util-linux/mount.c >> @@ -77,6 +77,17 @@ >> ?//config:?? ?Note that this option links in RPC support from libc, >> ?//config:?? ?which is rather large (~10 kbytes on uclibc). >> ?//config: >> +//config:config FEATURE_MOUNT_NFS_ALL >> +//config:?? ?bool "Support mounting NFS file systems on Linux >= 2.6.23" >> +//config:?? ?default y >> +//config:?? ?depends on MOUNT >> +//config:?? ?help >> +//config:?? ?Enable mounting of NFS file systems on Linux kernels with >> +//config:?? ?at least version 2.6.23. > I don't think you need to reference the Linux kernel version. > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) I only did this bc there's an existing option called FEATURE_MOUNT_NFS and it mentioned the Linux kernel version and I want to make as few changes as possible. The best option would obviously be renaming the existing FEATURE_MOUNT_NFS to something like FEATURE_MOUNT_NFS_LEGACY and make FEATURE_MOUNT_NFS a main switch. What's your opinion? From hi at alyssa.is Sat May 27 12:02:50 2023 From: hi at alyssa.is (Alyssa Ross) Date: Sat, 27 May 2023 12:02:50 +0000 Subject: [PATCH] volume_id: volume_id_get_buffer with small FSes Message-ID: <20230527120249.826781-1-hi@alyssa.is> I was working with some very small ext4 filesystems, used for overlaying on immutable VM/container images. If it's only desired to overlay a single config file, these filesystems can be very small indeed, and so ran afoul of this length check. I tested both the cases mentioned in the comments ? an empty floppy drive, and an unused loop device. Reading from an empty floppy drive is ENXIO, and reading from an unused loop device returns 0, so it should be fine to drop the minimum length, and be happy with any read as long as it returns at least one byte. By initializing read_len to -1, we can handle both lseek() failing and read_full() failing with the same check. --- v1: http://lists.busybox.net/pipermail/busybox/2022-May/089740.html Only change since v1 is updating the commit message to note that floppies don't even take this code path any more. util-linux/volume_id/util.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/util-linux/volume_id/util.c b/util-linux/volume_id/util.c index 061545fde..a5844c673 100644 --- a/util-linux/volume_id/util.c +++ b/util-linux/volume_id/util.c @@ -180,7 +180,7 @@ void *volume_id_get_buffer(struct volume_id *id, uint64_t off, size_t len) { uint8_t *dst; unsigned small_off; - ssize_t read_len; + ssize_t read_len = -1; dbg("get buffer off 0x%llx(%llu), len 0x%zx", (unsigned long long) off, (unsigned long long) off, len); @@ -237,13 +237,7 @@ void *volume_id_get_buffer(struct volume_id *id, uint64_t off, size_t len) dbg("requested 0x%x bytes, got 0x%x bytes", (unsigned) len, (unsigned) read_len); err: - /* No filesystem can be this tiny. It's most likely - * non-associated loop device, empty drive and so on. - * Flag it, making it possible to short circuit future - * accesses. Rationale: - * users complained of slow blkid due to empty floppy drives. - */ - if (off < 64*1024) + if (read_len <= 0) id->error = 1; /* id->seekbuf_len or id->sbbuf_len is wrong now! Fixing. */ volume_id_free_buffer(id); base-commit: 6d9427420bab4ef756444fc8800dbf56d7dacf7d -- 2.37.1 From hi at alyssa.is Sat May 27 14:47:26 2023 From: hi at alyssa.is (Alyssa Ross) Date: Sat, 27 May 2023 14:47:26 +0000 Subject: [PATCH v3] volume_id: volume_id_get_buffer with small FSes Message-ID: <20230527144725.1967641-1-hi@alyssa.is> I was working with some very small ext4 filesystems, used for overlaying on immutable VM/container images. If it's only desired to overlay a single config file, these filesystems can be very small indeed, and so ran afoul of this length check. Since 4fc5ec56f ("device matching against UUIDs: do not try floppies") (from 2009), floppy drives are skipped before this function is even called. Reading from an unused loop device returns 0, so it should be fine to drop the minimum length, and be happy with any read as long as it returns at least one byte. By initializing read_len to -1, we can handle both lseek() failing and read_full() failing with the same check. --- v2: http://lists.busybox.net/pipermail/busybox/2023-May/090340.html My previous submission omitted the version number in the subject line, and didn't actually include the updated commit message I referred to in the changelog; apologies. util-linux/volume_id/util.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/util-linux/volume_id/util.c b/util-linux/volume_id/util.c index 061545fde..a5844c673 100644 --- a/util-linux/volume_id/util.c +++ b/util-linux/volume_id/util.c @@ -180,7 +180,7 @@ void *volume_id_get_buffer(struct volume_id *id, uint64_t off, size_t len) { uint8_t *dst; unsigned small_off; - ssize_t read_len; + ssize_t read_len = -1; dbg("get buffer off 0x%llx(%llu), len 0x%zx", (unsigned long long) off, (unsigned long long) off, len); @@ -237,13 +237,7 @@ void *volume_id_get_buffer(struct volume_id *id, uint64_t off, size_t len) dbg("requested 0x%x bytes, got 0x%x bytes", (unsigned) len, (unsigned) read_len); err: - /* No filesystem can be this tiny. It's most likely - * non-associated loop device, empty drive and so on. - * Flag it, making it possible to short circuit future - * accesses. Rationale: - * users complained of slow blkid due to empty floppy drives. - */ - if (off < 64*1024) + if (read_len <= 0) id->error = 1; /* id->seekbuf_len or id->sbbuf_len is wrong now! Fixing. */ volume_id_free_buffer(id); base-commit: 6d9427420bab4ef756444fc8800dbf56d7dacf7d -- 2.37.1 From lineprinter0 at gmail.com Sun May 28 17:01:52 2023 From: lineprinter0 at gmail.com (Elvira Khabirova) Date: Sun, 28 May 2023 19:01:52 +0200 Subject: [PATCH] libbb: in xmalloc_fgetline, use getline if enabled Message-ID: <20230528170152.124736-1-lineprinter0@gmail.com> When xmalloc_fgetline was introduced, getline(3) was a GNU extension and was not necessarily implemented in libcs. Since then, it's become a part of POSIX.1-2008 and is now implemented in glibc, uClibc-ng, and musl. Previously, xmalloc_fgetline directly called bb_get_chunk_from_file. The issue with that approach is that bb_get_chunk_from_file stops both at \n and at \0. This introduces unexpected behavior when tools are presented with inputs containing \0. For example, in a comparison of GNU core utils cut with busybox cut: % echo -ne '\x00\x01\x00\x03\x04\x05\x06' | cut -b1-3 | hexdump -C 00000000 00 01 00 0a |....| 00000004 % echo -ne '\x00\x01\x00\x03\x04\x05\x06' | ./busybox cut -b1-3 | hexdump -C 00000000 0a 01 0a 03 04 05 0a |.......| 00000007 Here, due to bb_get_chunk_from_file splitting lines by \n and \0, busybox cut interprets the input as three lines instead of one. Also, since xmalloc_fgetline never returned strings with embedded \0, cut_file expects strlen of the returned string to match the string's total length. To fix the behavior of the cut utility, introduce xmalloc_fgetline_n, that fully matches the behavior of xmalloc_fgetline, but also returns the amount of bytes read. Add a configuration option, FEATURE_USE_GETLINE, and enable it by default. Use getline in xmalloc_fgetline_n if the feature is enabled. Change the behavior of cut_file to use the values returned by the new function instead of calling strlen. Call xmalloc_fgetline_n from xmalloc_fgetline. Add a test for the previously mentioned case. With FEATURE_USE_GETLINE: function old new delta xmalloc_fgetline_n - 173 +173 xmalloc_fgetline 85 58 -27 cut_main 1406 1367 -39 ------------------------------------------------------------------------------ (add/remove: 1/0 grow/shrink: 0/2 up/down: 173/-66) Total: 107 bytes Without FEATURE_USE_GETLINE: function old new delta xmalloc_fgetline_n - 41 +41 xmalloc_fgetline 85 58 -27 cut_main 1406 1367 -39 ------------------------------------------------------------------------------ (add/remove: 1/0 grow/shrink: 0/2 up/down: 41/-66) Total: -25 bytes Fixes: https://bugs.busybox.net/show_bug.cgi?id=15276 Signed-off-by: Elvira Khabirova --- coreutils/cut.c | 4 ++-- include/libbb.h | 2 ++ libbb/Config.src | 11 +++++++++++ libbb/get_line_from_file.c | 37 ++++++++++++++++++++++++++++++++----- testsuite/cut.tests | 2 ++ 5 files changed, 49 insertions(+), 7 deletions(-) diff --git a/coreutils/cut.c b/coreutils/cut.c index 55bdd9386..7c87467ca 100644 --- a/coreutils/cut.c +++ b/coreutils/cut.c @@ -89,6 +89,7 @@ static void cut_file(FILE *file, const char *delim, const char *odelim, const struct cut_list *cut_lists, unsigned nlists) { char *line; + size_t linelen = 0; unsigned linenum = 0; /* keep these zero-based to be consistent */ regex_t reg; int spos, shoe = option_mask32 & CUT_OPT_REGEX_FLGS; @@ -96,10 +97,9 @@ static void cut_file(FILE *file, const char *delim, const char *odelim, if (shoe) xregcomp(®, delim, REG_EXTENDED); /* go through every line in the file */ - while ((line = xmalloc_fgetline(file)) != NULL) { + while ((line = xmalloc_fgetline_n(file, &linelen)) != NULL) { /* set up a list so we can keep track of what's been printed */ - int linelen = strlen(line); char *printed = xzalloc(linelen + 1); char *orig_line = line; unsigned cl_pos = 0; diff --git a/include/libbb.h b/include/libbb.h index 6191debb1..73d16647a 100644 --- a/include/libbb.h +++ b/include/libbb.h @@ -1048,6 +1048,8 @@ extern char *xmalloc_fgetline_str(FILE *file, const char *terminating_string) FA extern char *xmalloc_fgets(FILE *file) FAST_FUNC RETURNS_MALLOC; /* Chops off '\n' from the end, unlike fgets: */ extern char *xmalloc_fgetline(FILE *file) FAST_FUNC RETURNS_MALLOC; +/* Same as xmalloc_fgetline but returns number of bytes read: */ +extern char* xmalloc_fgetline_n(FILE *file, size_t *n) FAST_FUNC RETURNS_MALLOC; /* Same, but doesn't try to conserve space (may have some slack after the end) */ /* extern char *xmalloc_fgetline_fast(FILE *file) FAST_FUNC RETURNS_MALLOC; */ diff --git a/libbb/Config.src b/libbb/Config.src index b980f19a9..7a37929d6 100644 --- a/libbb/Config.src +++ b/libbb/Config.src @@ -147,6 +147,17 @@ config MONOTONIC_SYSCALL will be used instead (which gives wrong results if date/time is reset). +config FEATURE_USE_GETLINE + bool "Use getline library function" + default y + help + When enabled, busybox will use the libc getline() function + instead of getc loops to read data from files. + Using getline provides better behavior when utilities + encounter NUL bytes in their inputs. + getline() was originally a GNU extension, but now is a part + of POSIX.1-2008 and is implemented in contemporary libcs. + config IOCTL_HEX2STR_ERROR bool "Use ioctl names rather than hex values in error messages" default y diff --git a/libbb/get_line_from_file.c b/libbb/get_line_from_file.c index 903ff1fb6..096bbd66f 100644 --- a/libbb/get_line_from_file.c +++ b/libbb/get_line_from_file.c @@ -12,9 +12,9 @@ char* FAST_FUNC bb_get_chunk_from_file(FILE *file, size_t *end) { - int ch; - size_t idx = 0; char *linebuf = NULL; + size_t idx = 0; + int ch; while ((ch = getc(file)) != EOF) { /* grow the line buffer as necessary */ @@ -55,10 +55,37 @@ char* FAST_FUNC xmalloc_fgets(FILE *file) char* FAST_FUNC xmalloc_fgetline(FILE *file) { size_t i; - char *c = bb_get_chunk_from_file(file, &i); - if (i && c[--i] == '\n') - c[i] = '\0'; + return xmalloc_fgetline_n(file, &i); +} + +/* Get line. Remove trailing \n. Return the number of bytes read. */ +char* FAST_FUNC xmalloc_fgetline_n(FILE *file, size_t *n) +{ + char *c = NULL; +#if ENABLE_FEATURE_USE_GETLINE + size_t idx = 0; + ssize_t nread; + + nread = getline(&c, &idx, file); + if (nread < 0) { + if (errno == ENOMEM) + bb_die_memory_exhausted(); + free(c); + c = NULL; + *n = 0; + } else { + *n = nread; + } +#else + c = bb_get_chunk_from_file(file, n); +#endif + + if (*n) { + if (c[*n - 1] == '\n') { + c[--*n] = '\0'; + } + } return c; } diff --git a/testsuite/cut.tests b/testsuite/cut.tests index 2458c019c..0fd731688 100755 --- a/testsuite/cut.tests +++ b/testsuite/cut.tests @@ -81,4 +81,6 @@ SKIP= testing "cut empty field" "cut -d ':' -f 1-3" "a::b\n" "" "a::b\n" testing "cut empty field 2" "cut -d ':' -f 3-5" "b::c\n" "" "a::b::c:d\n" +testing "cut with embedded NUL" "cut -c 1-3" "\x00\x01\x00\n" "" "\x00\x01\x00\x03\x04\x05\x06" + exit $FAILCOUNT -- 2.34.1 From farmatito at tiscali.it Sun May 28 19:53:39 2023 From: farmatito at tiscali.it (tito) Date: Sun, 28 May 2023 21:53:39 +0200 Subject: [PATCH] libbb: in xmalloc_fgetline, use getline if enabled In-Reply-To: <20230528170152.124736-1-lineprinter0@gmail.com> References: <20230528170152.124736-1-lineprinter0@gmail.com> Message-ID: <20230528215339.6bd30c7c@devuan> On Sun, 28 May 2023 19:01:52 +0200 Elvira Khabirova wrote: > When xmalloc_fgetline was introduced, getline(3) was a GNU extension > and was not necessarily implemented in libcs. Since then, > it's become a part of POSIX.1-2008 and is now implemented in > glibc, uClibc-ng, and musl. > > Previously, xmalloc_fgetline directly called bb_get_chunk_from_file. > The issue with that approach is that bb_get_chunk_from_file stops > both at \n and at \0. This introduces unexpected behavior when tools > are presented with inputs containing \0. For example, in a comparison > of GNU core utils cut with busybox cut: > > % echo -ne '\x00\x01\x00\x03\x04\x05\x06' | cut -b1-3 | hexdump -C > 00000000 00 01 00 0a |....| > 00000004 > % echo -ne '\x00\x01\x00\x03\x04\x05\x06' | ./busybox cut -b1-3 | hexdump -C > 00000000 0a 01 0a 03 04 05 0a |.......| > 00000007 > > Here, due to bb_get_chunk_from_file splitting lines by \n and \0, > busybox cut interprets the input as three lines instead of one. > > Also, since xmalloc_fgetline never returned strings with embedded \0, > cut_file expects strlen of the returned string to match the string's > total length. > > To fix the behavior of the cut utility, introduce xmalloc_fgetline_n, > that fully matches the behavior of xmalloc_fgetline, > but also returns the amount of bytes read. > > Add a configuration option, FEATURE_USE_GETLINE, and enable it > by default. Use getline in xmalloc_fgetline_n if the feature is enabled. > > Change the behavior of cut_file to use the values returned > by the new function instead of calling strlen. > > Call xmalloc_fgetline_n from xmalloc_fgetline. > > Add a test for the previously mentioned case. > > With FEATURE_USE_GETLINE: > > function old new delta > xmalloc_fgetline_n - 173 +173 > xmalloc_fgetline 85 58 -27 > cut_main 1406 1367 -39 > ------------------------------------------------------------------------------ > (add/remove: 1/0 grow/shrink: 0/2 up/down: 173/-66) Total: 107 bytes > > Without FEATURE_USE_GETLINE: > > function old new delta > xmalloc_fgetline_n - 41 +41 > xmalloc_fgetline 85 58 -27 > cut_main 1406 1367 -39 > ------------------------------------------------------------------------------ > (add/remove: 1/0 grow/shrink: 0/2 up/down: 41/-66) Total: -25 bytes > > Fixes: https://bugs.busybox.net/show_bug.cgi?id=15276 > Signed-off-by: Elvira Khabirova > --- > coreutils/cut.c | 4 ++-- > include/libbb.h | 2 ++ > libbb/Config.src | 11 +++++++++++ > libbb/get_line_from_file.c | 37 ++++++++++++++++++++++++++++++++----- > testsuite/cut.tests | 2 ++ > 5 files changed, 49 insertions(+), 7 deletions(-) > > diff --git a/coreutils/cut.c b/coreutils/cut.c > index 55bdd9386..7c87467ca 100644 > --- a/coreutils/cut.c > +++ b/coreutils/cut.c > @@ -89,6 +89,7 @@ static void cut_file(FILE *file, const char *delim, const char *odelim, > const struct cut_list *cut_lists, unsigned nlists) > { > char *line; > + size_t linelen = 0; > unsigned linenum = 0; /* keep these zero-based to be consistent */ > regex_t reg; > int spos, shoe = option_mask32 & CUT_OPT_REGEX_FLGS; > @@ -96,10 +97,9 @@ static void cut_file(FILE *file, const char *delim, const char *odelim, > if (shoe) xregcomp(®, delim, REG_EXTENDED); > > /* go through every line in the file */ > - while ((line = xmalloc_fgetline(file)) != NULL) { > + while ((line = xmalloc_fgetline_n(file, &linelen)) != NULL) { > > /* set up a list so we can keep track of what's been printed */ > - int linelen = strlen(line); > char *printed = xzalloc(linelen + 1); > char *orig_line = line; > unsigned cl_pos = 0; > diff --git a/include/libbb.h b/include/libbb.h > index 6191debb1..73d16647a 100644 > --- a/include/libbb.h > +++ b/include/libbb.h > @@ -1048,6 +1048,8 @@ extern char *xmalloc_fgetline_str(FILE *file, const char *terminating_string) FA > extern char *xmalloc_fgets(FILE *file) FAST_FUNC RETURNS_MALLOC; > /* Chops off '\n' from the end, unlike fgets: */ > extern char *xmalloc_fgetline(FILE *file) FAST_FUNC RETURNS_MALLOC; > +/* Same as xmalloc_fgetline but returns number of bytes read: */ > +extern char* xmalloc_fgetline_n(FILE *file, size_t *n) FAST_FUNC RETURNS_MALLOC; > /* Same, but doesn't try to conserve space (may have some slack after the end) */ > /* extern char *xmalloc_fgetline_fast(FILE *file) FAST_FUNC RETURNS_MALLOC; */ > > diff --git a/libbb/Config.src b/libbb/Config.src > index b980f19a9..7a37929d6 100644 > --- a/libbb/Config.src > +++ b/libbb/Config.src > @@ -147,6 +147,17 @@ config MONOTONIC_SYSCALL > will be used instead (which gives wrong results if date/time > is reset). > > +config FEATURE_USE_GETLINE > + bool "Use getline library function" > + default y > + help > + When enabled, busybox will use the libc getline() function > + instead of getc loops to read data from files. > + Using getline provides better behavior when utilities > + encounter NUL bytes in their inputs. > + getline() was originally a GNU extension, but now is a part > + of POSIX.1-2008 and is implemented in contemporary libcs. > + > config IOCTL_HEX2STR_ERROR > bool "Use ioctl names rather than hex values in error messages" > default y > diff --git a/libbb/get_line_from_file.c b/libbb/get_line_from_file.c > index 903ff1fb6..096bbd66f 100644 > --- a/libbb/get_line_from_file.c > +++ b/libbb/get_line_from_file.c > @@ -12,9 +12,9 @@ > > char* FAST_FUNC bb_get_chunk_from_file(FILE *file, size_t *end) > { > - int ch; > - size_t idx = 0; > char *linebuf = NULL; > + size_t idx = 0; > + int ch; > > while ((ch = getc(file)) != EOF) { > /* grow the line buffer as necessary */ > @@ -55,10 +55,37 @@ char* FAST_FUNC xmalloc_fgets(FILE *file) > char* FAST_FUNC xmalloc_fgetline(FILE *file) > { > size_t i; > - char *c = bb_get_chunk_from_file(file, &i); > > - if (i && c[--i] == '\n') > - c[i] = '\0'; > + return xmalloc_fgetline_n(file, &i); > +} > + > +/* Get line. Remove trailing \n. Return the number of bytes read. */ > +char* FAST_FUNC xmalloc_fgetline_n(FILE *file, size_t *n) > +{ > + char *c = NULL; > +#if ENABLE_FEATURE_USE_GETLINE > + size_t idx = 0; > + ssize_t nread; > + > + nread = getline(&c, &idx, file); > + if (nread < 0) { > + if (errno == ENOMEM) > + bb_die_memory_exhausted(); > + free(c); > + c = NULL; > + *n = 0; > + } else { > + *n = nread; > + } > +#else > + c = bb_get_chunk_from_file(file, n); > +#endif > + > + if (*n) { > + if (c[*n - 1] == '\n') { > + c[--*n] = '\0'; > + } > + } > > return c; > } > diff --git a/testsuite/cut.tests b/testsuite/cut.tests > index 2458c019c..0fd731688 100755 > --- a/testsuite/cut.tests > +++ b/testsuite/cut.tests > @@ -81,4 +81,6 @@ SKIP= > testing "cut empty field" "cut -d ':' -f 1-3" "a::b\n" "" "a::b\n" > testing "cut empty field 2" "cut -d ':' -f 3-5" "b::c\n" "" "a::b::c:d\n" > > +testing "cut with embedded NUL" "cut -c 1-3" "\x00\x01\x00\n" "" "\x00\x01\x00\x03\x04\x05\x06" > + > exit $FAILCOUNT Hi, what is this change for? - int ch; - size_t idx = 0; char *linebuf = NULL; + size_t idx = 0; + int ch; Ciao, Tito From adamg at pobox.com Mon May 29 01:29:52 2023 From: adamg at pobox.com (Adam Goldman) Date: Sun, 28 May 2023 18:29:52 -0700 Subject: [PATCH] udhcpd: Serve BOOTP clients Message-ID: <20230529012951.GA21491@iguana.lan> This patch makes udhcpd respond correctly to queries from BOOTP clients. It contains the following changes: The end field, or DHCP_END option, is required in DHCP requests but optional in BOOTP requests. Only complain about missing end fields if there are DHCP options in the packet. However, we still send an end field in all replies, because some BOOTP clients expect one in replies even if they didn't send one in the request. Requests without a DHCP_MESSAGE_TYPE are recognized as BOOTP requests and handled appropriately, instead of being discarded. We still require an RFC 1048 options field, but we allow it to be empty. Since a BOOTP client will keep using the assigned IP forever, we only send a BOOTP reply if a static lease exists for that client. BOOTP replies shouldn't contain DHCP_* options, so we omit them if there was no DHCP_MESSAGE_TYPE in the request. Options other than DHCP_* options are still sent. The options field of a BOOTP reply must be exactly 64 bytes. If we construct a reply with more than 64 bytes of options, we give up and log an error instead of sending it. udhcp_send_raw_packet already pads the options field to 64 bytes if it is too short. This implementation has been tested against an HP PA-RISC client. --- networking/udhcp/common.c.orig 2023-05-22 18:41:39.000000000 -0700 +++ networking/udhcp/common.c 2023-05-21 19:18:15.000000000 -0700 @@ -234,6 +234,7 @@ void FAST_FUNC init_scan_state(struct dhcp_packet *packet, struct dhcp_scan_state *scan_state) { scan_state->overload = 0; + scan_state->is_dhcp = 0; scan_state->rem = sizeof(packet->options); scan_state->optionptr = packet->options; } @@ -251,12 +252,17 @@ /* option bytes: [code][len][data1][data2]..[dataLEN] */ while (1) { + if (scan_state->rem == 0 && !scan_state->is_dhcp) + break; /* BOOTP packet without end field */ if (scan_state->rem <= 0) { complain: bb_simple_error_msg("bad packet, malformed option field"); return NULL; } + if (scan_state->optionptr[OPT_CODE] >= DHCP_REQUESTED_IP && scan_state->optionptr[OPT_CODE] <= DHCP_CLIENT_ID) + scan_state->is_dhcp = 1; + /* DHCP_PADDING and DHCP_END have no [len] byte */ if (scan_state->optionptr[OPT_CODE] == DHCP_PADDING) { scan_state->rem--; --- networking/udhcp/common.h.orig 2023-01-03 06:17:01.000000000 -0800 +++ networking/udhcp/common.h 2023-05-21 19:01:24.000000000 -0700 @@ -123,6 +123,7 @@ struct dhcp_scan_state { int overload; + int is_dhcp; int rem; uint8_t *optionptr; }; --- networking/udhcp/packet.c.orig 2023-01-03 06:17:01.000000000 -0800 +++ networking/udhcp/packet.c 2023-05-23 00:22:45.000000000 -0700 @@ -18,6 +18,7 @@ memset(packet, 0, sizeof(*packet)); packet->op = BOOTREQUEST; /* if client to a server */ switch (type) { + case 0: case DHCPOFFER: case DHCPACK: case DHCPNAK: @@ -28,7 +29,8 @@ packet->cookie = htonl(DHCP_MAGIC); if (DHCP_END != 0) packet->options[0] = DHCP_END; - udhcp_add_simple_option(packet, DHCP_MESSAGE_TYPE, type); + if (type) + udhcp_add_simple_option(packet, DHCP_MESSAGE_TYPE, type); } #endif --- networking/udhcp/dhcpd.c.orig 2023-01-03 06:17:01.000000000 -0800 +++ networking/udhcp/dhcpd.c 2023-05-28 17:08:51.000000000 -0700 @@ -649,7 +649,8 @@ packet->flags = oldpacket->flags; packet->gateway_nip = oldpacket->gateway_nip; packet->ciaddr = oldpacket->ciaddr; - udhcp_add_simple_option(packet, DHCP_SERVER_ID, server_data.server_nip); + if(type) + udhcp_add_simple_option(packet, DHCP_SERVER_ID, server_data.server_nip); } /* Fill options field, siaddr_nip, and sname and boot_file fields. @@ -733,8 +734,11 @@ { struct dhcp_packet packet; uint32_t lease_time_sec; + char message_type = DHCPOFFER; - init_packet(&packet, oldpacket, DHCPOFFER); + if (!udhcp_get_option(oldpacket, DHCP_MESSAGE_TYPE)) + message_type = 0; + init_packet(&packet, oldpacket, message_type); /* If it is a static lease, use its IP */ packet.yiaddr = static_lease_nip; @@ -785,8 +789,13 @@ } lease_time_sec = select_lease_time(oldpacket); - udhcp_add_simple_option(&packet, DHCP_LEASE_TIME, htonl(lease_time_sec)); + if (udhcp_get_option(oldpacket, DHCP_MESSAGE_TYPE)) + udhcp_add_simple_option(&packet, DHCP_LEASE_TIME, htonl(lease_time_sec)); add_server_options(&packet); + if (!udhcp_get_option(oldpacket, DHCP_MESSAGE_TYPE) && udhcp_end_option(packet.options) > 63) { + bb_simple_error_msg("BOOTP BOOTREPLY would be too large, not sending"); + return; + } /* send_packet emits error message itself if it detects failure */ send_packet_verbose(&packet, "sending OFFER to %s"); @@ -1050,8 +1059,8 @@ continue; } msg_type = udhcp_get_option(&packet, DHCP_MESSAGE_TYPE); - if (!msg_type || msg_type[0] < DHCP_MINTYPE || msg_type[0] > DHCP_MAXTYPE) { - bb_info_msg("no or bad message type option%s", ", ignoring packet"); + if (msg_type && (msg_type[0] < DHCP_MINTYPE || msg_type[0] > DHCP_MAXTYPE)) { + bb_info_msg("bad message type option%s", ", ignoring packet"); continue; } @@ -1086,6 +1095,17 @@ move_from_unaligned32(requested_nip, requested_ip_opt); } + /* Handle BOOTP clients */ + if (!msg_type) { + log1("received %s", "BOOTP BOOTREQUEST"); + if (!static_lease_nip) { + log1("no static lease for BOOTP client%s", ", ignoring packet"); + continue; + } + send_offer(&packet, static_lease_nip, lease, requested_nip, arpping_ms); + continue; + } + switch (msg_type[0]) { case DHCPDISCOVER: From andrej.valek at siemens.com Mon May 29 07:17:42 2023 From: andrej.valek at siemens.com (Valek, Andrej) Date: Mon, 29 May 2023 07:17:42 +0000 Subject: BusyBox regression: i386/x86 Message-ID: <9e19ccfdc025844e705366410cdffbb146750ec8.camel@siemens.com> Hello everyone, I would like to ask you a question about the current state of http://lists.busybox.net/pipermail/busybox/2023-January/090078.html . The regression is still in place for 1.36.1 and master. | WARNING: busybox-1.36.1-r0 do_package_qa: QA Issue: busybox: ELF binary /bin/busybox.nosuid has relocations in .text [textrel] As we have known already, it happens only if CONFIG_SHA1_HWACCEL or CONFIG_SHA256_HWACCEL is enabled. Is there any way to identify/fix it? Thank you, Andy From pp01415943 at gmail.com Wed May 31 17:31:44 2023 From: pp01415943 at gmail.com (Petja Patjas) Date: Wed, 31 May 2023 20:31:44 +0300 Subject: [PATCH v2] vi: Ensure that the edit buffer ends in a newline In-Reply-To: <20230417132853.46391-1-pp01415943@gmail.com> References: <20230417132853.46391-1-pp01415943@gmail.com> Message-ID: On Mon, Apr 17, 2023 at 04:28:53PM +0300, Petja Patjas wrote: > Currently vi assumes that the edit buffer ends in a newline. This may > not be the case. For example: > > $ printf test > test > $ vi test > > > We fix this by inserting a newline to the end during initialization. > > Signed-off-by: Petja Patjas > --- > > The first patch didn't apply, sorry about that. I also took this chance > to simplify the logic a bit. > > editors/vi.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/editors/vi.c b/editors/vi.c > index 2645afe87..2947c5c1b 100644 > --- a/editors/vi.c > +++ b/editors/vi.c > @@ -2315,9 +2315,10 @@ static int init_text_buffer(char *fn) > > update_filename(fn); > rc = file_insert(fn, text, 1); > - if (rc < 0) { > - // file doesnt exist. Start empty buf with dummy line > - char_insert(text, '\n', NO_UNDO); > + if (rc <= 0 || *(end - 1) != '\n') { > + // file doesn't exist or doesn't end in a newline. > + // insert a newline to the end > + char_insert(end, '\n', NO_UNDO); > } > > flush_undo_data(); > -- > 2.40.0 > Any comments on this patch?