mdev scripts

[David Henderson]

Good afternoon all!  I was interesting in migrating from udev to mdev,
but had some concerns.  As I have been compiling packages along the
way for the repo, I have noticed that some packages include a udev
rules file, but no mdev (since it is probably used much less than
udev).  Does anyone have or know of a collection of mdev scripts to
fully replace udev?  I have come across the mdev-like-a-boss
collection, but haven't had too much time to fully look into all the
scripts it includes.  Any help or guidance would be appreciated!

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

Re: Race in reboot/poweroff path at init?

[Denys Vlasenko]

On Tue, Oct 10, 2017 at 10:52 AM, Jeremy Kerr  wrote:
> Hi all,
>
> I've been debugging an issue where we can't reboot or poweroff a machine
> in the early stages of busybox init. Using the poweroff case as an
> example:
>
>  - kernel starts /sbin/init
>
>  - kernel receives a poweroff event, so calls __orderly_poweroff.
>Effectively, these will just call out to the /sbin/poweroff usermode
>helper.
>
>  - /sbin/poweroff just does a:
>
>  kill(1, SIGUSR2);
>
>  - However, /sbin/init has not yet installed a signal handler for
>SIGUSR2. Because we're PID 1, this means the signal is ignored, and
>so the command to poweroff the machine is dropped.
>
>  - init keeps booting rather than powering off.
>
> In our particular case, the "poweroff event" is an IPMI soft shutdown
> message. However, the same would apply for any other path that involves
> orderly_poweroff or orderly_reboot.
>
> Even though the signal handlers are installed fairly early in init, we
> can still hit the race between this and the SIGUSR2 being sent fairly
> reliably.
>
> I see a couple of options for resolving this:
>
>  - installing the signal handlers even earlier in init_main(). However,
>this will only reduce the window for lost events, rather than
>eliminating it; or

Sure, this should be done. How about this:

--- a/init/init.c
+++ b/init/init.c
@@ -1064,6 +1064,12 @@ int init_main(int argc UNUSED_PARAM, char **argv)
 #endif

 if (!DEBUG_INIT) {
+/* Some users send poweroff signals to init VERY early.
+ * To handle this, mask signals early,
+ * and unmask them only after signal handlers are installed.
+ */
+sigprocmask_allsigs(SIG_BLOCK);
+
 /* Expect to be invoked as init with PID=1 or be invoked as linuxrc */
 if (getpid() != 1
  && (!ENABLE_LINUXRC || applet_name[0] != 'l') /* not linuxrc? */
@@ -1204,6 +1187,8 @@ int init_main(int argc UNUSED_PARAM, char **argv)
 + (1 << SIGHUP)  /* reread /etc/inittab */
 #endif
 , record_signo);
+
+sigprocmask_allsigs(SIG_UNBLOCK);
 }

 /* Now run everything that needs to be run */

This covers code which opens and parses /etc/inittab,
which can be slow (if storage is slow), and can make
race realistic in real world.

Can you test whether this change makes the race go away in your case?

>  - using a synchronous channel to send the shutdown/reboot message
>between the poweroff/reboot helpers, rather than an asynchronous
>signal. Say, have init listening on a socket, allowing the poweroff
>binary to wait and/or retry.
>
> However, before I go down the wrong path here: does anyone have other
> ideas that might help eliminating dropped poweroff/reboot events?

The test that processes are being reaped is a good idea.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: NOEXEC environment bug

[Ralf Friedl]

Jack Schmidt wrote:

On 2017-11-02, at 08:26 , Denys Vlasenko  wrote:

On Wed, Nov 1, 2017 at 2:28 AM, Jack Schmidt  wrote:

I believe I have found a bug in the current version of busybox.

When:
* an applet is marked NOEXEC,
* busybox is configured with CONFIG_FEATURE_SH_STANDALONE=y, and
* busybox's ash is asked to do "ENV_VAR=newval no_exec_app"
Then the no_exec app is not called with the new environment.

This affects git master d5c1482fbac71c51e3add52632cdf1f9f9e6661b and 
1:1.21.0-1ubuntu1

To reproduce from git (on linux):

git pull
make defconfig
sed -i 's/# CONFIG_FEATURE_SH_STANDALONE is not 
set/CONFIG_FEATURE_SH_STANDALONE=y/' .config
make
./busybox ash -c 'BUG=1 head /proc/self/environ | grep -q BUG && echo ok || 
echo bug'
./busybox ash -c 'BUG=1 ./busybox head /proc/self/environ | grep -q BUG && echo 
ok || echo bug'

The first echoes "bug" because the environment is not set.

I reproduced this.

The problem here is that /proc/self/environ is not the environment
as seen by C code. It is the memory area of the process where *initial
environment
variables* are stored (IIRC it is located in the top part of the stack area).

When NOEXEC applet is executed, the environment *is* set up correctly,
but on the C
language level: environ[] array is updated. The *initial environment*
is not updated.
Therefore, /proc/self/environ does not show new added variables.

Thanks, that makes sense and seems hard to fix, especially portably.
There is nothing portable in /proc/self/environ, or anywhere in the 
/proc directory. /proc/self/environ is for the benefit of programs like 
ps. It is only possible to overwrite it in place, which is mainly done 
for passwords and other sensitive information. You would have the same 
problem with /proc/self/cmdline.

Alpine linux uses a similar command to check if /proc is really mounted, or is 
just a semi-convincing fake. With CONFIG_FEATURE_SH_STANDALONE, real /proc 
registers as a fake.
Why is such a check necessary? Why would someone want to mount a fake 
when it is easier to mount the real proc? And if it was done 
intentionally, why try to detect it?

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

Re: NOEXEC environment bug

[Jack Schmidt]

> On 2017-11-02, at 08:26 , Denys Vlasenko  wrote:
> 
> On Wed, Nov 1, 2017 at 2:28 AM, Jack Schmidt  wrote:
>> I believe I have found a bug in the current version of busybox.
>> 
>> When:
>> * an applet is marked NOEXEC,
>> * busybox is configured with CONFIG_FEATURE_SH_STANDALONE=y, and
>> * busybox's ash is asked to do "ENV_VAR=newval no_exec_app"
>> Then the no_exec app is not called with the new environment.
>> 
>> This affects git master d5c1482fbac71c51e3add52632cdf1f9f9e6661b and 
>> 1:1.21.0-1ubuntu1
>> 
>> To reproduce from git (on linux):
>> 
>> git pull
>> make defconfig
>> sed -i 's/# CONFIG_FEATURE_SH_STANDALONE is not 
>> set/CONFIG_FEATURE_SH_STANDALONE=y/' .config
>> make
>> ./busybox ash -c 'BUG=1 head /proc/self/environ | grep -q BUG && echo ok || 
>> echo bug'
>> ./busybox ash -c 'BUG=1 ./busybox head /proc/self/environ | grep -q BUG && 
>> echo ok || echo bug'
>> 
>> The first echoes "bug" because the environment is not set.
> 
> I reproduced this.
> 
> The problem here is that /proc/self/environ is not the environment
> as seen by C code. It is the memory area of the process where *initial
> environment
> variables* are stored (IIRC it is located in the top part of the stack area).
> 
> When NOEXEC applet is executed, the environment *is* set up correctly,
> but on the C
> language level: environ[] array is updated. The *initial environment*
> is not updated.
> Therefore, /proc/self/environ does not show new added variables.

Thanks, that makes sense and seems hard to fix, especially portably.

> 
>> Alpine linux uses a similar command to check if /proc is really mounted, or 
>> is just a semi-convincing fake. With CONFIG_FEATURE_SH_STANDALONE, real 
>> /proc registers as a fake.
> 
> Please tell me more. What exactly Alpine is doing.

On Alpine, this is /lib/rc/sh/init.sh but maybe it is on Gentoo as well. OpenRC 
may pride itself on busybox compatibility, so maybe it is still worth fixing 
(either in busybox or openrc).

https://github.com/OpenRC/openrc/blob/master/sh/init.sh.Linux.in#L34

f=/proc/self/environ
if [ -e $f ]; then
if $got_md5sum && [ "$(VAR=a md5sum $f)" = "$(VAR=b md5sum $f)" ]; then
eerror "You have cruft in /proc that should be deleted"



One can replace the 'md5sum $f' with 'cat $f|md5sum' and things are fine, since 
cat is not NOEXEC.

Alpine normally does not notice this problem as its busybox is not configured 
as standalone.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: NOEXEC environment bug

[Denys Vlasenko]

On Wed, Nov 1, 2017 at 2:28 AM, Jack Schmidt  wrote:
> I believe I have found a bug in the current version of busybox.
>
> When:
> * an applet is marked NOEXEC,
> * busybox is configured with CONFIG_FEATURE_SH_STANDALONE=y, and
> * busybox's ash is asked to do "ENV_VAR=newval no_exec_app"
> Then the no_exec app is not called with the new environment.
>
> This affects git master d5c1482fbac71c51e3add52632cdf1f9f9e6661b and 
> 1:1.21.0-1ubuntu1
>
> To reproduce from git (on linux):
>
> git pull
> make defconfig
> sed -i 's/# CONFIG_FEATURE_SH_STANDALONE is not 
> set/CONFIG_FEATURE_SH_STANDALONE=y/' .config
> make
> ./busybox ash -c 'BUG=1 head /proc/self/environ | grep -q BUG && echo ok || 
> echo bug'
> ./busybox ash -c 'BUG=1 ./busybox head /proc/self/environ | grep -q BUG && 
> echo ok || echo bug'
>
> The first echoes "bug" because the environment is not set.

I reproduced this.

The problem here is that /proc/self/environ is not the environment
as seen by C code. It is the memory area of the process where *initial
environment
variables* are stored (IIRC it is located in the top part of the stack area).

When NOEXEC applet is executed, the environment *is* set up correctly,
but on the C
language level: environ[] array is updated. The *initial environment*
is not updated.
Therefore, /proc/self/environ does not show new added variables.

> Alpine linux uses a similar command to check if /proc is really mounted, or 
> is just a semi-convincing fake. With CONFIG_FEATURE_SH_STANDALONE, real /proc 
> registers as a fake.

Please tell me more. What exactly Alpine is doing.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox