Re: RFC: initialize /dev/urandom, is it necessary? Can we do it in a better way?

[Michael Conrad]

On 9/19/23 01:36, Roberto A. Foglietta wrote:
On Tue, 19 Sept 2023 at 03:25, Michael Conrad 
 wrote:


On 9/18/23 06:14, Guillermo Rodriguez Garcia wrote:


everything is compressed with gzip -7. This is the worst
scenario.
However, even in the worst scenario due to gzip one single bit of
difference in the input generates a completely different
compressed
output:


Compression (or any other deterministic manipulation of data)
does not add any entropy (or "unpredictability") since the
processing is 100% reproducible.
In terms of entropy the output of the function is as good (or as
bad) as the amount of entropy in the initial seed.


Hi Michel,

Even aside from that, using gzip as some sort of hash function is
not going to be anywhere near as good as using an actual hash
function, like sha256, sha1 or even md5.


PREMISE

Hashing functions and compression algorithms are two completely 
different kinds of mathematical tools. The most obvious difference is that


That's a very large response so I'm not sure which part to quote, but I 
think you're still missing the point.  Assuming your initialization of 
randomness is meant to stop people from guessing the RSA/SSL keys you 
generate on a small low-power device during startup scripts, the 
attacker will probably have a copy of your device and be able to replay 
any of the steps you take during your startup script.  It will not 
matter whether you took a few random bits and a large static text and 
ran it through pigz before feeding it to /dev/urandom, because the 
attacker will start with guesses of the same few bits and also run them 
and that same static text through pigz to potentially get the same 
output.  If they mirror your initialization of /dev/urandom, then they 
can try to guess your RSA keys.  The only defense is having more actual 
bits of entropy, or preserving them from a previous boot in a manner 
that the attacker can't read.


My comment about hashing functions was implying that they would be used 
repeatedly, not that the entire input would be condensed into one single 
hash.  Yes there is a reduction of entropy if you feed a hash function 
more than 20 bytes of data and only get 20 out of it.  My point was that 
no hashing or compression is needed, because the kernel RNG is itself a 
sort of hash function and should handle that.  Just feed it the raw 
input bytes.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: RFC: initialize /dev/urandom, is it necessary? Can we do it in a better way?

[Michael Conrad]

On 9/18/23 06:14, Guillermo Rodriguez Garcia wrote:


everything is compressed with gzip -7. This is the worst scenario.
However, even in the worst scenario due to gzip one single bit of
difference in the input generates a completely different compressed
output:


Compression (or any other deterministic manipulation of data) does not 
add any entropy (or "unpredictability") since the processing is 100% 
reproducible.
In terms of entropy the output of the function is as good (or as bad) 
as the amount of entropy in the initial seed.


Even aside from that, using gzip as some sort of hash function is not 
going to be anywhere near as good as using an actual hash function, like 
sha256, sha1 or even md5.


I would expect this all goes into the kernel's own hashing inside the 
RNG and so gzip or any other hash function before delivering it to the 
kernel is probably irrelevant.


The name of the game is to find actually random bits, which you either 
need to save from the previous boot, or obtain from hardware somehow.  
The low bits of thermal sensors and multithreading scheduler timing 
nanoseconds are probably your best bet if you can't rely on having a 
hardware entropy generator.



-Mike C
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: busybox init returns fails with error code -1 (0x00007f00)

[Michael Conrad]

On 10/25/22 16:55, samuel ammonius wrote:

Hello,

I have a simple ISO filesystem set up with busybox and grub.These are 
the commands I use in GRUB2 to start the system:


grub> set root=(cd)
grub> linux /boot/bzImage root=/dev/sda1
grub> initrd /boot/initrd
grub> boot


I don't know how to get the full kernel error log, but the final error 
is "kernel panic: attempted to kill init! error code: 0x7f00". I 
tried building a static "Hello, world!" program as the FAQ said, and 
it worked. What could be causing the error?


You didn't provide any details about what is inside the initrd or the 
filesystem, where they came from, or what process you used to create 
them, so the problem could be just about anything.  There isn't even 
enough here to know whether it was busybox's init that died or the 
script inside the initrd.  Is busybox inside the initrd? or on 
/dev/sda1? or both? Chances are, you should probably ask on the 
forum/list related to the instructions you are following, such as buildroot.


If you can narrow it down to knowing for sure that busybox's init got 
called, and that calling other busybox applets (like '/bin/date', 
assuming that is one of your applets) succeeds, and give us any lines of 
error message that these generated before the kernel panic, and show us 
the /etc/inittab, then we can help a lot more accurately.


-Mike



___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH v2] seedrng: limit poolsize to 256 bytes and document flock() and fsync() usage

[Michael Conrad]

On 5/2/22 09:54, Bernhard Reutner-Fischer wrote:

There is also the case (that on my systems at least) udev
initialisation reads from /dev/[u]random well before the S20
script loads any saved entropy.
I've not tried to find out what the value is used for.

I find at least one occurrence where the goal is to create a
random delay in udev-watch.c [1].

Yes, but that spot does seem to have a fallback.

But why is the seeding being run only at S20, way after udev?


It needs to be at least late enough for the persistent storage to be 
mounted, which probably isn't the root filesystem at boot. udev probably 
needs to run first to find the device nodes for the persistent storage.




___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: suspected bug in timeout command

[Michael Conrad]

On 3/2/22 02:45, Raffaello D. Di Napoli wrote:

On 3/1/22 16:57, Denys Vlasenko wrote:
On Tue, Mar 1, 2022 at 5:39 PM Denys Vlasenko 
 wrote:

Meanwhile: what "timeout" is doing is it tries to get out
of the way of the PROG to be launched so that timeout's parent
sees PROG (not timeout) as a child. E.g. it can send signals
to it, get waitpid notifications if PROG has been stopped
with a signal, and such.

And PROG also has no spurious "timeout" child.
"timeout" exists as an orphaned granchild.


That doesn’t seem to be a concern for coreutils, according to Rob’s 
inspection. (I haven’t looked, but I’ll assume they still do signal 
forwarding and everything that can be done cheaply.) Isn’t it a goal 
of BB to avoid unnecessary divergence from coreutils?




Let's go with a solution with fd opened to /proc/PID?


I’d think simplifying the implementation and bringing it closer to 
coreutils’ would be more in line with BB’s goals, instead of making it 
larger and more complicated (especially considering how 
counter-intuitive it is already, despite being fairly small).



It might be worth mentioning that busybox can't conform to coreutils 
unless it does remain the parent process, because of this detail: (from 
coreutils' timeout man page)


> If the command times out, and --preserve-status is not set, then
> exit with status 124.  Otherwise, exit with the status of COMMAND.

timeout doesn't appear to be part of POSIX, though.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: grep: add option for better usability in pipelines

[Michael Conrad]

On 2/16/22 19:32, Kang-Che Sung wrote:



Now, for an example where it makes a difference. Consider a Bash script
like this:

   # enable automatic error handling
   set -eo pipefail
   # check for string "issues" in a logfile
   cat logfile | grep issue | sort --unique

If there are no issues in the logs, grep return exit code 1 and the
shell interprets this as an error and exits itself.


Why do we need to implement a workaround in grep while you can
do this in shell to ignore the exit code of grep?

{ grep issue 

In order to implement his suggestion, you need to only ignore exit code 
1, while still allowing other exit codes to abort the script. (like a 
system error while reading the file)


But also, I've never seen ":" used as a command... where is that 
documented?  Is it equivalent to 'true'?


-Mike C
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: suspected bug in timeout command

[Michael Conrad]

On 2/12/22 07:38, Michael Conrad wrote:
Correctly using pidfd *still* requires that you be the parent process, 
else the child could get reaped and replaced before the pidfd is 
created.  As far as I can tell, the only purpose of pidfd is for 
waking on poll() instead of using signals, which is orthagonal to this 
problem.


I haven't looked at the source in busybox yet, but it boggles my mind 
that it wouldn't just be a simple fork+alarm+waitpid because that is 
literally the least code implementation, and race-free.


-Mike C


Sorry for being lazy.  I looked at the source and this is the reason:

/* We want to create a grandchild which will watch
 * and kill the grandparent. Other methods:
 * making parent watch child disrupts parent<->child link
 * (example: "tcpsvd 0.0.0.0 1234 timeout service_prog" -
 * it's better if service_prog is a child of tcpsvd!),
 * making child watch parent results in programs having
 * unexpected children.    */

I don't follow this reasoning.  Does "disrupts the parent<->child link" 
just about sending signals?  If the timeout app relays all signals from 
itself to the child, what remaining problems would exist?


-Mike C

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: suspected bug in timeout command

[Michael Conrad]

On 2/12/22 06:08, David Laight wrote:

From: Raffaello D. Di Napoli

Sent: 12 February 2022 01:33


On 2/11/22 16:22, Rob Landley wrote:

On 2/9/22 11:12 AM, Baruch Siach wrote:

Hi Sun,

On Wed, Feb 09 2022, סאן עמר wrote:

Hi, I'm using busybox for a while now (v1.29.2). and I had an issue with a 
sigterm send randomly

to a process of mine. I debugged it until I found

it from the timeout process which was assigned before to another process with 
the same pid. (i'm

using a lot of timeouts for a lot of jobs)

so i looked at the code, "timeout.c" file where it sleep for 1 second in each 
iteration then check

the timeout status. I suspect at this time the

process timeout monitoring is terminated, but another one with the same pid is 
already created.

which creates unwanted timeout.

There is a comment in there about sleep for "HUGE NUM" will probably result in 
this issue, but I

can't see why it won't occur also in the current

case.

there is no change of this behaviour in the latest master.
i would appreciate any help, sun.

Any reference to PID number is inherently racy.

Not between parent and child.

Except in BB’s timeout, the relationship is not parent/child :)

Much to my surprise, I’ll say that. When I read the bug report the other
day, I thought to myself well, this one ought to be easy to fix. But no,
there’s no SIGCHLD to be handled, no relationship between processes to
be leveraged.

I don’t think this bug can be fixed without a near-complete rewrite, or
without doing a lot of procfs digging to really validate the waited-on
process, since kill(pid, 0) only validates a pid, not a process.

And Linux uses a strict 'next free pid' algorithm for new processes
so the is no guard time between a process exiting and its pid being reused.
This problem was 'fixed' inside the kernel by using a small structure
instead of the pid itself - but that didn't help userspace (or even some 
drivers).
By comparison NetBSD uses the high bits of the pid as a 'generation number'
and so guarantees that a pid won't be reused for some time (a few thousand 
forks).

You can use the process start time (I think it is in /proc/pid/stat)
to validate the process just before the kill().
That leaves a very small timing window that it is hard to avoid
without using pidfd.

David

Correctly using pidfd *still* requires that you be the parent process, 
else the child could get reaped and replaced before the pidfd is 
created.  As far as I can tell, the only purpose of pidfd is for waking 
on poll() instead of using signals, which is orthagonal to this problem.


I haven't looked at the source in busybox yet, but it boggles my mind 
that it wouldn't just be a simple fork+alarm+waitpid because that is 
literally the least code implementation, and race-free.


-Mike C

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: suspected bug in timeout command

[Michael Conrad]

On 2/9/22 12:12, Baruch Siach wrote:

Hi Sun,

On Wed, Feb 09 2022, סאן עמר wrote:

Hi, I'm using busybox for a while now (v1.29.2). and I had an issue with a 
sigterm send randomly to a process of mine. I debugged it until I found
it from the timeout process which was assigned before to another process with 
the same pid. (i'm using a lot of timeouts for a lot of jobs)
so i looked at the code, "timeout.c" file where it sleep for 1 second in each 
iteration then check the timeout status. I suspect at this time the
process timeout monitoring is terminated, but another one with the same pid is 
already created. which creates unwanted timeout.

There is a comment in there about sleep for "HUGE NUM" will probably result in 
this issue, but I can't see why it won't occur also in the current
case.

there is no change of this behaviour in the latest master.
i would appreciate any help, sun.

Any reference to PID number is inherently racy. There is no solution for
your problem in the traditional POSIX API.


PIDs are not racy if they are sent by the parent process.  Since the 
timeout command starts the other command, and waits to kill it, it 
should be the parent process, and will always reliably know that either 
the child is not reaped and can be sent a signal, or that it is reaped 
and there's no reason to.  Perhaps the implementation of this command 
needs corrected?


-Mike C

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Tar component in busybox version 1.34.1 has a memory leak bug when trying to unpack a tar file.

[Michael Conrad]

On 12/1/21 7:42 AM, tito wrote:



It can matter: consider large tar files on memory constrained devices.
tar may fail to complete correctly, due to running out of memory, and in
the process of running out of memory, may invoke the OOM killer in the
process, which might kill some other process.

Ariadne

Hi,

// Die if we can't allocate size bytes of memory.
void* FAST_FUNC xmalloc(size_t size)
{
void *ptr = malloc(size);
if (ptr == NULL && size != 0)
bb_die_memory_exhausted();
return ptr;
}

Ciao,
Tito


A stock Linux system will happily slaughter your system services with 
the OOM killer before malloc ever returns NULL.


In fact, I think the only way I've ever seen a program get NULL from 
malloc is if it exhausts 32-bit address space.


But, anyone assembling a embedded system has to be aware of the proper 
way to configure the OOM killer to kill the correct things first, so tar 
shouldn't be running with any privileges that would cause a real problem.


But back to the original question,


Hi~

It seems that I found a bug on busybox version 1.34.1:
In libbb/xfuncs_printf.c:50, malloc twice for archive_handle and
archive_hadle->fileheader with 184 and 72 bytes heap space.

Back to tar_main function, the two pointers(tar_handle，tar_handle->file_header)
hasn't been freed when return.



This isn't a bug.  Busybox frequently leaves out the 'free()' operations for 
anything that is a one-time allocation for the life of the process, because 
freeing it does nothing more than take up space and time.  Memory allocation 
tools will produce lots
of errors when you use them on busybox.

It only needs fixed if the memory usage *grows un-bounded* during execution.


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] shrink last_char_is function even more

[Michael Conrad]

On 7/19/2020 2:48 PM, Denys Vlasenko wrote:

strrchr(s,c) will first find the end of s, then go backwards looking for c.
The second part is wasted work, we only need to check the*last*  char == c.


Maybe a naive implementation, but why wouldn't they just record the last 
occurrence on a forward scan?


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH 3/4] lsscsi: code shrink and refactor

[Michael Conrad]

On 7/9/2020 3:16 PM, Markus Gothe wrote:
Jon Postel formulated the robustness principle decades ago. Still 
today it is a good advice to "be liberal in what you accept and strict 
in what you send".


Counterexample: Internet Explorer

It allowed so much garbage to render correctly that other browser 
vendors had to work overtime to accept all the same garbage and make 
sure it rendered in the same way.  Then, subsequently when IE was no 
longer defining the standard, progress was hamstrung by needing to be 
compatible with its own past allowances lest they be accused of breaking 
people intranets.  So much so that they just weren't able to fix most of 
their bugs and eventually abandoned the project.  If they had just 
declared tighter standards and enforced the rules, web development might 
not have been a misery for an entire decade.


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Nuke

[Michael Conrad]

On 6/20/2020 10:55 PM, Eli Schwartz wrote:

you should not "happen" to type in suspicious arguments to commands you
don't understand


I'd say about twice a year I accidentally dump some large body of text 
into my shell by accident.  The idea that one of those lines of text 
might start with the word nuke is unsettling, so I checked all my linux 
systems and verified that none of them have nuke in the path.


So if no standard system includes nuke by default maybe good to drop 
from default in busybox?


-Mike


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Busybox with a UEFI bios?

[Michael Conrad]

Busybox shouldn't have anything to do with BIOS or UEFI.  The boot 
loader and kernel handle those things, then once the kernel is running 
Busybox has a standard Posix environment to operate in.  You should 
investigate documentation on UEFI for the boot loader you are using.


On 5/4/2020 4:10 AM, Nikos Mouzakitis wrote:

Hello,
i have used BusyBox with SeaBIOS as a BIOS and i have successfully 
launched it.
What are the steps that i should take to do it with a UEFI bios? For 
example with

firmware from TianoCore/EDK2?

Thanks.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox



___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] nslookup: skip line comments on parsing /etc/resolv.conf

[Michael Conrad]

On 4/22/2020 11:36 AM, Leesoo Ahn wrote:

hence we save a few cycles while parsing


But you are also suggesting adding bytes, right?  This is the second 
time you have proposed a patch that adds bulk to busybox to save a 
little performance at runtime, which is the opposite of the goal of the 
project.  If you have use cases that are actually impacted by these 
performance problems, then you need to make a much more thorough 
argument about why these extra bytes are needed.


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: git smart http for busybox repo

[Michael Conrad]

On 4/13/2020 11:31 AM, Eli Schwartz wrote:

by attempting to demonize the request as an attack from people demanding
a workflow change from mailing lists and git to "mandatory github
webflow omg so smart".


I think he was serious, actually.  A rare case of needing to turn *off* 
your sarcasm filter, maybe?


FWIW, GitLab is available for free to run on your own infrastructure, 
and if you run it in a docker container behind Traefik, it gets an 
automatic LetsEncrypt SSL certificate.  It's amazingly easy to buy a 
$10/mo Linode or Digital Ocean Droplet and have a full-featured source 
repository website in the space of a Saturday afternoon.  (you can get 
it working on a $5/mo VM if you replace systemd with busybox service 
management)


I am not suggesting that this project change workflow at all, I just 
want to bring these "current events" to everyone's attention, to help 
put wdlkmpx's comments into perspective.


-Mike C

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Weird signal issues using yocto's warrior busybox (aarch64) when memory is cached

[Michael Conrad]

On 1/30/2020 12:53 AM, Sergio Paracuellos wrote:

 warning: core file may not match specified executable file.
 [New LWP 23217]

 warning: Could not load shared library symbols for 3 libraries,
e.g. /lib/libm.so.6.
 Use the "info sharedlibrary" command to see the complete listing.
 Do you need "set solib-search-path" or "set sysroot"?
 Core was generated by `sleep 1'.
 Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xfcd7fc60 in ?? ()
 (gdb) bt
#0  0xfcd7fc60 in ?? ()
#1  0x00555668af74 in ?? ()
 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
 (gdb)

Look at the PC (0xfcd7fc60) at this point.. It has not sense
at all. For me it looks like a stack corruption.


First things first, do you trust the hardware?  If the system swapped 
out some pages and then read them back in and the controller or storage 
device gave back bad data, this could cause all sorts of crashes.  Maybe 
run a memtest, too, unless you can reproduce the issue on multiple 
different machines.


I just had a USB thumb drive corrupt a file with no warning, so it was 
fresh on my mind.


-Mike

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Why almost every command is trying to read urandom?

[Michael Conrad]

On 11/12/19 2:47 PM, Mauro Condarelli wrote:
In a recent kernel(5.x) / Buildroot / Busybox for an embedded system 
(mips/MT7628, if it matters) I see TONS of:
|random: mount: uninitialized urandom read (4 bytes read) random: 
fsck.vfat: uninitialized urandom read (4 bytes read) random: tar: 
uninitialized urandom read (4 bytes read) (Complete startup log below) |


I hadn't noticed before, but I just checked and my busybox 1.11 is doing 
this (reading /dev/urandom on every single applet startup) but I have a 
later busybox 1.30 which does not.


   strace busybox echo 2>&1 | grep rand

This stops when, after a while (up to 10min later!!) I finally see: |[ 
562.001438] random: crng init done |


Two questions:

 1. why does it take so long to initialize /dev/urandom?
 2. for what reason |mount| or |tar| should try to use it in the first
place?

Note: I did NOT have this problem with older kernels (3.x).

1. /dev/random needs to "collect entropy" from unpredictable things like 
scheduler timing, human input devices, etc. /dev/urandom is then a 
less-secure source of random which gets initialized from /dev/random 
once the kernel is confident that /dev/random is random enough.  There 
are various places throughout the kernel code that feed entropy into the 
random pool, so changing kernels can change how fast it initializes.  
Busybox doesn't really have anything to do with this.  There might be 
some kernel options you need to explore to get things to initialize 
faster; but making it initialize faster might also be less secure.  You 
also have the option of writing some init script to preserve entropy 
from the previous boot and seed it after the reboot (by writing to 
/dev/random)


2. For one of the copies of busybox I have on hand, it appears that it 
initializes srand() at the startup of every single applet.  I don't see 
a reference to /dev/urandom in the current busybox source that would 
have this effect, so either busybox fixed it, or the behavior was coming 
from a particular libc used to build busybox.  My busybox with that 
behavior is statically linked, and I don't recall which libc it was.  
Since you just got yours out of a Buildroot, you should be able to 
investigate that easier.


-Mike


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] libbb: Converted safe_read to safe_write format

[Michael Conrad]

On 10/18/2019 10:54 AM, Denys Vlasenko wrote:

On Thu, Oct 10, 2019 at 4:35 PM Martin Lewis  wrote:

Hello,

Could you please elaborate on what was lacking in the INT_MAX part?
As seen in write's man page:

On Linux, write() (and similar system calls) will transfer at most 0x7000 
(2,147,479,552) bytes, returning the number of bytes actually transferred.  
(This  is  true  on
both 32-bit and 64-bit systems.)

Wouldn't it create an issue with 64 bit systems when trying to
read/write large files?

This seemed like a change not prompted by an actually observed
buggy behavior.


In fact, to my eyes

+if (count > SYS_BUFSIZE_MAX)
+count = SYS_BUFSIZE_MAX;

looks like it *introduces* a bug.  read() is always allowed to return a short 
count however the kernel pleases, and safe_read is supposed to call it in a 
loop until the desired size is reached or until EOF or a fatal error.  If you 
truncate the count before beginning the loop, then the caller ends up with a 
short read even though there might be more data.  (not that anyone would likely 
have a reason to *require* more than 2GB in a single buffer anyway...)

-Mike

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: fdisk head inconsistency

[Michael Conrad]

On 10/1/2019 6:58 PM, Mauro Condarelli wrote:
The former consistently swears I have "Geometry: 245 heads, 62 
sectors/track, 1021 cylinders",
while the latter insists on "Geometry: 4 heads, 16 sectors/track, 
242560 cylinders".

Physically the *same* card.
Of course Debian Linux is accessing the card through a USB card reader 
(hama a4504143, if it matters), while embedded Linux is accessing it 
directly via MMC interface present on uController (MT7628)... which 
could be a significant difference.


I just tried two versions of busybox fdisk (1.19.0, and 1.30.1) vs. two 
versions of util-linux fdisk (2.19, 2.34) and all four tools agree about 
the drive geometry of any drive I've tested on. I think you'll just need 
to do more experiments and see if you can pin down the problem on your end.


I need to do this in a script and to use BB fdisk I need to print 
previous partition data and manually set start of next one to 
prev_end+1. This is "inconvenient" to do in a shell script.
IMHO one of the two programs is severely broken and I would like to 
understand which and how to fix it.
Right now my "solution" is to disable BB fdisk and to install 
util-linux one, but that, of course, has a cost in a severely 
constrained embedded system with 16M total Flash space.


Any advice welcome.


Very inconvenient to do in a shell script, I agree :-) and in fact I'd 
advise against parsing fdisk with a shell at all.  The four tools I just 
tested each had a different output format! That's a pretty good 
indication it could change in the future and break your script and blow 
away someone's data.  Also that 'bootable' flag is pretty annoying 
because its presence/absence changes the number of fields on the line.  
There's an "sfdisk" which is better for scripting, but no busybox applet 
for it. Still, it is safer than scripting input for fdisk.


You don't need to give CHS geometry to fdisk, just sector numbers.  You 
can get sector numbers direct from the kernel using 
/sys/class/block/$DEV/start and /sys/class/block/$DEV/size.  (or on old 
kernels, /sys/block/$DEV/$PART_DEV/{start,size} ).  You could then 
construct a script for fdisk and pipe that in.  Of course, this depends 
on the kernel having read the partition table, which might not be the 
case if you're formatting something from scratch, but there's 
'partprobe' for that.  You also have to worry about what kind of 
partition table it is, because the kernel can parse GPT partitions and 
then if you try forcibly adding a new one with fdisk it might blow away 
the GPT table.  I just checked, and 'gdisk' isn't available from busybox 
yet... so there might not be a safe way to do this with pure busybox tools.


Hope that helps.

-Mike


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: fdisk head inconsistency

[Michael Conrad]

On 9/29/2019 8:57 AM, Mauro Condarelli wrote:

Note: the SD card was originally formatted using Debian GNU/Linux fdisk
on a desktop.

I have several problems here, possibly all stemming from  a bogus
detection of "disk geometry":
- (n)ew partition always suggested sector 16 as starting point
(obviously useless).
- (p)rint shows bogus values in CHS of newly created Partitions.
- (v)erify complains about "old" partition geometry.

(snip)

Command (m for help): p
Disk /dev/mmcblk0: 7580 MB, 7948206080 bytes, 15523840 sectors
242560 cylinders, 4 heads, 16 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device   Boot StartCHS    EndCHS    StartLBA EndLBA
Sectors  Size Id Type
/dev/mmcblk0p1    0,33,3  17,96,10  2048 264191
262144  128M  c Win95 FAT32 (LBA)
/dev/mmcblk0p2    17,96,11    293,126,14  264192    4458495
4194304 2048M 83 Linux


Since you have only run "delete" commands prior to this print command, 
I'm assuming that the debian fdisk wrote out those partitions where the 
head number (i.e. 33) is exceeding the maximum (4).  (but maybe you 
could check?)  I would guess that maybe the USB stick came with the 
partition table listing 4 heads 16 sectors as a hint to partition tools 
that the media likes 32K boundaries (4*16*512=32768).  Maybe Debian 
fdisk ignored those and wrote out CHS offsets based on assumption that 
the partition table matches the default geometry that fdisk generates?  
Either way, I'm guessing the inconsistency is already written to disk, 
so you can fix it (or not) however you like.


In the grand scheme of things, no modern software cares about those CHS 
numbers anyway.  Each partition table entry contains redundant CHS 
start/end and LBA (plain old integer sector number) start/end, and every 
modern tool/OS uses the LBA number and ignores the CHS, because the CHS 
haven't been real measurements for 25 years or more.


https://en.wikipedia.org/wiki/Master_boot_record#Partition_table_entries

The only thing you should worry about is that the partition is aligned 
on a multiple of the erase-size of the USB media.  I'm not current on 
what those are, but 1MiB should be sufficient, which is why the default 
start sector for fdisk is 2048 (*512=1MiB)


I'd just go ahead and try it assuming you have all the data on there 
backed up, which you should any time you play with partition tables ;-)


-Mike

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: in initrd "exec sh /dev/console 2>&1" does not respond to keyboard

[Michael Conrad]

Well, just a guess, but I'd say your problem is with kernel device 
drivers for input.  Usually people have the basic text showing up on 
their console and the complaints are about how to get ^C and other 
tty-specific features to work while using /dev/console.  Your problem 
sounds more like the Linux virtual console subsystem isn't connecting to 
your input devices. I'd suggest poking around in the input drivers 
section of the config and make sure things are compiled as "=y" and not 
as modules.


On 2/27/2019 8:44 PM, David Mathog wrote:

On 27-Feb-2019 17:37, Michael Conrad wrote:

On 2/27/2019 6:00 PM, David Mathog wrote:

On 27-Feb-2019 14:01, David Mathog wrote:

This is really frustrating!  Perhaps there is some kernel parameter
for 3.10.108 kernels which needs to be set (or unset)??? These are
built into the kernel, seems like they should be enough

CONFIG_HID=y
CONFIG_HID_GENERIC=y
CONFIG_USB_HID=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB=y


It is definitely the kernel. If the custom (based on "make 
menuconfig" of boel)

3.10.108 kernel is replaced with a stock Centos 7 kernel then



What do you get from "grep CONSOLE .config" in each of the two kernels ?


The one where the keyboard does not work:

# CONFIG_NETCONSOLE is not set
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y

The one where where the keyboard does work:

CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_CONSOLE_POLL=y
# CONFIG_LP_CONSOLE is not set
CONFIG_VIRTIO_CONSOLE=m
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_USB_SERIAL_CONSOLE=y
# CONFIG_PSTORE_CONSOLE is not set
CONFIG_KGDB_SERIAL_CONSOLE=y

That said, there are a zillion other differences...

Thanks,

David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox



___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: in initrd "exec sh /dev/console 2>&1" does not respond to keyboard

[Michael Conrad]

On 2/27/2019 6:00 PM, David Mathog wrote:

On 27-Feb-2019 14:01, David Mathog wrote:

This is really frustrating!  Perhaps there is some kernel parameter
for 3.10.108 kernels which needs to be set (or unset)???  These are
built into the kernel, seems like they should be enough

CONFIG_HID=y
CONFIG_HID_GENERIC=y
CONFIG_USB_HID=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB=y


It is definitely the kernel. If the custom (based on "make menuconfig" 
of boel)

3.10.108 kernel is replaced with a stock Centos 7 kernel then



What do you get from "grep CONSOLE .config" in each of the two kernels ?


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [git commit] bc: new applet, throws warning

[Michael Conrad]

On 12/6/2018 11:48 AM, Gavin Howard wrote:

you are
going to have to make the bc not give good error messages and/or not
check for errors as thoroughly (a massive chunk of the parser, which
is the largest portion, is dedicated to error checking), reduce the
quality of the code, reduce the performance of the math (though this
would not remove much), or all of them combined.


Just FYI, these are typical things people do for busybox applets ;-)

I'm not a bc user, so I don't care either way; having the applet seems 
better than not having it, and you seem to have thoroughly completed a 
difficult project.  ...but I do think maybe you missed the spirit of 
Busybox code.


-Mike

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [RFC PATCH v2] Allow applets to be implemented as scripts

[Michael Conrad]

On 11/7/2018 9:18 AM, Kang-Che Sung wrote:

On Wed, Nov 7, 2018 at 9:54 PM Tito wrote:

this embedded scripts patch looks like "featuritis" at its best to me.
It is adding complexity for solving what problem exactly:
avoiding to copy the scripts manually to the new system or to
the new firmware image?

I see one advantage of embedding scripts into busybox binary:
compression. The script could remain compressed in a firmware or
read-only image, saving space, and is useful for users who build
busybox only to run a specific script (installation, embedded
system startup, or something else non-trivial).
I think it's okay for that use case.


IMHO squashfs is a better option all around.  The main use case I 
imagine is that you want a recovery shell to live alongside a regular 
system image, and have the embedded scripts only available when running 
busybox sh, and save some integration work of mounting the rest of the 
recovery file tree at the appropriate places.  For example, if your 
/etc/profile is only valid for bash, then if you want to run busybox ash 
on that system it would help to have /etc/profile load magically from 
within busybox.


The main downside I see is that it violates the Principle of Least 
Astonishment.



One side effect I fear will derive from this patch is that
users which would be capable of sending patches for bugs
they find in bb will resort to simply scrap the applet and add
an embedded script as it is faster.

I disagree. Embedded script always has an overhead of starting a shell
interpreter, although I acknowledge the size advantage the script can
provide, as long as many coreutils are present in that environment.
The script won't worth embedding if you don't intend to build a shell or
coreutils in busybox.


It sounds like not just the overhead of the interpreter, but also the 
overhead of decompressing them on each execution.


But, there are lots of standard unix tools which are seldom-used and 
don't have much performance requirement, and if they can be implemented 
as a shell script half the size of the comparable machine code, then 
that makes sense.


-Mike

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: License concerns when embedding script in busybox binary

[Michael Conrad]

On 11/7/2018 10:49 AM, Ron Yorston wrote:

Kang-Che Sung wrote:

Specifically, I think the current state of config ASH_EMBEDDED_SCRIPTS help
text did not yet warn builders that the binary may be distributed **only when
the embedding scripts are GPLv2-compatible**. Builder and distributors may
accidentally violate copyright if they didn't get careful at reading the
BusyBox licenses. I think something should be done to make the warning more
explicit.

As I said:  I don't know what the status of embedded scripts is.  *Are*
they required to be GPLv2 compatible?


I'm not a lawyer either, but I'd guess they probably need to be. But, 
the main requirement is that a vendor provide the source to their 
customer, and the source is in fact being shipped because it's a 
script.  Anyone with gdb would be able to extract the table and then 
decompress it back to the original directory of scripts.  Maybe if 
busybox had an option to dump out the scripts it would help enforce the 
idea that the sources were being shipped.  Wonder how many bytes that 
would require...


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: less Idle time with busybox ash as bash vs bash

[Michael Conrad]

Busybox utilities are written in whatever way uses the fewest bytes.  
Most standard utilities are optimized for speed.  Sometimes the reduced 
footprint of busybox can offset the lack of speed optimization because 
it can remain in disk cache or processor cache.  And sometimes not.


If your bash script does a lot of script logic (i.e. more of an 
application rather than just sequence of commands), then it would be 
reasonable to see a dip in performance.  If you do mostly just call 
other utilities, then you should make sure that you have PREFER_APPLETS 
enabled and that you're actually getting the benefit of avoiding 
exec().  Maybe, try running strace on each of bash and ash-as-bash and 
count the number of execve calls.  Then you'll have a decent idea of how 
the bash builtins stack up to the busybox PREFER_APPLETS overall.


On 9/6/2018 6:54 PM, James Hanley wrote:

To be clear - when we run the same script under bash vs busybox ash as bash - 
bash yields 10% more idle time to the system. I assumed that the fork/exec of 
all the underlying utilities (test etc) compared to the vfork or function calls 
in busybox would yield better results (not worse) then bash.

Is this expected behavior?

-Jim


On Aug 31, 2018, at 2:06 PM, James Hanley  wrote:

We had some bash scripts that we converted to use busybox ash as bash
(removed any array constructs) and when comparing the two scripts - it
seems that running them under busybox yields less idle time compared
to bash.

I was expecting that busybox would (itself) take up more time simply
because of vfork, but yield more CPU time overall since there would be
less overhead as a number of the applets would not fork

Is this expected behavior that busybox overall yields less idle time?
-Jim

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox



___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] wget: don't silently ignore certificate validation

[Michael Conrad]

The story just broke earlier this year how a casino hotel "smart 
thermometer" in the fish tank was used as a backdoor to attack the rest 
of their network.


If a smart device running busybox is programmed to automatically check 
for firmware updates, the designers might expect HTTPS to be a valid 
form of security to know that they were accessing their own servers.  If 
they don't write a test case to verify that certificates are checked, 
it's shoddy work, but there's a lot of shoddy work in smart devices.


In such a scenario, anyone on the same wifi would be able to overwrite 
the firmware of the device.  This almost deserves a CVE number.


-Mike

On 5/26/2018 1:34 PM, Denys Vlasenko wrote:

wget should work for common use cases.
Such as downloading sources of kernels, gcc and such.
 From build scripts, not only by hand.
Without having to modify said scripts.
Your patch breaks that.
NAK.

I don't care that security people are upset.
They are paranoid, it's part of their profession.
It does not mean everybody else have to be as paranoid.

If you have a patch which adds actual cert checking
and thus does not introduce regressions, please post it.


On Sat, May 26, 2018 at 6:38 PM,   wrote:

//config:   If you still think this is unacceptable, send patches.


That’s exactly what I did.
http://lists.busybox.net/pipermail/busybox/2018-May/086444.html

Jakub


On 2018-05-26 17:54, Denys Vlasenko wrote:

On Sat, May 26, 2018 at 5:39 PM,   wrote:

That's a crime against security!


Say what?


That’s a hyperbole. The thing is that when you don’t verify the peer’s
certificate, then you’re vulnerable to MitM attack with fake certificate
injection. The whole SSL/TLS is totally useless in that moment. It’s more
or
less like putting the door’s key under the carpet right in front of the
door.

Allowing to bypass/ignore certificate verification is ok-ish in some
situations, but only when the user do it consciously, using explicit
option
such as --no-check-certificate, not silently as the default option.


wget.c:

//config:   If you still think this is unacceptable, send patches.
//config:
//config:   If you still think this is unacceptable, do not want to
send
//config:   patches, but do want to waste bandwidth explaining how
wrong
//config:   it is, you will be ignored.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox



___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: add bb_info_msg was Re: Applets send errors to syslog during normal, successful operation

[Michael Conrad]

On 3/5/2018 5:11 PM, Deweloper wrote:

Hi,
I see your point, forget about this bb_info_msg stuff.
The same result can still be achieved by using:

syslog_level = LOG_INFO
bb_error_msg(...)
syslog_level = LOG_ERR

if needed

If I interpret bloatcheck results properly, the above costs extra
45 B of code per call @x86-64.


That sounded suspicious, so I checked.  Might be worthwhile 
investigating what gcc was up to, because assigning a small constant to 
a global should be 7 bytes each on x86-64


However, pushing a small constant onto the stack should be 2 bytes, 
though ironically loading that small constant into a register for 
pass-by-register calling convention is 5.


So, with enough calls it would be worth it to create a new function, 
with a savings of about 9 bytes per use over the global variable trick 
vs. the cost of adding the new function.


(and wow, there's a nutty size optimization ... you could push a 1-byte 
constant onto the stack and pop it off into the register of your choice 
with two fewer bytes than the instruction to assign the constant 
directly to the register.)


-Mike

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Proper defense against symlink attacks in tar, unzip et al

[Michael Conrad]

On 2/19/2018 11:15 AM, Denys Vlasenko wrote:

On Mon, Feb 19, 2018 at 5:09 PM, Harald van Dijk  wrote:

Let's also brainstorm option 3:
Allow symlinks which
(a) start with one or more "../";
(b) never end up on a higher level of directory tree:
"../dir/.." is ok,
"../../usr/bin/.." is ok,
"../file" is not ok,
"../../dir/file" is not ok;
and (c) they also should not leave tarred tree:
symlink "sbin/mkswap" to "../bin/busybox" is ok, but
symlink "mkswap" to "../bin/busybox" is not ok (it hops "above" the
tree).

This sounds a bit complicated, but it can be achieved just by looking
at names, no multiple lstat() calls for every open() needed.

With only these symlinks allowed, we know that if we untar to an empty
directory or to a formerly empty directory with another tarball
untarred, any pathname we open, whilst it can contain components which
are symlinks, they nevertheless can not allow new opens to "leave" the
tree and create files elsewhere.

This wouldn't be safe, I think. Consider a tarball containing

a/
b/
a/a -> ../b
a/a/a -> ../../c


The link to "../../c" is not allowed - it fails criteria (b).

You wrote "it can be achieved just by looking at names", but that's not
enough here: you have to know that a/a/a is actually b/a, so only one level
deep in the -C directory, to know that ../../c points outside the -C
directory.

Yes... but:


Since the a/a -> ../b symlink may not even be in this archive,
the only way to determine that is by lstat().

I assume that tarball(s) are being unpacked into an empty directory.
The case when someone already placed malicious symlinks there
before unpacking would be a bug in whatever tool allowed _that_
to happen.

My goal here is to not allow tar (and unzip) to create such symlinks.


That might be considered a bug though.  There's lots of times a symlink 
points to a higher directory (or even starts with '/') and tar should be 
a reliable way to mirror a directory tree.


What if you do a test on the inode of the destination directory?  To 
determine whether it is valid, repeatedly append ".." and stat until you 
reach root or the unpack directory.  Then to speed it up, make a 
fixed-size LRU cache of directories you know are valid.  Each time you 
create a directory, add it to the cache, and then on average you 
probably only add one directory stat per unpacked file.  For more speed 
and less security, just change it to a cache of path names.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] init: Add handshake to poweroff/reboot for signal handler setup

[Michael Conrad]

On 11/24/2017 9:09 PM, Deb McLemore wrote:

+   while (1) {
+   fdrc = connect(fdBB2,
+   (struct sockaddr *)_addr2,
+   sizeof(sa_family_t) +
+   BB_SIGNALS_SOCKET_STR_LEN);
+   if (fdrc == 0)
+   break;
+   sleep(1);
+   }


On 2/14/2018 1:58 PM, Michael Conrad wrote:
This will give you even better "instant boot sequence abort" 
performance than you would get with the design you're proposing, 
unless you have some insanely high polling rate in the reboot_helper 
that you think can actually deliver the signal before init has even 
forked for the first time. 


Sorry, I wasn't paying close enough attention to what you were 
proposing.  If you have a 1-second sleep, then you're really not trying 
to block the startup sequence, you're just looking for a way to make 
sure the signal gets delivered?


...then just

/bin/reboot:

   #! /bin/sh
   while ! -d /proc; do sleep 1; done;
   /bin/busybox reboot


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] init: Add handshake to poweroff/reboot for signal handler setup

[Michael Conrad]

On 2/14/2018 12:53 PM, Deb McLemore wrote:

The only reproduction we were able to perform injected via a BMC soft poweroff 
being triggered.

This then called into kernel/reboot.c (orderly_poweroff where the schedule_work 
was performed) utilizing the

usermodehelper during the run_cmd /sbin/poweroff.


I'd like to point out that there's still a race condition, since when 
init starts it might kick off the rest of your startup sequence before 
the idle reboot process gets a time slice to discover that init is alive 
and send the signal.


Would it maybe be better to have the main script that initializes your 
system check for the existence of the socket, and if found, stop 
everything and tell init to shutdown?


Also, why not have the reboot process look for something in the 
filesystem to indicate whether the system has started booting? Before 
init starts, there won't be anything in the filesystem, but that's not a 
problem because you can just wait until there is.


To make a complete proposal, why not:

reboot_helper:
  1) create abstract socket
  2) wait for any filesystem path that indicates init sequence has 
started (/proc maybe)

  3) send reboot signal to init

init_userspace.sh
  1) check for abstract socket, and if exists, send signal to init and 
then exit

  2) else run startup sequence

This will give you even better "instant boot sequence abort" performance 
than you would get with the design you're proposing, unless you have 
some insanely high polling rate in the reboot_helper that you think can 
actually deliver the signal before init has even forked for the first time.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] ash: make bash_source command search current directory after PATH

[Michael Conrad]

On 1/26/2018 12:47 PM, Cathey, Jim wrote:

My understanding, from years past, is that "source " (or ". ") is _exactly_ the 
same as "", except that it's running in _this_ shell rather than in a subshell.  Thus it is able to 
affect environment variables that subsequent commands can inherit, etc.

If "." is not in your PATH, and you want to source a file that's right there, you have to 
". ./" just as you'd expect.  If that's not what bash is doing, then it's wrong.


I fought through the bash startup scripts almost 20 years ago in 
college, and still have "source .bashrc" in my ~/.bash_profile that I've 
been carrying from system to system ever since :-)  and my PATH has 
never had '.' in it.  Your explanation makes perfect sense though.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] ash: make bash_source command search current directory after PATH

[Michael Conrad]

On 1/26/2018 9:15 AM, Denys Vlasenko wrote:

On Fri, Jan 26, 2018 at 9:34 AM, Paul Otto  wrote:

According to the BASH documentation, the source command should:
Read and execute commands from filename  in  the  current  shell environment
and return the exit status of the last command executed from filename.  If
filename does not contain a slash, filenames  in  PATH  are used to find the
directory containing filename.  The file searched for in PATH  need  not  be
executable. When  bash  is  not  in  posix  mode,  the  current directory is
searched if no file is found in PATH.

I wish bash wouldn't introduce gratuitous standard violations.


But wow, learn something every day... I never knew 'source' searched 
PATH at all.  I thought it just loaded a file with the same semantics as 
'open()'.


This would be the danger of learning by example instead of reading the 
manual.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] Fix runsvdir so it reaps children and avoid zombi processes when killed.

[Michael Conrad]

On 1/9/2018 1:53 PM, Laurent Bercot wrote:


Zombies will _always_ be observable, even if you try to reap 
immediately.


 Of course. I used "observable" in the broad sense, meaning there is a
nonzero amount of time where init is not runnable, won't be scheduled,
and won't immediately reap zombies. This makes zombie observation
literally millions of times more likely than when there's no blocking
path between the moment it gets a SIGCHLD and the moment it reaps the
zombie. :) 


But then there's the age-old question of whether you should make edge 
cases more rare so that they almost never happen, or more frequent so 
that people can catch their mistakes.


Some years ago, I had a co-worker who was testing our code (C++) on BSD 
while I was testing on Linux, and he would constantly find my 
un-initialized attribute bugs, because Linux was zeroing every object 
allocation (probably just the underlying pages from mmap), but BSD 
wasn't.  I'm sure the Linux behavior saves people from a lot of random 
crashes, making development easier, but it leaves the bugs out there in 
the wild to be run into later.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: ash.c history loading and ENABLE_FEATURE_EDITING_SAVEHISTORY

[Michael Conrad]

On 12/24/2017 4:43 AM, Ceriel Jacobs wrote:



Where is the user interface to quickly issue a pre-written shell 
function? And how to see the available functions?
 


ls /usr/local/bin ...?

Just add your "pre-written shell commands" in script files, give them a 
useful name, and put them in the PATH.  This is what most people do.


-Mike

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: BusyBox built-in shell (ash)

[Michael Conrad]

On 12/12/2017 6:28 PM, A.W.C. wrote:
yes, I know that Squashfs is read-only filesystem. Tried again, not 
sure what need be changed here for this specific configuration and 
filesystems available.



# mknod -m 666 /dev/null c 1 3
mknod: /dev/null: Read-only file system


You say you understand it is read only, but this error message is 
exactly the problem you are having.  You cannot change things in a 
directory which is on a read-only filesystem.


It appears you do not have the devtmpfs built into your kernel (the one 
which comes pre-populated with lots of helpful device nodes), so you 
will need to use something else, like tmpfs (which comes completely 
empty, but writable).


Maybe try

mount -t tmpfs none /dev
mknod -m 666 /dev/null c 1 3
# and all the rest of your device nodes


-Mike

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Reboot implemention

[Michael Conrad]

On 11/13/2017 8:19 PM, Cathey, Jim wrote:


>Is there a reason why BusyBox's [reboot] implementation is different, 
or is it a bug?


The final fs cleanup, and the only one that really counts, is what the 
kernel does after init(8) exits.




Pretty sure if init exits it is an immediate PANIC, which is not how 
most systems reboot.  I think it all ends with the reboot syscall. I'm 
not sure what the semantics are for that syscall, but it would seem that 
sync() would be wise to execute first.  Unless it's implied by reboot().


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] ash: avoid GLIBC'ism %m

[Michael Conrad]

On 7/22/2017 2:56 PM, Johannes Schindelin wrote:

Hi Denys,

On Fri, 21 Jul 2017, Denys Vlasenko wrote:


On Wed, Jul 19, 2017 at 3:47 AM, Jody Bruchon  wrote:

On 2017-07-18 9:15 PM, Kang-Che Sung wrote:

On Wed, Jul 19, 2017 at 2:11 AM, Markus Gothe 
wrote:

Actually last time I checked ‘%m’ is POSIX contrary to glibc’s deprecated
'%a’. However, I agree that it should not be used since at least uClibc can
be built without support for it.

How come %m is POSIX when I didn't see any mention of it in this page?
http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html

It does not appear to be part of POSIX or the Single UNIX Specification. The
glibc man page (as of 2016-12-12) even indicates that it is a glibc-specific
extension:

*m *(Glibc extension; supported by uClibc and musl.) Print output of
/strerror(errno)/. No argument is required.

This sounds like every libc has already conceded to implementing it.

Let's benefit from it then?

No, not every libc. I would not have spent the time and effort to develop
the patch, contribute it, rework it and contribute a second iteration if
it was not for a good reason now, would I.

Ciao,
Johannes



I believe his point is that your patch adds size to busybox which is 
unneeded for most users.  (btw, it's recommended to post bloatcheck 
numbers with a patch.  If you show a small number from bloatcheck then 
there is less to argue about)


Which libc are you using?  Do you think %m support could be checked with 
an ifdef?


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH 1/1] makedevs: set path size to match linux

[Michael Conrad]

On 6/27/2017 3:10 AM, Ralf Friedl wrote:

Michael Conrad wrote:
If you ask for large enough allocations on the stack, GCC will 
secretly give you malloc/free instead, which adds to code size. It 
might be that 4096 triggers this effect, and perhaps that was the 
reason for the original small-ish static buffer.
Do you have a reference for that? I just tried it, and GCC just 
allocates memory from the stack no matter the size. Granted, it is a 
64-bit system, but I used 0x1 (281474976710656) which 
should be enough to trigger such a behavior even on a 64-bit system. 
In fact, it is more than a current system can provide either in the 
stack or through malloc.



I guess I'll retract this, unless someone else knows something. I 
remember someone warning about this behavior, but I can't find a 
reference and I just tested on 32-bit and allocating stack buffers up to 
the maximum stack size are all shifting the stack pointer by the size of 
the buffer.  Declaring a buffer larger than the maximum stack size 
results in an instant segfault when the function is called.


It could have been a different compiler, or platform, or maybe a special 
flag to gcc.  Sorry for the misinformation.


-Mike

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH 1/1] makedevs: set path size to match linux

[Michael Conrad]

On 6/26/2017 9:45 PM, Matthew Weber wrote:

Baruch/Emmanuel,

On Mon, Jun 26, 2017 at 7:36 PM, Emmanuel Deloget  wrote:

Hello,

On Mon, Jun 26, 2017 at 11:23 PM, Matthew Weber
 wrote:

Baruch,

On Mon, Jun 26, 2017 at 3:55 PM, Baruch Siach  wrote:

Hi Jared,

On Mon, Jun 26, 2017 at 03:33:09PM -0500, Matt Weber wrote:

From: Jared Bents 

Update to increase the pathname limit to the
linux limit of 4096 characters.

Similar patch:
https://patchwork.openembedded.org/patch/131475/

Signed-off-by: Jared Bents 
Signed-off-by: Matt Weber 
---
  miscutils/makedevs.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/miscutils/makedevs.c b/miscutils/makedevs.c
index 9e7ca34..0049edb 100644
--- a/miscutils/makedevs.c
+++ b/miscutils/makedevs.c
@@ -208,7 +208,7 @@ int makedevs_main(int argc UNUSED_PARAM, char
**argv)
   unsigned count = 0;
   unsigned increment = 0;
   unsigned start = 0;
- char name[41];
+ char name[4096];

Why not use PATH_MAX here?

Agree, that would be cleaner.  Will submit v2 after some testing.

That still leaves a hardcoded value in the sscanf  of 4095
should I add a comment to the affect we're assuming PATH_MAX is at
least 4096?  Maybe a check is also needed?


Alternatively you may use the m modifier, when implemented, to auto-allocate
the name pointer. This way you don't have to hardcode anything in the
sscanf(), you let the library for the job for you. Later, you can check the
string length.

Such a change would induce an allocation, a free but will also reduce stack
usage.


If we want to keep it all static, another option would be to stringify
that define.
(Courtesy Jared for this idea)

+ #define STRINGIFY(x) STRINGIFY2(x)
+ #define STRINGIFY2(x) #x
.
- if ((2 > sscanf(line, "%40s %c %o %40s %40s %u %u %u %u %u",
+ if ((2 > sscanf(line, "%" STRINGIFY(PATH_MAX) "s %c %o %40s %40s %u
%u %u %u %u",


If you ask for large enough allocations on the stack, GCC will secretly 
give you malloc/free instead, which adds to code size.  It might be that 
4096 triggers this effect, and perhaps that was the reason for the 
original small-ish static buffer.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: # CONFIG_BUSYBOX is not set: breakage on master

[Michael Conrad]

On 8/27/2016 2:18 AM, Cristian Ionescu-Idbohrn wrote:

On Sat, 27 Aug 2016, Denys Vlasenko wrote:

config BUSYBOX
 bool "Include busybox applet"
 default y
 help
   The busybox applet provides general help regarding busybox and
   allows the included applets to be listed.  It's also required
   if applet links are to be installed at runtime.

   If you can live without these features disabling this will save
   some space.

And this is also expected:

$ ./busybox
busybox: applet not found

when executed immediately after build?  And this too?

$ ./busybox --help
-help: applet not found

$ ./busybox --list
-list: applet not found



Yes, adding or removing those behaviors is precisely the purpose of the 
CONFIG_BUSYBOX setting.


Maybe you should explain your situation and what you expected? because a 
person reading your subject line would assume you are trying to say "I 
compiled busybox without the CONFIG_BUSYBOX flag, and now I'm surprised 
that it did what it said it would do"...

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] getrandom: new applet

[Michael Conrad]

On 7/12/2016 5:53 PM, Rich Felker wrote:

On Tue, Jul 12, 2016 at 01:09:42PM -0400, Michael Conrad wrote:

On 7/7/2016 11:49 AM, Rob Landley wrote:

On 07/06/2016 11:41 AM, Etienne Champetier wrote:

Now you really hate the fact that getrandom() is a syscall.

I do not hate the fact getrandom is a syscall. I'm asking what the point
is of a new applet to call this syscall. You have suggested it could
block to show when /dev/urandom is producing a higher grade of
randomness than it does before being properly seeded. That is, as far as
I can tell, the only reason for your new applet to exist rather than
upgrading $RANDOM in ash/hush.


Actually in my opinion the syscall is inferior to a new character
device, because blocking syscalls interfere with event-driven
programming.

Suppose you want to write a single-thread event-driven web server
which initializes its SSL library with this randomness source (i.e.
won't allow SSL until enough entropy is collected for a good
initialization) but you still want it to be able to accept non-SSL
connections.  In order to use the syscall you need a thread, or
child process.  (haha, such as pipe to a "getrandom" applet...)

Thanks for contributing your ideas about what color the bikeshed
should be, but getrandom's already got you covered. Until your csPRNG
is initialized, just call getrandom with the GRND_NONBLOCK once each
time you get any event (i.e. each time poll() returns). There's no
need to busy-wait or periodically check with timeouts since you don't
need the results until there's an event to act on, anyway.


Not unless they add a feature to deliver a signal when it becomes 
un-blocked.


And they don't have me covered unless the event library I'm using adds 
explicit support for it.  If I'm using libevent or glib and was asked to 
write such a program today, I'd probably have to settle for polling with 
a timer, or a thread.



There are very good reasons it's a syscall rather than a device: many
use cases require a never-fails entropy source, and with the device
node approach they're vulnerable to fd-exhaustion attacks. Most
existing bad code, when faced with such a situation, falls back to
some completely insecure seed like time(). The only reliable way to
prevent such idiocy was to provide an interface that can't fail.


It's trivial to open it at program start, and abort if you can't. If the 
FD is already open it will never fail.


The "unix way" is to make things waitable via file handles, or via 
signals.  I have a personal grudge against blocking system calls.


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] getrandom: new applet

[Michael Conrad]

On 7/7/2016 11:49 AM, Rob Landley wrote:

On 07/06/2016 11:41 AM, Etienne Champetier wrote:

>Now you really hate the fact that getrandom() is a syscall.

I do not hate the fact getrandom is a syscall. I'm asking what the point
is of a new applet to call this syscall. You have suggested it could
block to show when /dev/urandom is producing a higher grade of
randomness than it does before being properly seeded. That is, as far as
I can tell, the only reason for your new applet to exist rather than
upgrading $RANDOM in ash/hush.

Actually in my opinion the syscall is inferior to a new character 
device, because blocking syscalls interfere with event-driven programming.


Suppose you want to write a single-thread event-driven web server which 
initializes its SSL library with this randomness source (i.e. won't 
allow SSL until enough entropy is collected for a good initialization) 
but you still want it to be able to accept non-SSL connections.  In 
order to use the syscall you need a thread, or child process.  (haha, 
such as pipe to a "getrandom" applet...)


-Mike


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: busybox sed, 'r' command

[Michael Conrad]

On 3/23/2016 12:12 PM, Ralf Friedl wrote:

Cristian Ionescu-Idbohrn wrote:

sed (GNU sed) 4.2.2 can do this:

$ printf 'foo
bar
baz' | sed r -
foo
bar
baz

or, after storing the text in a file:

$ printf 'foo
bar
baz' >/tmp/bar

$ sed r /tmp/bar
foo
bar
baz

But busybox sed can't:

$ printf 'foo
bar
baz' | busybox sed r -
sed: empty filename

$ busybox sed r /tmp/bar
sed: empty filename

$ printf '' | busybox sed 'r /tmp/bar'


$ busybox sed 'r /tmp/bar'


The 'r' command is documented by GNU sed as a GNU extension. Still,
busybox sed documents the 'r' command as supported:

r [address]r file
   Read contents of file and append after the contents of the
   pattern space. Exactly one space must be put between r and 
the

   filename.

Am I misinterpreting the documentation?

From the documentation:
>   The full format for invoking `sed' is:
> sed OPTIONS... [SCRIPT] [INPUTFILE...]
So in your example you invoce sed with the script "r" and the input 
file "-" or "/tmp/bar". The content is not printed because it is the 
argument to the "r" command, but because it is the main input file to 
sed. You can avoid that by using quotes around the command and the 
file name, or by omitting the space between the command and the filename.
You should also try the last two examples, where you invoke busybox 
sed with quotes, with GNU sed. The behaviour is the same.


You should note that in your example when reading from a file, sed 
didn't read from stdin, at least you don't mention it, although your 
interpretation would mean that the filename is the argument to the "r" 
command, therefor no argument is given to sed, and sed should read stdin.


You should also not that invoking the "r" command with the filename 
causes the content of this file to be inserted after every line. When 
reading from a pipe, the pipe is empty after the first line.


My documentation to GNU sed 4.2.2 says:
> `r FILENAME'
>  As a GNU extension, this command accepts two addresses.
>
>  Queue the contents of FILENAME to be read and inserted into the
>  output stream at the end of the current cycle, or when the next
>  input line is read.  Note that if FILENAME cannot be read, it is
>  treated as if it were an empty file, without any error indication.
>
>  As a GNU `sed' extension, the special value `/dev/stdin' is
>  supported for the file name, which reads the contents of the
>  standard input.

So the main difference seems to be that GNU sed doesn't give an error 
message if the file can't be read. I'm not sure why that would be a 
good idea.
Also not that there is no mention of using "r -" for stdin, instead 
/dev/stdin is mentioned.


On the other hand, I don't know why busybox sed needs exactly one 
space between command and filename. GNU sed works with zero or more 
spaces.


It looks to me that what actually happens when running "sed r" is that 
it appends *no lines* to the end of each line read from stdin.


$ printf 'foo
bar
baz' | sed

Does not add a final newline

$ printf 'foo
bar
baz' | sed r

Does add a final newline

$ printf 'foo
bar
baz' | sed 'r /dev/null'

Does add a final newline

echo "blah" > -
$ printf 'foo
bar
baz' | sed 'r -'

results in

foo
blah
bar
blah
baz
blah

So it is not a special case for the filename.

I personally don't see much value in preserving the behavior of 
appending nothing for a file which doesn't exist.  Tools should give 
errors if they can't do what you ask them to.


-Mike C.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH v3 3/4] nsenter: new applet

[Michael Conrad]

On 3/16/2016 11:35 AM, Bartosz Gołaszewski wrote:

2016-03-15 21:45 GMT+01:00 Mike Frysinger :

On 15 Mar 2016 12:00, Bartosz Gołaszewski wrote:

Actually some time ago I sent a series extending the readahead applet.
It was rejected eventually but one of the patches was actually adding
a useful macro taken from systemd that seems to be doing a nice job at
determining the right size for string buffers holding integers:

http://lists.busybox.net/pipermail/busybox/2015-August/083302.html

And Denys' reponse:

2015-08-25 14:52 GMT+02:00 Denys Vlasenko :

I am using a mich simpler expression, sizeof(type)*3.

type,sizeof(type)*3, actual reqd # of chars
char 3  3
short6  5
int  12 10
int64_t  24 19

As you see, it is a quite good approximation.

Let's see how it works in real-world example:

char path[sizeof("/proc/self/fd/%d") + sizeof(int)*3];
char path[sizeof("/proc/self/fd/%d") + DECIMAL_STR_MAX(int)];

With current name, it becomes longer.
Can you make this macro shorter?

i think his example just goes to show that, even when you think about it,
you get it wrong :).  his examples miss the extra byte needed for the -
sign, and he used %d which is signed (rather than %u which is unsigned).

also, that macro is wrong for the same reason :).
-mike

What about #define INT_BUF_MAX(type) (sizeof(type) * 3 + 1)?

It would give us (including the preceding '-' and terminating '\0'):

sizeofbufsizeactual max
1 4  4
2 7  7
4 13 12
8 25 20


Or, use the actual 2.4 ratio, rounded up, plus sign, plus NUL.  (and 
your "actual max" is wrong)


#define INT_BUF_MAX(type) (sizeof(type) * 24 / 10 + 3)

sizeofbufsizeactual max
1 5  5
2 7  7
4 12 12
8 22 21

The final one is only wrong because we added a byte for sign but a signed 
64-bit is actually 63 bits which is a character shorter.


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH v3 3/4] nsenter: new applet

[Michael Conrad]

On 3/14/2016 2:27 PM, Mike Frysinger wrote:

the code seems to assume that the byte size scales into the number of
chars required to represent the number in base 10 when it's really a
log scale.  here's a table to show it's wonky:


The number of bytes is also a log scale.  The ratio of log_256 to log_10 
is 2.4, so 3 is a reasonable approximation.  It reasonably handles the 
case of 16-bit, 32-bit and 64-bit PIDs (which are all I would think 
would ever appear in the wild)


I don't see what the complaint is since its only bytes of stack space 
anyway...

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: NEED help with Busybox

[Michael Conrad]

These are mostly Unix questions, not busybox questions.  But I'll answer 
off-list to get you started.


On 3/6/2016 7:14 AM, Hiep Huynh wrote:

Hi there,

I'm a newbie to Busybox and I need your help with these questions:

1) How do I check if my Linux kernel system is using busybox?
2) Usually on a embedded Linux system, how does busybox get fired up 
after system boots?
3) When a command "top" is entered, could you help explain how that 
command is routed to use busybox's top? Or point me to any document?

4) Lastly, what are the steps to upgrade Busybox on existing Linux system?

Thank you so much for your help.
Hiep


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Michael Conrad]

On 10/14/2015 2:37 AM, Natanael Copa wrote:

The security is based on physical access. The local technician can log
in without password. (in theory, if you have physical access then you
have access to it all anyway). And after all, it is the "local technician"
the device is supposed to protect anyway.


Why run 'login' at all?  You can just run "agetty -l /bin/bash" from 
init or runit and always have a shell ready.


Alternatively you can randomize the password and print it on the console 
with the welcome message.


Just some other ideas.
-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: How to use read in Busybox v1.1.1 ?

[Michael Conrad]

On 5/14/2015 11:33 AM, Mike Yates wrote:

On 13 May 2015 at 16:27, Michael Conrad mcon...@intellitree.com wrote:

On 5/13/2015 7:45 AM, Mike Yates wrote:

read -p Enter name:  $name

I have found that the $ is the issue - Busybox will only accept a
variable name without it, while Bash accepts either, or the null
variable.

I think you have some other error in your script giving this illusion.

No, I do not  - the command line I gave is now working just fine,
without the $.
I have tested everything at the command-line anyway.
I had been trying a null or existing (but unassigned) variable, as
used in Bash, while Busybox v1.1.1 only accepts new or assigned
variables.


You are using some strange terminology here.  What is a null variable? 
an existing but unassigned variable?  AFAIK the shell doesn't have 
these concepts.  If the variable exists it must have a value, though it 
could be an empty string.



I mean read, read $v and read v all work in Bash, but only read
v in Ash (Busybox).


By your own examples below, read $v does *not* work in bash. Unless 
your definition of work is doesn't throw an error but it clearly 
doesn't store the value in $v.


-Mike C.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: How to use read in Busybox v1.1.1 ?

[Michael Conrad]

On 5/14/2015 12:38 PM, Mike Yates wrote:

After all, I was only using read as a convenient stop to debug
prompt. The ash arg count error prevented read from stopping the
script and was almost disastrous!


Ok, so by works you mean stops to wait for a newline.  That was the 
primary point of confusion.



As I said, Busybox should either make its built-ins Posix Compliant or
explain prominently why they are not (Almquist) or, better still, give
a usage line on failure.


http://pubs.opengroup.org/onlinepubs/9699919799//utilities/read.html

This document says nothing about the variable being optional or any 
reference to the $REPLY variable.  Do you have a link to a document that 
says otherwise?



I'm sure you will sggest a more reliable method?


If you want the widest compatibility with shells, simply say read 
REPLY, and/or actually require the value you read to be yes or y 
before continuing, which is what most people do.


Also, I like to use set -e so that any command which fails will exit 
the shell.  The shell's default of continuing after failed commands is 
the dangerous part.



That said, it doesn't seem like a bad idea to add $REPLY support to 
busybox sh if it can be written in a few bytes, which I suspect it can.


-Mike C
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: How to use read in Busybox v1.1.1 ?

[Michael Conrad]

On 5/13/2015 7:45 AM, Mike Yates wrote:

On 11 May 2015 at 20:01, Bastian Bittorf bitt...@bluebottle.com wrote:

* Mike Yates x...@fonehelp.co.uk [11.05.2015 18:05]:

The command read in Busybox v1.23 functions just like in GNU bash but in the
v1.1.1 in my old NAS it keeps complaining of not enough arguments.

what is your exact commandline?


read -p Enter name:  $name

I have found that the $ is the issue - Busybox will only accept a
variable name without it, while Bash accepts either, or the null
variable.


I think you have some other error in your script giving this illusion.  
My bash behaves like busybox. As far as I know it has never been 
possible to read $foo and get the value placed into $foo (unless $foo=foo)


$ bash --version
GNU bash, version 4.3.33(1)-release (x86_64-unknown-linux-gnu)
...

$ x=a
$ read $x
blahblah
$ echo $x
a
$ echo $a
blahblah

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: How to use read in Busybox v1.1.1 ?

[Michael Conrad]

On 5/13/2015 11:30 AM, Jody Bruchon wrote:

On 05/13/2015 11:27 AM, Michael Conrad wrote:

My bash behaves like busybox. As far as I know it has never been
possible to read $foo and get the value placed into $foo (unless
$foo=foo)
I confirmed that bash on one of my servers does allow use of 'read 
$foo' instead of 'read foo'. It seems like a bad idea though; if a 
POSIX sh-compatible script sets foo=bar and goes 'read $foo' to 
effectively perform a 'read bar' then bash will break it.




The oldest bash I have is
   GNU bash, version 4.2.53(1)-release (i386-pc-linux-gnu)
   Copyright (C) 2011 Free Software Foundation, Inc.
and doesn't work there either.

I'm curious, what happens in your version of bash if you use read in a loop?

while read $foo; do
  echo $foo;
done

Does it start writing to an unintended variable on the second iteration?

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Add a user/password interface for a Telnet and ftp connect

[Michael Conrad]

On 03/18/2015 10:50 AM, Alexis Guilloteau wrote:

Hi,

Right now i can run a Telnet daemon on one of my board using the 
command /usb/sbin/telnet -l /bin/sh and run a ftp daemon thanks to 
inetd.conf but each of the connection are anonymous (well, it ask for 
a user name but not for a password...)
After looking at the help of the ftpd function in busybox i know that 
the main function is to create an anonymous ftp server so i was not 
surprised with the lack but do you think there would be a solution for 
that ? I would think it would be to work into the .c file of the 
function but maybe you have another idea.
And pretty much the same thing for telnetd. Right now the only user on 
the board is the root with no password.




If you do want any sort of security, you are better off using ssh and 
sftp.  Telnet and ftp don't really offer any security even with 
passwords, so there is little interest in adding support for permissions 
to those applets.  The most popular ssh for embedded is 'dropbear': 
https://matt.ucc.asn.au/dropbear/dropbear.html


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [RFC] Proof-of-concept for netlink listener for mdev -i

[Michael Conrad]

On 03/15/2015 12:16 PM, Laurent Bercot wrote:

On 15/03/2015 15:52, Natanael Copa wrote:

I have simplified the long-time living netlink listener more by
forwarding the netlink socket and letting the handler read
directly from netlink. This factorize out the pipe and remove the need
of any micro protocol.


 As I wrote in another message, there is basically no benefit in doing
that, because it forces the handler to be netlink-aware.



But then it would still need to be micro-protocol-aware.  The netlink 
protocol is nearly identical to the micro-protocol you proposed earlier; 
maybe being netlink-aware isn't so bad?


The main difference is whether it uses recv() expecting a datagram or 
read() and has to parse some message framing.  I'd bet the first 
requires less code.  And, it doesn't have to be a netlink socket; the 
messages could be relayed through any datagram socket.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: RFD: Rework/extending functionality of mdev

[Michael Conrad]

On 3/13/2015 11:21 AM, Harald Becker wrote:

On 13.03.2015 12:41, Michael Conrad wrote:

Stream-writes are not atomic, and your message can theoretically get
cut in half and interleaved with another process writing the same
fifo.  (in practice, this is unlikely, but still an invalid design)


---snip---
O_NONBLOCK disabled, n = PIPE_BUF
All n bytes are written atomically; write(2) may block if there is not
room for n bytes to be written immediately
---snip---



I stand corrected.  I thought there would be a partial write if the pipe 
was mostly full, but indeed, it blocks.




If someone really wants a netlink solution they will not be happy
with a fifo approximation of one.


You missed the fact, my approach allows for free selection of the 
mechanism. C hosing netlink means using netlink, as it should be. The 
event listener part is as small as possible and write to the pipe, 
which fire up a parser / handler to consume the event messages.


Are you suggesting even the netlink mode will have a process reading the 
netlink socket and writing the fifo, so another process and can process 
the fifo?  The netlink messages are already a simple protocol, just use 
it as-is.  Pass the



On 3/13/2015 12:14 PM, Harald Becker wrote:

The new code would not be run like a hotplug helper, it would be run as
a daemon, probably from a supervisor.  But the old code is still there
and can still be run as a hotplug helper.


The new code behaves exactly as the old code. When used as a hotplug 
helper, it suffers from parsing conf for each event. My approach is a 
splitting of the old mdev into two active threads, which avoid those 
problems even for those who like to stay at kernel hotplug.


Then it sounds like indeed, you are introducing new configuration steps 
for the old-style hotplug helper?  i.e. where does the fifo live?  who 
owns it? what security implications does this have?  Who starts the 
single back-end mdev processor?  If started from the hotplug-helper, who 
ensures that only one gets started?


If people have existing systems using hotplug-helper mdev, you can't 
just change the implementation on them in a way that requires extra 
configuration.  Everyone who has commented on this thread so far agrees 
with that.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: RFD: Rework/extending functionality of mdev

[Michael Conrad]

On 3/13/2015 9:48 AM, Harald Becker wrote:

On 13.03.2015 12:29, Michael Conrad wrote:

On 3/13/2015 3:25 AM, Harald Becker wrote:

   1 - kernel-spawned hotplug helpers is the traditional way,
   2 - netlink socket daemon is the right way to solve the forkbomb
problem


ACK, but #2 blocks usage for those who like / need to stay at #1 / #0


In that case, I would offer this idea:


All you do, is throwing in complex code sharing and the need to chose
a mechanism ahead at build time, to allow for switching to some newer
stuff ... but what about pre-generated binary versions, which
mechanism shall be used in the default options, which mechanism shall
be offered?


Please review it again.  My solution solves both #1 and #2 in the same
binary, with no code duplication.


At first complex code reusage, and then: How will you do it without 
suffering from hotplug handler problem as current mdev? I'm don't 
seeing, that you try to handle this problem. My solution is to enable 
kernel hotplug handler mechanism to also benefit and avoid that 
parallel parsing for each event.


... beside that, this close / open_netlink look suspicious, looks like 
possible race condition. 


I thought pseudocode would be clearer than English text, but I suppose 
my pseudocode is still really just English...  Maybe some comments will 
help.


The new code would not be run like a hotplug helper, it would be run as 
a daemon, probably from a supervisor.  But the old code is still there 
and can still be run as a hotplug helper.


  mdev_main() {
read_options();
load_config();
// if user requests --netlink mode, we act like a daemon
if (option_netlink) {
  // If --netlink-on-stdin then netlink is open for us already
  // if not, then we need to create our netlink socket
  if (!option_netlink_on_stdin) {
close(0); // the new socket will now be file descriptor 0
open_netlink_socket();
  }
  // use 'select()' to see if a new netlink message is ready.
  // if the user gave us a --timeout then we exit if no new
  //  netlink message in a certain amount of time
  while (select([0], timeout)) {
if (recv(0, message)) {
  // Netlink message is a list of variables.  We call 'setenv' 
for each.

  apply_env_from_message(message);
  // Now we have all the hotplug variables.  So call the old code.
  process_request();
}
// keep running in a loop until timeout (or forever if no timeout)
  }
}
else
#endif
  process_request();
  }

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: RFD: Rework/extending functionality of mdev

[Michael Conrad]

On 3/13/2015 3:25 AM, Harald Becker wrote:

   1 - kernel-spawned hotplug helpers is the traditional way,
   2 - netlink socket daemon is the right way to solve the forkbomb
problem


ACK, but #2 blocks usage for those who like / need to stay at #1 / #0


In that case, I would offer this idea:


All you do, is throwing in complex code sharing and the need to chose 
a mechanism ahead at build time, to allow for switching to some newer 
stuff ... but what about pre-generated binary versions, which 
mechanism shall be used in the default options, which mechanism shall 
be offered?


Please review it again.  My solution solves both #1 and #2 in the same 
binary, with no code duplication.


I suggested wrapping #2 in a ifdef for the people who don't have netlink 
at all, such as on BSD, and also anyone who doesn't want the extra bytes.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: RFD: Rework/extending functionality of mdev

[Michael Conrad]

On 3/13/2015 3:25 AM, Harald Becker wrote:
This is splitting operation of a big process in different threads, 
using an interprocess communication method. Using a named pipe (fifo) 
is the proven Unix way for this ... and it allows #2 without blocking 
#1 or #0.


Multiple processes writing into the same fifo is not a valid design.  
Stream-writes are not atomic, and your message can theoretically get cut 
in half and interleaved with another process writing the same fifo.  (in 
practice, this is unlikely, but still an invalid design)


If you want to do this you need a unix datagram socket, like they use 
for syslog.


It is also a broken approximation of netlink because you don't preserve 
the ordering that netlink would give you, which according to the kernel 
documentation was one of the driving factors to invent it.  If someone 
really wants a netlink solution they will not be happy with a fifo 
approximation of one.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: RFD: Rework/extending functionality of mdev

[Michael Conrad]

The question I was asking was only about this:

On 3/12/2015 12:04 PM, Harald Becker wrote:
but that one will only work when you either use the kernel hotplug 
helper mechanism, or the netlink approach. You drop out those who 
can't / doesn't want to use either. 


...which I really do think could be answered in one paragraph :-) If the 
netlink socket is the right way to solve the forkbomb problem that 
happens with hotplug helpers, then why would anyone want to solve it the 
wrong way?  I don't understand the need.


-Mike


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: RFD: Rework/extending functionality of mdev

[Michael Conrad]

On 3/11/2015 9:30 AM, Harald Becker wrote:
So how can we avoid that unwanted parallelism, but still enable all of 
the above usage scenarios *and* still have a maximum of code sharing 
*and* a minimum of memory usage *without* delaying the average event 
handling too much?


The gathering parts need to acquire the device information, sanitize 
this information, and serialize the event operations to the right 
order. The device node handling part shall receive the information 
from the gathering part(s) (whichever is used) and call the required 
operations, but shall avoid reparsing the conf on every event (speed 
up) *and* drop as much memory usage as possible, when the event system 
is idle.


My idea is a fifo approach. This allows splitting the device 
management functionalities. Nevertheless which approach to gather the 
device information is used, the parser and device handling part can be 
shared (even on a mixed usage scenario). 


Supposing that we have
  * mdev acting as a parallel hotplug handler forked by the kernel
and then add
  * mdevd which reads netlink messages and runs as a daemon

What specifically is the appeal of a third approach which tries to 
re-create the kernel netlink design in user-land using a fifo written 
from forked hotplug helpers?


I'm interested in this thread, but there is too much to read.  Can you 
explain your reason in one concise paragraph?


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Question on busybox and loading firmware?

[Michael Conrad]

On 9/23/2014 2:05 AM, Michael D. Setzer II wrote:

device class 'firmware': registering
pci :02:08.0: Firmware left e100 interrupts enabled; disabling
ipw2200 :02:02.0: Direct firmware load failed with error -2
firmware ipw2200-bss.fw: firmware: requesting ipw2200-bss.fw
ipw2200: ipw2200-bss.fw request_firmware failed: Reason -12
ipw2200: Unable to load firmware: -12
usbserial: USB Serial support registered for Keyspan - (without firmware)
psmouse serio2: trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 3/3


Most google results show -2.  Maybe check the kernel source to see what 
-12 is?



...takes about 1:46 to get
to the loading of the file system, so not sure where the 60 seconds timeout
starts, or if that is what is making it take so long?? On desktop system, the
kernel loads in about 15 seconds.


If you enable timestamps in the kernel logging it can help find things 
that are taking a long time to initialize.  1:46 seems a bit excessive.  
If this does end up being the problem that the kernel firmware loader 
times out before the root filesystem even gets loaded, you might be able 
to edit the timeout in the kernel source.




Another message talked about a hot plugin script, but there are two variables
that it says are defined in the envirnonment, and I can not find them?



Also, not sure if it would apply, since I thought hotplug was for devices that
are later plugged into the system instead of devices that are actually built 
into
the sytem.



These environment variables exist only when when the kernel is asking 
for firmware.  The hotplug interface is used for pretty much all 
communication from the kernel to userspace about driver-things.


A quick way to debug is with a script like

#! /bin/sh
echo ---  /var/log/hotplug_requests.log
/usr/bin/env  /var/log/hotplug_requests.log
exec /sbin/mdev



HOTPLUG_FW_DIR=/usr/lib/hotplug/firmware/


firmware is typically located at /lib/firmware.  This is where mdev 
would look for it by default.



Did a search in the /sys directory to look for any file called loading, but none
exist on notebook or desktop systems I've seen.


They are created on demand by the kernel, matching the environment 
variables given to hotplug.




Thanks again.


If I had more time available I could give better examples, but there are 
past examples in the archives of this list.


Good luck!

-Mike


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Question on busybox and loading firmware?

[Michael Conrad]

On 9/22/2014 10:27 AM, Michael D. Setzer II wrote:

On 22 Sep 2014 at 10:32, Gustavo Zacarias wrote:

On 09/22/2014 09:56 AM, Michael D. Setzer II wrote:

Was already able to find the firmware since it was included with the 
installation
of the fedora 20 on the notebook. Issue is that I placed the firmware files 
into the
  /lib/firmware directory, but on booting from my project kernel it seems to 
try and
load firmware during the kernel loading before the ramdisk.lzma is loaded. The
kernel is built with the option to not include firmware, since I don't know 
what if
any firmware will be needed by end users.  This seems to have worked with
bnx2  and bnx2x firmware that another end user needed.

But the booting showed the messages before the ramdisk.lzma is
recognized, and then shows messages with =-12, and =-2. Didn't save the
output since this was a ram only load. Was thinking that mdev -s might cause
it to load firmware. Kernel contains most disk and ethernet devices included.

Hi.
Make the driver a module instead of built into the kernel.
The driver might initialize before the kernel/userland has
access/mounted a root filesystem and that's what happens.

Thanks for the reply. Problem is that iso has the option of select 7 different
kernels, so if I changed it to using moduals I would have to include them for
multiple kernels and also come up with a script to load the moduals. Right
now everything works by having the kernels handle the hardware.


I think the right way to handle that is to have each kernel look for a 
different /lib/modules/* directory.  You shouldn't need a special script 
to load modules because the kernel should report them to mdev and it 
should just work.  But I understand wanting to have a static kernel 
for simplicity.


Anyway, when the kernel tries to load firmware, you should get a 
60-second timeout before it gives up.  If you have more than 60 seconds 
between when the module gets initialized and when your filesystem gets 
mounted, then that could be the problem.  There are past messages on 
this list that show how to get better logging of what the kernel is 
asking from mdev, which might help you find the problem.


What I have done for my static kernels is to include the firmware into 
the compiled kernel.  This is best when you know that the kernel will 
always need the firmware.  (but if you are doing this for lots optional 
hardware, you can end up with a very large kernel, which is worse than 
needing to load firmware from the filesystem) Don't remember offhand, 
but there is a kernel config where you tell it the directory of the 
firmware, and tell it what filenames to include, and then those files 
get sucked in when you compile the kernel and are automatically 
available at boot.


Hope that helps,
-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: How do I (unconditionally) enable unicode support in busybox?

[Michael Conrad]

On 08/10/2014 03:39 AM, James Bowlin wrote:

I ran into problems like this years ago when I tried it before.
I had given up before because there were just so many variables
(kernel header version ublibc version, binutils version,
buildroot version, busybox version, and more) that could cause
the segfault.  I think patches may be needed too.

My guess is that it will work with uclibc but is flakey with
glibc.


Want a cheap trick for getting it all to work?  Extract gentoo-uclibc in 
a directory, chroot into it (with a number of the Gentoo install steps 
like setting up resolv.conf and /dev and /proc) and then USE=static 
emerge busybox.


Gentoo-uclibc in a chroot is my weapon of choice these days.  I hate 
cross-compiling with a passion.


(would love to see someone put together a gentoo-musl! )

-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: shutdown busybox and start another PID1 process

[Michael Conrad]

On 08/09/2014 07:02 AM, Rieker Flaik wrote:

But here I can't do that because /sbin/init has taken over PID 1 and
spawned processes. So I first have to shut this pre-OS down before
booting into the next.

Is there a way to kill all processes and start a shellscript as PID 1
again? Maybe by tweaking /etc/inittab and its restart option? Or do I
need to hack the source in busybox-1.22.0/init/init.c?


As tito said, kexec is probably the best option.  But I would add that 
runsvdir (runit suite, also part of busybox) would probably serve your 
needs better than init.  Run a shell script as PID 1, have it run 
runsvdir, and then when your backup script is complete just kill the 
runsvdir and it will cleanly shut down all the services, and return.  
Then the PID 1 script can exec things like normal.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: How do I (unconditionally) enable unicode support in busybox?

[Michael Conrad]

On 8/4/2014 2:48 PM, James Bowlin wrote:

BTW, the following code is an infinite loop in my
initrd:

[ $LANG = en_US.UTF-8 ] || LANG=en_US.UTF-8 exec $0 $@


I think you should focus on this bug.  Which busybox version? Which libc 
version?  Because my busybox runs it just fine. (as should any 
conforming shell)

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] top: fix parsing of /proc/meminfo

[Michael Conrad]

On 07/21/2014 04:44 PM, Dan Fandrich wrote:

On Sun, Jul 20, 2014 at 11:20:13AM +0300, Timo Teras wrote:

On Sat, 19 Jul 2014 21:31:33 +0200
Dan Fandrich d...@coneharvesters.com wrote:


On Fri, Jul 18, 2014 at 10:07:06PM +0300, Timo Teräs wrote:

and do it in smaller code:

diff --git a/procps/top.c b/procps/top.c
index 530f45f..e60dab6 100644
--- a/procps/top.c
+++ b/procps/top.c
@@ -501,10 +501,27 @@ static void display_cpus(int scr_width, char
*scrbuf, int *lines_rem_p)
  static unsigned long display_header(int scr_width, int
*lines_rem_p) {
+   static const char *fields =

Minor suggestion: this should be
static const char * const fields =

so it can go into .rodata.


That said, adding the second const does make sense. And thinking more,
static should probably be left out.

static needs to be left in in order to avoid a copy of the structure onto the
stack at run-time.

All this may be moot with an optimizing compiler, but not all compilers are
necessarily smart enough to do this on their own. Adding those keywords also
makes it more clear what the intent is of the structure.


Am I missing something here?  There is no structure, just a character 
pointer.  If you leave off static it will be compiled as an 
instruction that pushes a constant onto the stack, by any/every compiler.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: /proc/pid/cmdline and udhcpcd

[Michael Conrad]

On 03/26/2014 09:13 AM, Cristian Ionescu-Idbohrn wrote:

On Wed, 26 Mar 2014, Denys Vlasenko wrote:

But how that respawn tool going to work with other programs?

As I've written in a previous message, I know nothing of such other
programs, but I'd be intrested to learn more.


There is no convention in Unix that you can't modify argv[].

Sad, because if there was, there would have been something to refer
to.


daemontools and runit's runsvdir both have a feature where they log to 
the cmdline, as a ... clever? way of not relying on a writable logging 
destination.

http://smarden.org/runit/runsvdir.8.html

I'm aware of quite a few Perl daemons that overwrite their proc title 
(otherwise you'd end up with perl ... all over your ps listing).  
Examples include Catalyst and Plack fast-cgi servers.


I've personally written C code that replaces the = with \0 in 
options like --option-foo=VALUE.  Not in any published open-source 
though, I don't think...


All mysql utilities overwrite passwords in cmdline as a security measure.
http://dev.mysql.com/doc/refman/5.1/en/password-security-user.html

So in short, its a thing that the Linux world has been doing for a long 
time, though infrequently.  I'm sure someone at your work thought 
re-using /proc/*/cmdline was a really cool idea, and built a system 
around it, and this system might have been working ok for you so far.  
And I sympathize with this situation.  However, there exists a 
holy-grail design of process management that is frequently advertised on 
this list, where you have one runscript per persistent daemon, and a 
daemon manager which runs all the daemons as child processes, and 
restarts them if they exit unexpectedly.  And this design is probably 
actually what you want.  So if you're interested in learning something 
new and highly effective for process management, check out the tools 
runit, s6, perp (or, my own recently completed 'daemonproxy').  
Also, runit is available as a busybox applet.


http://smarden.org/runit/
http://skarnet.org/software/s6/why.html
http://b0llix.net/perp/
https://github.com/silverdirk/daemonproxy

While a paradigm-shift could be painful, a quick fix could be as simple 
as having your current process monitor watch an instance of runsv 
instead of udhcpcd, and in turn, runsv would monitor udhcpcd.


Hope that helps.
-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

[Michael Conrad]

On 3/18/2014 3:09 PM, Mike Dean wrote:
Helping them with this usually results in grumbling about it being 
overcomplicated to perform what should be such a simple task.


IMHO, the plethora of unix config file syntaxes are much harder to learn 
than reading a quick manpage (or --help in this case) of the tool you 
want to run.  Where are they going to learn the syntax? Your 
documentation? Random Internet documentation for the real ntpd?  The man 
page for the real ntp.conf is 1700 lines long!


On 3/18/2014 3:09 PM, Mike Dean wrote:
 I personally don't see how this tiny addition represents any 
significant increase to the size of the source tree or the compiled 
binary.


What syntax should be used?  the full ntpd syntax?  Should busybox emit 
errors or warnings on directives it doesn't support?  I can't imagine 
you could add this feature properly in less than 300 bytes, and that is 
significant for busybox.


On 3/18/2014 2:31 PM, Harald Becker wrote:

ntpd -p `cat /etc/timeserver`


I'm inclined to side with Harald that this is the best solution. Can't 
be much simpler for the user than that...


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

[Michael Conrad]

On 3/18/2014 3:54 PM, Mike Dean wrote:

So you're telling me that a plain text script which takes more than 300 bytes 
is a better solution than an option that could be configured out?  But your 
full text option, enabled by default, takes less than 300 bytes I suppose?


I'm not sure I follow.  Harald suggested adding 23 bytes to your 
existing script, and adds the convenience of a config file where there 
wasn't before.


You could add that same minimal config file in C, and it would take a 
lot more than 23 bytes.


Either way, the config file will be a thing specific to busybox ntpd 
and you will have the exact same documentation problem in teaching 
people how to use it, then they have learning about the -p command 
line switch.


If you want to be compatible with a standard tool, and support 
ntp.conf, then you gain the popularly-available documentation, but add 
a significant amount of code.


Neither way is really ideal.  So if you want to add a non-ideal 
solution, it should be done in a distro-specific script.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Running a script every second

[Michael Conrad]

I know this borders on bike-shedding, but if you really want to run 
something exactly 60 times per elapsed minute you need to compare calls 
to clock_gettime(CLOCK_MONOTONIC).  Nothing else will work reliably in 
all cases, and certainly not signals.  (if the system is lagged 
significantly, two signals can be merged into one)


I'm not aware of any way to call clock_gettime from a shell script, but 
Perl can do it.  If you don't have perl and you still want it to be a 
script for ease-of-maintenance, I would recommend:


  1. write a very small C program that calls clock_gettime() for an 
initial timestamp, writes \n on STDOUT, increment timestamp by exactly 
1 second, calls clock_gettime(), and then usleep()s for the difference 
between clock_gettime and timestamp, if greater than 0.


  2. write a script that performs ./c_prog | while read; do 
something(); done


No special file descriptors, process IDs, signals or other mess, and 
guaranteed one iteration of the script per every elapsed second (but no 
guarantee that the execution occurs during that second.  Linux isn't 
realtime, afterall)


-Mike

On 3/6/2014 9:25 AM, Yan Seiner wrote:


On 03/05/2014 10:49 PM, Harald Becker wrote:

Hi Yan !

On 05-03-2014 09:14 Yan Seiner y...@seiner.com wrote:

I am trying to run a script every second.

Beside what Laurent told about using sleep, etc.


first script (the one that does the work)

trap 'update' HUP
mknod /tmp/dummyfifo p
while true; do
 read  /tmp/dummyfifo  /dev/null 21
done
The problem is that the 'read' generates a
/usr/bin/update: line 1: can't open /tmp/dummyfifo: Interrupted
system call

The reason for this is you create your pipe once, but open it
again at every iteration of the loop.

Try the following:

mknod /tmp/dummyfifo p
exec 0/tmp/dummyfifo 1/dev/null 21
while true; do
read
done

This opens the fifo once and assigns it for stdin. After that it
stays open until the first script is terminated in any way.

In addition stdout *AND* stderr are redirected to /dev/null for
all following commands in the script, so you need to redirect to
any file or tty when you want do display something.


Thanks!

I like it.  My solution leaves 'cat' processes behind if the script 
gets killed.  Usually not a problem since it's only invoked at boot.


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Looking for simple ifplugd example script

[Michael Conrad]

On 02/21/2014 05:39 AM, Bryan Evenson wrote:

It means that busybox/examples/var_service/README is badly located, or
badly written, or both.

I found the README you were talking about.  I have never used runsvdir before 
and I don't have it included in my version of Busybox.  I didn't realize that 
Busybox was assuming you'd use runsvdir to run ifplugd, which was the start of 
my confusion.  And since I didn't know that's what was assumed, I didn't think 
to look a couple directories up for a related README.

A little more background on my system.  It's an ARM family processor and I'm 
using the Yocto Project's Poky distribution on my system.  The default image 
for that build uses sysVinit and is setup for ifup/ifdown.


Every distro has a different take on how networking should be handled.  
It isn't practical for busybox to have networking configuration examples 
for every distro.  If you want to make use of ifplugd, you first need to 
understand the design and layout of your distro.  The example configs 
are only meant to help you understand how the tool works.  That said, 
Denys was asking what could be done to the docs to help you on this path.




So if I wanted to use ifplugd, is the suggestion that I include runsvdir and 
runsv in my Busybox configuration and use it to run ifplugd?  I'm unclear what 
runsvdir is doing that sysVinit can't.

If you want sane networking in a non-trivial situation, I think ifup isn't the
tool.

If not ifup, what would you suggest?  I'm open to ideas, just looking for the 
simplest path to get to where I want to go.


While busybox clones many classic tools, there is a sentiment among many 
developers and users that some of these classic tools suffer from design 
flaws and shouldn't be used.


IMHO your best bet for a quick solution is to stick with your distro's 
way of doing things.  But if you have the time for the learning curve, 
the best way to get rock-solid reliability from your system is to toss 
anything having to do with ifup/ifdown or sysvinit or init scripts, 
learn the actual commands and daemons needed for your system to 
function, and put these bare essentials into runit-style scripts.  But 
this is an opinion.



___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] ping: try SOCK_DGRAM if no root privileges

[Michael Conrad]

On 1/10/2014 12:37 AM, Laurent Bercot wrote:


 You're performing too much work copying your argument list. :P
 The wrapper should be entirely transparent: busybox shouldn't
even notice it has been run through it, so it should be called
with the exact same argv. Here's what I do
[...]


If you didn't want to have to maintain the list within the binary, and 
want to depend on the filesystem to declare which applets are allowed, 
you could write the wrapper to stat /bin/$NAME to verify that it (and 
/ and /bin) are

  * owned by root
  * not writable by other users
  * on the root filesystem (compare device number to device number of /)
  * has set-uid bit

This would be authorization-by-the-filesystem that you could rely on, 
and is intuitive to configure.


It's a lot more code to write, but would still be a small binary.

-Mike

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: bnx2 firmware loading?

[Michael Conrad]

On 12/03/2013 09:15 AM, Lauri Kasanen wrote:

Recent kernels can load firmware without userspace help, perhaps you'd
want to backport those changes.
Interesting!  However I like the ability to log which firmware blobs 
were attempted.  Maybe the right fix is a kernel build option to always 
log firmware load attempts.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: bnx2 firmware loading?

[Michael Conrad]

On 12/2/2013 4:58 PM, Michael Di Domenico wrote:

when i try to do a 'modprobe bnx2', it fails with a message saying it
cannot load the firmware files 'bnx2/bnx-firmware-0.6.1b.fw'

however, i do in fact have the firmware files in '/lib/firmware/bnx2'

oddly enough the bnx2 module does load after the 'unable to load
firmware' error messages spit out, but no ethernet devices show up

i'm *sure* i'm doing something wrong, but googling around hasn't shed
any answers

any thoughts or directions?


I use the following script to help debug these sorts of things.

- /sbin/hotplug -
#! /bin/sh
if test -n $MODALIAS -o -n $FIRMWARE; then
echo hotplug: `env | sort`  /dev/kmsg;
fi
test -n $MODALIAS  modprobe $MODALIAS;
exec /bin/mdev $@;
-

It prints to the kernel log, so you can find the output with dmesg or 
the serial console or whatever is convenient.


Hope that helps.

-Mike


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Question about the installation directory of programs

[Michael Conrad]

On 11/8/2013 9:57 PM, ChenQi wrote:
I'm asking this because our project may also need a separation of / 
and /usr. In other words, we need to make sure the system can still 
boot up for recovery and repair even if /usr is missing.


As busybox is an important part of our system, I want to know your 
opinions on this issue.




IMHO, try this:

Install busybox at /bin and /sbin, and install all applets (either 
symlinks or hardlinks) in those dirs.


Create /usr mountpoint.
Make /usr/bin symlink to ../bin
Make /usr/sbin symlink to ../sbin

In your usr partition which gets mounted at /usr, make symlinks for 
each busybox applet to ../../[s]bin/$APPLET


Now, before you mount /usr, you still can access any busybox 
/usr/bin/$APPLET, and when you mount the real /usr, it will hide the 
directory symlinks, but the symlinks to each applet will take their 
place, and you still have access to them.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] init: handle kexec clean reboot

[Michael Conrad]

On 05/22/2013 01:41 PM, Laurent Bercot wrote:


So, as I expected, killall5 is a heavy monster, scanning the process
list in /proc (so, not portable), and killing them one by one unless
they match some criteria. Absolutely ugly, needs some specific tweaks
to support FUSE, and would exhibit a huge race condition if it didn't
SIGSTOP all processes before scanning and SIGCONT them after killing.


Isn't that because killall kills by name?  It would have to scan the process 
list, then.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] init: handle kexec clean reboot

[Michael Conrad]

On 05/22/2013 10:28 PM, Harald Becker wrote:


To grab Laurent's idea: What about a separate shutdown applet in
Busybox:

kill(-1,TERM), sleep, kill(-1,KILL), sleep, umount, sync then
exec into the given remainder of command line? And remove all
special shutdown processing from init process?

Vor easy shutdown we can do: shutdown poweroff -f
... or: shutdown kexec whatever
Since the topic interests people, I figured I'd share a utility I wrote 
recently.  It's designed to be the program that init execs into, and it 
runs a shutdown script with a N second timeout.


https://github.com/silverdirk/failsafe_shutdown

Its purpose is to make sure that the system goes down, and doesn't get 
hung permanently due to unexpected situations.


If the child script doesn't complete, or exits with an unexpected value, 
it does the usual kill, remount-ro, sync, reboot.  As a convenience, 
it allows the script return value to determine which reboot action is 
called.  (though the script can perform its own reboot call)


Also, does anyone happen to know if there is a way to activate the 
sysrq_trigger actions through a syscall, without needing /proc mounted?


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: CTRL-ALT-DEL not working as expected. Seeking for advices

[Michael Conrad]

On 03/29/2013 11:56 AM, Harald Becker wrote:

Hi Denys !


Hence my suggestion to add this sigprocmask to unblock all signals
*AND* restore all signal actions to there default as part of the
cttyhack applet.

I would like to hear people confirming that kernel indeed blocks
ant signals to pid 1. Which kernel version does that?


Linux 3.0.0 and 3.6.11 do not mask any signals.

And it's easy to find out!

   /root # gcc init-debug.c
   (see attached init-debug.c)

followed by editing grub's boot line during a reboot:

   kernel (hd0,0)/vmlinuz-... root=/dev/sda2 init=/root/a.out

revealing

   SigPnd:
   ShdPnd:
   SigBlk:
   SigIgn:
   SigCgt:
   CapInh:
   CapPrm:
   CapEff:
   CapBnd:

Meanwhile, the man page for kill (2) says:

   The only signals that can be sent to process ID 1, the
   init process, are those for which init  has  explicitly
   installed signal handlers.  This is done to assure the
   system is not brought down accidentally.

So perhaps the confusion is that Linux is simply not delivering
the signal (regardless of sigprocmask) unless you install a signal
handler.  I question whether anyone would actually want to write a
shell script with signal handling to act as init...  that seems
messy and error prone.

Anyway, this little test also reveals that (as I thought I remembered)
you have to make a special syscall to get the ctrl-alt-del behavior.
Namely,

   reboot(RB_DISABLE_CAD);

causes the system to stop instantly rebooting when ctrl-alt-del is
pressed, and instead send SIGINT to pid 1.  I'm not even sure if
there is a command-line access to this call.  I've only ever done
it from C.


   setting on entrance. So the central place to trow that signal
   unblocking/default action restoring is the place used to startup the
   shell, usually the cttyhack applet.

- Restoring signal actions to there default and unblocking doesn't
   harm if it's done without being required. It just waste some
   time/code space, but avoids lengthy debug sessions due to blocked
   signal handling.


Can you name any actual cases where busybox caused signals to be
blocked?

Again, I'm suspecting that the real problem all along was either a
missing call to reboot (2) or not installing a handler and causing
the kernel to not deliver the signal.

-Mike


#include stdio.h
#include sys/fcntl.h
#include sys/mount.h
#include string.h
#include signal.h

void sig_handler(int sig_num) {
	fprintf(stderr, Caught signal %d\n, sig_num);
}

int main() {
	char buf[4096];
	int fd, got, i;
	struct sigaction sa;

	if (mount(proc, /proc, proc, 0, ) != 0)
		perror(mount(proc));
	if ((fd= open(/proc/1/status, O_RDONLY))  0)
		perror(read(/proc/1/status));

	got= read(fd, buf, sizeof(buf));
	sleep(5);
	write(1, buf, got);

	memset(sa, 0, sizeof(sa));
	sa.sa_handler= sig_handler;
	for (i=0; i64; i++)
		if (sigaction(i, sa, NULL)  0)
			fprintf(stderr, Can't listen to signal %d\n, i);

	fprintf(stderr, Entering infinite loop\n);
	while (1)
		sleep(999);
}

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: CTRL-ALT-DEL not working as expected. Seeking for advices

[Michael Conrad]

On 03/30/2013 05:34 AM, Laurent Bercot wrote:


So perhaps the confusion is that Linux is simply not delivering
the signal (regardless of sigprocmask) unless you install a signal
handler.

  No, this is not the problem. Every shell in the world traps SIGINT.


Hm, true...  but then the problem you actually have is that there
might be signals that the shell is allowing to be delivered that you
didn't expect.


I question whether anyone would actually want to write a
shell script with signal handling to act as init...  that seems
messy and error prone.

  Lots of people do that, and for good reasons: see
  http://skarnet.org/software/s6/s6-svscan-1.html


You make great arguments for stage 1 and 3, but it still seems a
shell is ill-suited for stage 2.  You would have to handle any
signal where you didn't want the shell's default behavior, and
if I remember right, there was also a trick needed to get the
shell to reap zombies.

It just seems too easy to write a tiny C program that
  1 - launches a supervisor
  2 - reaps zombies
  3 - runs a script when it receives signals
  4 - execs stage 3 when the supervisor exits

Not to mention the large number of supervisor programs that
already do this.

I use shells as init sometimes, but mostly just for diagnostics.


I'm not even sure if there is a command-line access to this call.

  echo 0  /proc/sys/kernel/ctrl-alt-del


Ah, nice.

-Mike

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: CTRL-ALT-DEL not working as expected. Seeking for advices

[Michael Conrad]

On 03/30/2013 01:58 PM, Ralf Friedl wrote:
The kernel is never compiled with an initramfs. The kernel is often 
compiled to use an initramfs, if the boot loader supplies one.


Actually, check kconfig for newer kernels.  They have an option to 
automatically create the cpio archive from a directory of your choice 
and build it directly into the kernel image.  I used this for a while 
because it seemed convenient, but then decided I'd rather decouple the 
kernel from the initrd so I could mix  match (and do things like 
init=/bin/sh).  I imagine it makes life easier for people with limited 
bootloaders, or people making advanced use of kexec.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: busybox will not run any other binary - configuration issue on my end

[Michael Conrad]

On 3/12/2013 1:39 PM, Paul Smith wrote:

On Tue, 2013-03-12 at 12:35 -0400, q5sys wrote:

however when I try to start any other program, like another shell for
example, zsh, bash, etc. Busybox returns that the command is not
found.

The kernel tries to invoke the proper ld.so but can't find it, so it
gives this very cryptic error message.


The short version: You're probably trying to run a dynamic-linked 
program and missing a library.  Run ldd to find out.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: BeagleBone for ALSA jackd

[Michael Conrad]

On 10/24/2012 8:53 AM, Grant wrote:

I would like to build as minimal of a system as possible on a
BeagleBone.  I only need ALSA and jackd to work.  Would this work well
with busybox?  I'm very familiar with Gentoo but a system like this
would be set up entirely outside of the Gentoo framework?


Gentoo makes for a great system to create lightweight builds.  You can build
a minimal build with something like:

 ROOT=/tmp/somewhere emerge -v baselayout uclibc busybox

The details are slightly more complex, eg I tend to use a uclibc based
chroot with hardened compiler, etc, you will need a cross compiler setup,
but very roughly that's about all you need...

I already have Gentoo on an SD card running on the BeagleBone so I
wouldn't need a cross compiler.  Could I do the above, copy
/tmp/somewhere to / on another SD card, set up /boot, and boot?  It
couldn't be so easy :)


Well, this is on the verge of being more appropriate for the Gentoo 
forums, but I figured I'd mention my technique for building my 
busybox-based car computer.


Start by building busybox (statically linked), and building a system 
image consisting of a standard directory tree, a bunch of busybox 
hardlinks, and a small handfull of files in /etc.  Find any Linux that 
runs on your target platform.  Steal their kernel. (and needed modules)  
Make it boot.  (have to write your own init scripts.  I suggest runit 
since it's built into busybox, but perp and s6 are also nice)


You now have a bootable Linux system in the ballpark of 4MB.

Get a Gentoo stage-3 image for your platform.  For best results, put the 
stage-3 image on a nice file server and NFS-mount it onto the target 
platform.  (which is a little involved, but worth it, IMHO. This gives 
you an easy way to make backups and copies or even add it to version 
control.)  chroot into it and emerge all the packages you need.


(trying to do the same on x86 and cross-compiling will waste a bunch of 
your time and drive you slightly insane, unless you enjoy debugging 
autoconf scripts)


Once you have the chrooted Gentoo system behaving as you like, write a 
perl script that copies out *only* the files you need, (excluding 
binaries replaced by busybox) and place them into the mostly-empty 
system you created earlier.  Gentoo has the nice /var/db/pkg files to 
help you find all of a package's files.  Exclude packages like 
baselayout.  Then exclude some directories like /etc and 
/usr/share/doc.  (you want to very carefully craft your own /etc)


Then take the result and copy it to a USB stick, and boot off of it.

For bonus points, take the result and play the symlink-to-tmpfs game and 
then make the image a read-only squashfs image, and use that as the 
system root.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] Add xorpipe utility

[Michael Conrad]

On 9/12/2012 10:42 PM, j...@jodybruchon.com wrote:

My rationale behind writing this simple utility is as follows: Moving data
through a fully encrypted tunnel like SSH is too slow for me, so I use
netcat/socat for moving large chunks of data between systems. I don't want the
data to be easily identified and reproduced if it is somehow intercepted, though
it's also not a major problem if someone goes through the trouble of decrypting
it; thus, simple XOR encryption is good enough for my purposes and is also
extremely fast. I'm sure someone else will find it useful, and given its
minuscule size, it is of negligible cost to include.


I apologize for further sidetracking the conversation, but if I were 
going to write a quick-n-dirty encryption tool I would pick a 32-bit int 
and then XOR with a pseudo-random sequence generated from it. That would 
at least give the attacker a mental challenge (unless they knew the 
first 4 bytes of the data...)  Maybe also add a salt parameter?


  while (more_data) {
data[i]= data[i] ^ key ^ salt;
key= key * a + c;
  }
(http://en.wikipedia.org/wiki/Linear_congruential_generator)

Integer multiplication is pretty cheap on most hardware.

-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [vamos-dev] [PATCH 1/3] fix literal error warning

[Michael Conrad]

On 9/10/2012 11:46 AM, Michael Tokarev wrote:

On 10.09.2012 19:31, Manuel Zerpies wrote:

Hey guys,

what about this patch? Is there anyone who can have a look at it?


[]

-   bb_perror_msg(filename);
+   bb_perror_msg(%s, filename);

Please stop fixing a non-issue.  This GCC warning is wrong.
This has been discussed several times, and exactly the same
patch has been proposed several times too.


Actually, that half of his patch *is* legitimate.  It's a bug.

  $ ./busybox stat -f %s
  stat: (null): No such file or directory

It's only on the SELINUX enabled binary.

Here's the full context:

#if ENABLE_SELINUX
security_context_t scontext = NULL;

if (option_mask32  OPT_SELINUX) {
if ((option_mask32  OPT_DEREFERENCE
 ? lgetfilecon(filename, scontext)
 : getfilecon(filename, scontext)
)  0
) {
bb_perror_msg(filename);
return 0;
}
}
#endif
if (statfs(filename, statfsbuf) != 0) {
bb_perror_msg(can't read file system information for 
'%s', filename);

return 0;
}

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [vamos-dev] [PATCH 1/3] fix literal error warning

[Michael Conrad]

On 9/10/2012 12:36 PM, Michael Conrad wrote:

On 9/10/2012 11:46 AM, Michael Tokarev wrote:

On 10.09.2012 19:31, Manuel Zerpies wrote:

Hey guys,

what about this patch? Is there anyone who can have a look at it?


[]

-bb_perror_msg(filename);
+bb_perror_msg(%s, filename);

Please stop fixing a non-issue.  This GCC warning is wrong.
This has been discussed several times, and exactly the same
patch has been proposed several times too.


Actually, that half of his patch *is* legitimate.  It's a bug.

  $ ./busybox stat -f %s
  stat: (null): No such file or directory


Furthermore, it could potentially be used in an exploit.  Suppose 
someone has a CGI script that runs stat -f on a requested file, and an 
attacker can see the error output.


The attacker can inspect the stack using %d %d %d %d %d %d... and then 
maybe find a suitable pair of integers in the stack for %.*s, which 
could be used to dump out the memory of the busybox process, either to 
prepare a different exploit, or to possibly dump environment variables 
containing passwords or configuration settings.


Luckily, it only affects SELINUX platforms.
(oh the irony)

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: shell parsing bug with

[Michael Conrad]

On 09/07/12 01:00, Rich Felker wrote:
 On Fri, Sep 07, 2012 at 06:50:48AM +0200, Harald Becker wrote:
 Sorry if it sound provocative, I'm just interested/wondering what/why
 are you doing here. Nothing more.
 I'm not doing it. I'm just uncomfortable with having a shell that will
 misinterpret conforming, albeit obfuscatd, shell scripts from third
 parties, and was giving one such example. I suspect the main place
 such code might come from a is a script that obfuscates and/or removes
 all unnecessary whitespace from a given shell script.

Would you happen to be the poor sucker tasked with writing that tool?  I
feel for you :-)

A tool like that would be up against all the deviations from the
standard that occur on countless shell versions throughout history that
exist across different flavors of UNIX.  Just look at the autoconf
project- they don't even use functions, for sake of compatibility.  Also
keep in mind that the standard was created long after the shells, in an
attempt to move them toward a common syntax.

Also, I think such a tool would have to handle Bash anyway, since it's
one of the most prevalent shells out there.  (also a number of distros
have bash masquerade as sh, which *should* make it conform to POSIX, if
you're lucky)

-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: httpd w/PHP performance

[Michael Conrad]

On 6/21/2012 8:39 AM, Gary Altenberg wrote:

On 6/21/2012 5:01 AM, Laurent Bercot wrote:



There might also be some downsides to repeated alloc/free in the
embedded environment.
  Not at all. As long as you have enough memory to serve the 
requests, and
dynamic allocations are kept to a reasonable level, there's no 
problem in

performing several of them in an embedded environment. If anything, the
fork+exec approach makes memory management easier on the programmer (and
on the kernel to some extent) since every exec and every process death
trigger automatic garbage collection for the late process.


Doesn't this depend on what CPU you are using? If you are using a NO 
MMU CPU doesn't a lot of alloc/free calls leave your memory very 
fragmented?




Not if you free *everything* when you're done.

(It's a moot point anyway, since PHP runs every request with a fresh 
variable-space, and the strategies of deallocate everything and 
exit/fork-a-new-process are nearly identical)

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: httpd w/PHP performance

[Michael Conrad]

On 6/21/2012 6:01 AM, Laurent Bercot wrote:

I have an application that runs well using lighttpd with PHP. In an effort
to reduce the memory footprint I tried porting it to the busybox ( 1.20.1 )
httpd. It was easy to get this working and it seems to work properly. What
isn't good enough is performance when executing PHP scripts. It looks like
the httpd is using fork/exec for each cgi, and that fork/exec can use a lot
of CPU.

  httpd itself, and on a fast machine with a decent OS, fork/exec themselves,
don't use *that* much CPU. I suspect that your bottleneck might be the
startup time of the PHP interpreter, since busybox httpd is indeed spawning
a new PHP intepreter per request.


$ time perl -e '$i=1000; system(sh,-c,) while $i--;'

real0m1.213s
user0m0.004s
sys 0m0.120s

$ time perl -e '$i=1000; system(perl,-e,) while $i--;'

real0m1.845s
user0m0.012s
sys 0m0.112s

$ time perl -e '$i=1000; system(ruby,-e,) while $i--;'

real0m35.341s
user0m28.954s
sys 0m3.176s

$ time perl -e '$i=1000; system(php,empty.php) while $i--;'

real2m25.559s
user2m18.189s
sys 0m6.000s


This is probably because PHP doesn't use modules, and links to 
*everything* it has compiled support for.  PHP is linked against 41 
libraries on my system.  The startup cost is probably just the dynamic 
linking and initialization of libraries.  (To be fair, other scripting 
languages would take longer to load than PHP if you loaded all those 
modules.)


George:  you might want to try recompiling php with the minimum features 
needed for your application, and maybe linking with uClibc .  It will 
help in the CGI case, but also help your memory usage if you use 
lighttpd and a pool of php processes.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Mounting Filesystem over existing directory

[Michael Conrad]

On 06/04/2012 10:06 AM, Laurent Bercot wrote:
 Is that correct. In my system i can update the kernel boot args. But i
 believe that if the mounting of the root partition fails then the
 kernel will panic.
  You can do some basic tests before rebooting, including whether the
 mounting works (mount /dev/something /mnt/test) and whether the new
 firmware looks like something you actually made
 (chroot /mnt/test /bin/true  /bin/verify /mnt/test/somepublickey)

  If all else fails, you should have a hardware watchdog that reboots
 the device when the kernel's gone fishing, and your bootloader will
 then fall back on the old rootfs.

I would think you'd want to use kexec to test the new image, then if it
panics, the nvram is unchanged and it will reboot into the regular
partition.  If the kexec'd system boots up, and knows that it is testing
an update, then it can be the one to write the changes to the nvram so
that it is used from now on.

-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Mounting Filesystem over existing directory

[Michael Conrad]

On 5/31/2012 2:04 AM, Bartos-Elekes Zsolt wrote:

Michael Conrad wrote:

Unionfs has one problem though: the only way to get correct behavior 
is to merge path A and B onto mountpoint C.  (C can't be the same as 
A or B).


Perhaps this is valid only for older versions of unionfs. I am using 
unionfs mounted on /var that is composed of a tmpfs mounted on 
/mnt/tmpfs, and the original /var that is on the flash (containing 
only a few important files and directories that must be preserved 
across reboots, like /var/lib/dpkg).


$ mount | grep unionfs
unionfs on /var type unionfs (rw,relatime,dirs=/mnt/tmpfs=rw:/var=rw)


...

On 6/1/2012 3:24 AM, Sameer Naik wrote:


With UnionFS-2.5.11 i could merge /var/cache/etc=rw and /etc=ro at
/etc. But evidently i have no real world testing going on here. Is
there any specific test case i should try to confirm this?


I think I was remembering it wrong.  I think my actual problem was 
because I was trying to put the union on /, and so the source of the 
union was *under* the mount-point.  And who knows, this might work now too.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Mounting Filesystem over existing directory

[Michael Conrad]

On 6/1/2012 2:42 AM, Laurent Bercot wrote:

Out of curiosity, Is is possible to free up the resources used by
initramfs. I would be very interested in knowing how this can be done.
Initramfs is really just a tmpfs which the kernel copies files into at 
boot-time.  You free it by removing all files from it, and unmounting it 
(after switch_root, because you can't unmount /).


My initramfs was only 5MB (busybox, rsync, dropbear-sshd, some symlinks 
and a script) so I didn't care.  I want busybox loaded into ram for the 
entire life of the system, so I could just rm the others to reclaim a 
tiny bit of ram and that's pretty much optimal for me.



In my case, i am developing a system for an embedded system with NAND
storage. Due to NAND corruption issues that mostly arise right now is
when system is powered off while NAND writes are being performed (i.e.
when files are being flushed out to the filesystem). This corruption
makes the system un-bootable. Due to this issue i want to make the
NAND filesystem readonly. Only at the time of system updates the
filesystem will be remounted in rw mode. This still leaves room for
the corruption to occur during system updates.

  There's only one way to guarantee bootability even with updates:
have *two* read-only partitions for the rootfs. Boot on one; when you
download an update, write the binary file to the other one. Reboot. If
it boots, use the new partition as your new rootfs; if not, fall back
on the old one (it still works) and report a failure.

Right now i am thinking of having a initramfs filesystem with a
recovery system that starts a device recovery process if the system
partition cannot be mounted. So the intention is:

  You can do that, but that means your device will be non-functional
(i.e. stuck in recovery mode) at the first failing update. (And trust
me, failing updates WILL happen.) Your users will complain, and
rightfully so.
  Better have two rootfs partitions so you can always guarantee that
one of them boots into a functional system.


Interesting.  But where do you have the logic for choosing a boot 
device?  What if your new partition is fine, but core services fail to 
load?  How do you recognize that you need to start over with a different 
root partition?


My case is also an embedded system.  I just wanted reliability, system 
updates from USB drive, and the ability to power-off the system without 
notice (thus mounting read-only).  My init script mounts all the USB 
devices looking for a system update (squashfs file), and if it finds one 
it mounts the main partition read/write and uses rsync to copy the image 
to the local drive, then unmounts everything.  Then, it mounts the main 
partition read-only, creates the union, and execs 'init'.  In practice, 
it runs very fast, especially if no USB devices are present.


If anything goes wrong with the new version, I just pop in a USB drive 
with the old version.  The initramfs is simple enough that it never 
needs changed.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Mounting Filesystem over existing directory

[Michael Conrad]

On 5/30/2012 3:08 AM, Sameer Naik wrote:

Thanks for the quick response. I will check out the links Bartos provided.
Certainly, my query is not related to busybox, but where else can i
find a better community for my query :)

Regards
~Sameer


Indeed, you're posting your question to a lot of people who have done 
this exact thing :-)


I found aufs to be more experimental with lots of fancy features... but 
wasn't stable enough for me.  (this changes over time and by kernel 
version, of course, but when I tested it 3 years ago I got some strange 
results)  Unionfs has worked flawlessly for me on multiple kernels.


Unionfs has one problem though: the only way to get correct behavior is 
to merge path A and B onto mountpoint C.  (C can't be the same as A or B).


What I came up with was to use the rootfs that Linux creates for the 
initramfs, and have the following symlink pattern:


/etc - /union/etc
/bin - /union/bin
...
/union/etc - /initrd/etc
/union/bin - /initrd/bin
...
All of that lives in the initramfs and is loaded immediately.

Then, I mount the system image at /sysimage, and then

mount -t unionfs -o dirs=/initrd=rw:/sysimage/fhs=ro none /union || die 
Failed to set up unionfs;


This hides the second level of symlinks and uses the unionfs 
*atomically*, and since I'm using the rootfs, I don't have to mount my 
own tmpfs or switchroot or anything like that.  Also, my system uses the 
one busybox binary that it loaded out of initramfs for the entire life 
of the system, so no need to worry about freeing up the resources used 
by the initramfs.


Also, the entire system becomes writable, and if I want to know what I 
changed I can just rsync /initrd to my development machine and see what 
new files exist, and integrate them into my next system image.  I can 
also selective revert things to default while the system is running by 
deleting files out of /initrd.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Possible change to /etc/mdev.conf default?

[Michael Conrad]

On 05/14/2012 01:45 AM, Walter Dnes wrote:
 On Sun, May 13, 2012 at 05:47:15PM -0600, Michael J. Hammel wrote
 On Sun, 2012-05-13 at 18:14 -0400, Walter Dnes wrote:
 I was spelunking through my /etc/mdev.conf, looking at the syntax,
 when something occured to me looking at...

 sr[0-9]*root:cdrom 660 @ln -sf $MDEV cdrom

   What happens if you have multiple devices, e.g. sr0 and sr1?  Does
 the system get confused?  Would the following work better...

 sr[0-9]*root:cdrom 660 @ln -sf $MDEV cdrom%1
 I don't think mdev handles that syntax but it would be trivial to
 replace the ln command with a script that simply parses the number
 (srnum) from MDEV and performs the same function as you suggest.
   Out of sheer curiousity, what do %1 and %2 do as shown on
 http://git.busybox.net/busybox/plain/docs/mdev.txt which seems to be
 somewhat different from the default /etc/mdev.conf on my machine.


FEATURE_MDEV_RENAME_REGEXP

mdev *does* do what you want.  Notice that you need parentheses (like in the 
example) for regex capturing.  (and the feature needs to be enabled of course)

-Mike

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: OTP feature for /bin/login

[Michael Conrad]

On 5/8/2012 6:56 PM, Rich Felker wrote:

On Tue, May 08, 2012 at 05:38:26PM -0400, Michael Conrad wrote:

  With the little amount of thought I've done on it so far, I've concluded
that a viable system would have to have executables instead of shared
objects as atoms, i.e. the /bin/login program configurably executes into
/bin/login-X-mechanism, where X can be passwd, OTP or anything of the
kind, and /bin/login-X-mechanism does the X-specific work.


+1

Call them Busybox Auth Helpers and the API is as simple as read
$username\n$password\n from stdin, and return 0 or 1.  Serves
everyone's needs in about 20 lines of code added to busybox.  All
configuration and selection of which accounts are affected can be
written into a Multiplexor which obeys the same API.  You could even
write an auth helper that dynamically links out to PAM.

A *good* OTP system (I'm not sure how good the submitted one is) needs
bidirectional communication for login. For a printed sheet of
passwords, the host has the ask the user for a specific number off the
sheet, not just any password, so the authentication method needs a way
to present this information to the user. Or if you have a device on
the client side that can generate passwords based on a challenge from
the host, you need a way to present the challenge to the user when
they attempt to login (so they can enter it in their device).


My thought here was that you can't always alter the original protocol 
that much (httpd, ftpd, etc).  If you can and need to, then you might as 
well just write a custom daemon  (which actually, is exactly what you're 
describing below with the ssh passthrough) or use PAM.  Writing a 
one-size-fits-all authentication API is not a simple thing, and I think 
any attempt to do so would end up as complex as PAM.


The OP was describing a system where you'd have your phone 
time-synchronized with the server, and be unidirectional.  Your phone 
knows what the correct password is at any given time.



It could be as simple as checking getenv(BUSYBOX_AUTH_HELPER), or
hard-coded busybox config string.  If it doens't exist, fall back to
passwd/shadow.

Letting this be configured by the environment is a gaping security
hole...


I was about to say not any worse than LD_LIBRARY_PATH, but I suppose 
then it would need the same special restriction for setuid programs.  
(It would just require a check of geteuid... but you're right, probably 
better to forget it and either use a config file or hard-code it.)


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Dangerous behaviour of mktemp when unknown flags are used

[Michael Conrad]

On 04/17/2012 02:30 PM, Rich Felker wrote:
 On Tue, Apr 17, 2012 at 03:48:20PM +0200, Denys Vlasenko wrote:
 On Tue, Apr 10, 2012 at 4:24 AM, John Spencer
 maillist-busy...@barfooze.de wrote:
 (this is busybox 1.19.2)

 /src/build/zlib-1.2.6/Makefile:tempfile := $(shell mktemp -u __XX)

 mktemp: illegal option: u
 BusyBox v1.19.2 (2012-04-08 20:17:39 GMT) multi-call binary.

 Usage: mktemp [-dt] [-p DIR] [TEMPLATE]

 

 zlibs Makefile uses mktemp -u without testing if it returns a result and
 then happily uses the variable to delete and create stuff.

 i don't think it's a good idea that the binary doesn't ignore (or only warn
 about the wrong config on stderr) and still return some usable string to the
 caller.
 It doesn't return anything:

 $ busybox mktemp -u 2/dev/null
 nothing
 $

 The entire output went to stderr. None is on stdout.
 This is as correct handling of unknown option as it can get.
 That's the entire issue he was reporting. Since the normal usage of
 mktemp with -u is something like var=$(mktemp -u), it's very dangerous
 for the output to be an empty string. It's possible to check for
 errors, and one probably should, but plenty of low-quality scripts
 don't and the shell does not make it particularly easy to do so. (The
 simplest solution I can think of for a script would be

 var=$(mktemp -u || echo /dev/null/invalid/path)

 where the fallback is chosen to be something that's guaranteed by
 POSIX not to work.
Considering that mktemp has an inherent possibility of failure, I think
checking failure of the command is the *only* correct usage.  And it
isn't hard at all: You can check $? or test the length of the variable
or set a default on the next line.  Makefile are less convenient, but as
you showed, it isn't hard.

Also, why is it so dangerous?  It doesn't exist, so you have to create
it, and mkdir and touch and shell redirection all fail with a missing
argument.  (ending the make process, if you've written the makefile
correctly) and you'll have a handy message on stdout to help you find
the problem.

-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] arpping in udhcpc

[Michael Conrad]

If you both look closely at the function in question (monotonic_ms) 
you will see that it is already 64-bit, and using the linux 
CLOCK_MONOTONIC which is never affected by changes to the system time.


Adrian is correct that the 'long long' return of monotonic_ms is being 
stored in a 'unsigned', but the existing implementation seems perfectly 
correct as long it doesn't sleep continuously for more than 49 
real-world days. (and it doesn't because the timeout is hard-coded at 
2000ms)


I think the safe_poll function is much more suspicious:

/* Wrapper which restarts poll on EINTR or ENOMEM.
 * On other errors does perror(poll) and returns.
 * Warning! May take longer than timeout_ms to return! */
int FAST_FUNC safe_poll(struct pollfd *ufds, nfds_t nfds, int timeout)
{
while (1) {
int n = poll(ufds, nfds, timeout);
if (n = 0)
return n;
/* Make sure we inch towards completion */
if (timeout  0)
timeout--;
/* E.g. strace causes poll to return this */
if (errno == EINTR)
continue;
/* Kernel is very low on memory. Retry. */
/* I doubt many callers would handle this correctly! */
if (errno == ENOMEM)
continue;
bb_perror_msg(poll);
return n;
}
}

So if it gets hit with a signal that causes EINTR, it subtracts 1 
millisecond and tries again, regardless of how much time actually elapsed???


-Mike

On 4/11/2012 12:45 PM, Cathey, Jim wrote:

Is not one of the ways to manage delta-time
timeouts to use uptime() instead of time()?
You don't care what time it is, you only want
to manage a timeout on the order of seconds,
so a monotonic time source like uptime() is
actually preferable.

It seems to me that 64-bit math is unnecessarily
punitive, especially for many embedded processors.

Also, DST doesn't affect the value of time()
et al. at all, or should not.

-- Jim

-Original Message-
From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net]
On Behalf Of Adrian Szyndela
Sent: Wednesday, April 11, 2012 1:41 AM
To: busybox@busybox.net
Subject: [PATCH] arpping in udhcpc

Hi,

I'm attaching a patch for way too long wait on poll() during arpping
after IP address acquiring over DHCP.

It happens on a platform which starts with Epoch time. Then, at some
point, a correct time source appears, and an actual time is set.

If an actual time is set during wait on poll(), computing of a timeout
overflows on unsigned type. The patch just changes types to stay with
long long computing.

Before applying the patch the side effect of setting an actual time is
close to hangup - with no IP address assigned. After applying the patch
the side effect of time change is that poll() might wait shorter than
desired 2 seconds in case of socket activity.

I found a comment /* We don't expect to see 1000+ seconds delay,
unsigned is enough */ in networking/arping.c (which probably is affected
by the problem as well). The above case introduces 10+ seconds
delay :). 3600 seconds at daylight saving time change is a piece of
cake.

Regards,
Adrian

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] ash: setsid and TIOCSCTTY when enabling job control.

[Michael Conrad]

Would this have an effect on scripts being used as init which did not 
previously have a controlling terminal?  There are quite a few commands 
which change behavior when run with/without a tty.


(the usual fix for enabling job control is to run agetty in your init 
script)


-Mike

On 3/12/2012 7:56 PM, Avery Pennarun wrote:

Both calls will fail if we are already a process group leader, or the
process group leader is not us, or we already have a controlling terminal.
So basically these calls are harmless in the worst case, and get rid of the
annoying can't access tty; job control turned off problem in the best
case.  In other words, CTRL-C and CTRL-Z will work.

This makes busybox sh job control usable with init=/bin/sh on the Linux
kernel command line.
---
  shell/ash.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/shell/ash.c b/shell/ash.c
index 5671a52..5259dd2 100644
--- a/shell/ash.c
+++ b/shell/ash.c
@@ -3727,6 +3727,8 @@ setjobctl(int on)
if (fd  0)
goto out;
/* fd is a tty at this point */
+   setsid();
+   ioctl(fd, TIOCSCTTY, 0);
close_on_exec_on(fd);
do { /* while we are in the background */
pgrp = tcgetpgrp(fd);


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: do stuff after shutdown

[Michael Conrad]

On 2/23/2012 7:59 PM, Laurent Bercot wrote:

You mean process 1. ;)


Right :-)  Whose idea was it to count from 1, anyway?


[ Side note : panicking when process 1 exits is a *very* silly thing
for the kernel to do. Process 1 exiting, instead of being forbidden,
should mean the end of the machine's life cycle, and the kernel should
either halt, reboot, or even kexec something else, depending on process
1's exit code. But that is totally off-topic. ]


I agree.  But they probably have hard-coded assumptions about process 1 
always existing in the process table or something.


Speaking of kexec though, that reminds me: if someone wanted to run an 
unknown distro (like from a iso image or something) and then clean up 
afterward, you could run your own init, start the distro as normal, 
receive its shutdown request, mount read-only, sync, etc, and then kexec 
into a new kernel with an embedded busybox to run a cleanup script.


You can also install a panic-kernel, to be kexec'd any time the kernel 
crashes.  I think that's a pretty killer feature.  In fact you could 
install the panic-kernel with the embedded cleanup script, and then 
deliberately exit from your init at shutdown ;-)


And none of this has the slightest thing to do with busybox. ;) 
Other than that people who play with busybox are often trying to do 
hackish things like these :-)  I felt obligated to answer since I had 
started into embedded linux with many of the same questions as the OP.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: do stuff after shutdown

[Michael Conrad]

On 2/23/2012 4:52 PM, Michael Di Domenico wrote:

I have a busybox system booting over pxe, it does some stuff and then
eventually boots up my main linux distro.  my question is; when i'm
done with my main linux distro, is it possible to run commands back in
the busybox shell after the switchroot completes/returns?

does it move stuff back and let you continue to run a command or two,
or is the environment trashed requiring a reset of the box.  my
inclination from the code is that it's trashed, but i just want to
make sure


If the init process exits, the kernel panics.  Therefore no normal 
distro will ever have an init that returns to its caller.  (also, if you 
didn't exec into the new init, then it wouldn't be process 0, and could 
cause you problems)


switchroot allows you to free up the initramfs, but you don't have to 
use it.  You could actually run your own init process and chroot your 
distro's startup scripts (effectively chrooting everything else in 
userspace), and play games with symlinks to /lib/modules but at 
shutdown your distro will still call reboot() at the end which go 
straight to the kernel, and not to any script outside the chroot.


Most likely you want to alter the shutdown scripts of your distro.

-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox