linux-kernel - Re: Signals to cinit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 12 Nov 2008 15:52:26 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	sukadev@...ux.vnet.ibm.com
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Pavel Emelyanov <xemul@...nvz.org>, daniel@...ac.com,
	Nadia Derbey <Nadia.Derbey@...l.net>, serue@...ibm.com,
	clg@...ibm.com, Containers <containers@...ts.osdl.org>,
	sukadev@...ibm.com, linux-kernel@...r.kernel.org
Subject: Re: Signals to cinit

On 11/10, sukadev@...ux.vnet.ibm.com wrote:
>
> Oleg Nesterov [oleg@...hat.com] wrote:
> | (lkml cced because containers list's archive is not useable)
>
> Hmm. what do you mean by not usable ? I see your email here:
> https://lists.linux-foundation.org/pipermail/containers/2008-November/014152.html

Yes, but I failed to find our previous discussions via google, and actually
I prefer to see them all on marc.info, so I can quickly find them...

> | > Or something. yes, sys_rt_sigqueueinfo() is problematic...
>
> Yes, if user-space sets si_pid to 0.
>
> Can we change sys_rt_sigqueueinfo() to:
>
> 	if (!info->si_pid)
> 		info->si_pid = getpid();

I doubt very much we can do this. This can break the existing applications
which can overload ->si_pid. I think it is better to pass ->si_pid as is.
If user-space sends siginfo_t so sub-namespace, it must know what it does.
I don't think the kernel can help, it just can't know what ->si_pid actually
means. Unless this is documented somewhere, but I don't know.

> | But how can send_signal() know that the signal comes from the upper ns?
> | This is not trivial, we can't blindly use current to check. The signal
> | can be sent from irq/workqueue/etc.
>
> You mean the in_interrupt() check we had in earlier patchset would
> not be enough ?

I don't think we can rely on in_interrupt() check. Thnk about some device
drivers which can send the notification from workqueue, or from kernel
thread... Say, can you see when drivers/usb/core/devio.c does
async_completed() ? And note that SI_ASYNCIO is SI_FROMUSER.

Even _if_ it is safe to use in_interrupt() right now, I don't think we
can rely on this fact.

> | Perhaps we can start with something like the patch below. Not that I like
> | it very much though. We should really place this code under
> | CONFIG_I_DO_CARE_ABOUT_NAMESPACES ;)
>
> CONFIG_PID_NS ?

Ah yes, we have it ;)

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/