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 09:45:15 +0800
From:   "Leizhen (ThunderTown)" <thunder.leizhen@...wei.com>
To:     <hpa@...or.com>, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, x86l <x86@...nel.org>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Andy Lutomirski <luto@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
CC:     <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 1:48, hpa@...or.com wrote:
> On June 6, 2018 2:17:42 AM PDT, "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?
>>>>
>>>
> 
> The use of signals without SA_RESTORER is considered obsolete, but it's somewhat surprising that the vdso isn't there; it should be mapped even for static binaries esp. on i386 since it is the preferred way to do system calls (you don't need to parse the ELF for that.) Are you explicitly disabling the VDSO? If so, Don't Do That.

Yes, the vdso was explicitly disabled by the tester. Thanks.

> 

-- 
Thanks!
BestRegards

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ