linux-kernel - Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 7 Jun 2018 11:10:04 +0800
From:   "Leizhen (ThunderTown)" <thunder.leizhen@...wei.com>
To:     Andy Lutomirski <luto@...capital.net>
CC:     Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        LKML <linux-kernel@...r.kernel.org>, <yaomin2@...wei.com>
Subject: Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when
 vdso disabled on X86?



On 2018/6/7 10:39, Andy Lutomirski wrote:
> 
> 
>> On Jun 6, 2018, at 7:05 PM, Leizhen (ThunderTown) <thunder.leizhen@...wei.com> wrote:
>>
>>
>>
>>> On 2018/6/7 1:01, Andy Lutomirski wrote:
>>> On Wed, Jun 6, 2018 at 2:18 AM Leizhen (ThunderTown)
>>> <thunder.leizhen@...wei.com> wrote:
>>>>
>>>> I found that glibc has already dealt with this case. So this issue must have been met before, should it be maintained by libc/user?
>>>>
>>>>        if (GLRO(dl_sysinfo_dso) == NULL)
>>>>        {
>>>>                kact.sa_flags |= SA_RESTORER;
>>>>
>>>>                kact.sa_restorer = ((act->sa_flags & SA_SIGINFO)
>>>>                        ? &restore_rt : &restore);
>>>>        }
>>>>
>>>>
>>>>> On 2018/6/6 15:52, Leizhen (ThunderTown) wrote:
>>>>>
>>>>>
>>>>>> On 2018/6/5 19:24, Leizhen (ThunderTown) wrote:
>>>>>> After I executed "echo 0 > /proc/sys/abi/vsyscall32" to disable vdso, the rt_sigaction01 test case from ltp_2015 failed.
>>>>>> The test case source code please refer to the attachment, and the output as blow:
>>>>>>
>>>>>> -----------------
>>>>>> ./rt_sigaction01
>>>>>> rt_sigaction01    0  TINFO  :  signal: 34
>>>>>> rt_sigaction01    1  TPASS  :  rt_sigaction call succeeded: result = 0
>>>>>> rt_sigaction01    0  TINFO  :  sa.sa_flags = SA_RESETHAND|SA_SIGINFO
>>>>>> rt_sigaction01    0  TINFO  :  Signal Handler Called with signal number 34
>>>>>>
>>>>>> Segmentation fault
>>>>>> ------------------
>>>>>>
>>>>>>
>>>>>> Is this the desired result? In function ia32_setup_rt_frame, I found below code:
>>>>>>
>>>>>>     if (ksig->ka.sa.sa_flags & SA_RESTORER)
>>>>>>             restorer = ksig->ka.sa.sa_restorer;
>>>>>>     else
>>>>>>             restorer = current->mm->context.vdso +
>>>>>>                     vdso_image_32.sym___kernel_rt_sigreturn;
>>>>>>     put_user_ex(ptr_to_compat(restorer), &frame->pretcode);
>>>>>>
>>>>>> Because the vdso is disabled, so current->mm->context.vdso is NULL, which cause the result of frame->pretcode invalid.
>>>>>>
>>>>>> I'm not sure whether this is a kernel bug or just an error of test case itself. Can anyone help me?
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>> I can't tell from your email what you're testing, what behavior you
>>> expect, and what you saw.  A program that sets up a signal handler
>>> without supplying a restorer will not work if the vDSO is off, and
>>> this is by design.
>> OK, so that the user should take care whether the vDSO is disabled by itself or not, and use different strategies to process it appropriately, like glibc.
>>
>>>
>>> (FWIW, there is a very longstanding libc bug that causes this case to
>>> get severely screwed up if the user's SS is not the expected value,
>>> and that bug was just fixed very recently.  But I doubt this is what
>>> you're seeing.)
>>>
>>> I suppose we could improve the kernel to at least push NULL instead of
>>> some random address a bit above 0, but it'll still crash.
>> Should we add a warning? Which may help the user to aware this error in time.
>>
> 
> It’s entirely valid to have a non working restorer if you never plan to return from a signal handler. And anyone who writes their own libc should be able to figure this out on their own, I think.

OK. Thanks a lot.

> 
>>>
>>> .
>>>
>>
>> -- 
>> Thanks!
>> BestRegards
>>
> 
> .
> 

-- 
Thanks!
BestRegards