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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 2 Feb 2022 15:02:12 -0600
From:   Mike Christie <michael.christie@...cle.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     geert@...ux-m68k.org, vverma@...italocean.com, hdanton@...a.com,
        hch@...radead.org, stefanha@...hat.com, jasowang@...hat.com,
        mst@...hat.com, sgarzare@...hat.com,
        virtualization@...ts.linux-foundation.org,
        christian.brauner@...ntu.com, axboe@...nel.dk,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH V6 01/10] Use copy_process in vhost layer

On 1/18/22 1:12 PM, Eric W. Biederman wrote:
> Mike Christie <michael.christie@...cle.com> writes:
> 
>> On 1/17/22 11:31 AM, Eric W. Biederman wrote:
>>> Mike Christie <michael.christie@...cle.com> writes:
>>>
>>>> On 12/22/21 12:24 PM, Eric W. Biederman wrote:
>>>>> All I am certain of is that you need to set
>>>>> "args->exit_signal = -1;".  This prevents having to play games with
>>>>> do_notify_parent.
>>>>
>>>> Hi Eric,
>>>>
>>>> I have all your review comments handled except this one. It's looking like it's
>>>> more difficult than just setting the exit_signal=-1, so I wanted to check that
>>>> I understood you.
>>>
>>> [snip problems with exit_signal = -1]
>>>
>>>>
>>>> What do you think?
>>>
>>> I was wrong.  I appear to have confused the thread and the non-thread
>>> cases.
>>>
>>> Perhaps I meant "args->exit_signal = 0".  That looks like
>>> do_notify_parent won't send it, and thread_group_leader continues to do
>>> the right thing.
>>
>> That doesn't work too. exit_notify will call do_notify_parent but 
>> our parent, qemu, does not ignore SIGCHILD so we will not drop
>> down in into this chunk:
>>
>>         psig = tsk->parent->sighand;
>>         spin_lock_irqsave(&psig->siglock, flags);
>>         if (!tsk->ptrace && sig == SIGCHLD &&
>>             (psig->action[SIGCHLD-1].sa.sa_handler == SIG_IGN ||
>>              (psig->action[SIGCHLD-1].sa.sa_flags & SA_NOCLDWAIT))) {
>>
>> do_notify_parent will return false and so autoreap in exit_notify will
>> be false.
> 
> Bah good point.  We won't send the signal but you won't autoreap either.
> 
> I think we could legitimately change this bit:
> 
> 	/*
> 	 * Send with __send_signal as si_pid and si_uid are in the
> 	 * parent's namespaces.
> 	 */
> 	if (valid_signal(sig) && sig)
> 		__send_signal(sig, &info, tsk->parent, PIDTYPE_TGID, false);
> 
> To add:
> 	else
>         	/* We don't notify the parent so just autoreap */
>         	autoreap = true;
> 

Hey,

This works for me, but I think we might have issues where threads now get
reaped too soon when they are being ptraced.

I think I found a simple solution by just using kernel_wait in the vhost
task code since I want to wait for the thread to exit when I'm removing
a device already. I posted a patchset so you can check it out.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ