linux-kernel - Re: [PATCH 2/2] kernel/signal.c: explicitly initialize si

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: Fri, 23 Feb 2024 13:16:04 +0800
From: Wen Yang <wenyang.linux@...mail.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Christian Brauner <brauner@...nel.org>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Thomas Gleixner <tglx@...utronix.de>,
 Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
 Luis Chamberlain <mcgrof@...nel.org>,
 Mike Christie <michael.christie@...cle.com>,
 Dmitry Vyukov <dvyukov@...gle.com>,
 Vincent Whitchurch <vincent.whitchurch@...s.com>,
 Ard Biesheuvel <ardb@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] kernel/signal.c: explicitly initialize si_code and
 use ksig->info uniformly



On 2024/2/23 03:05, Oleg Nesterov wrote:
> On 02/23, wenyang.linux@...mail.com wrote:
>>
>> From: Wen Yang <wenyang.linux@...mail.com>
>>
>> By explicitly initializing ksig->info.si_code and uniformly using ksig->info,
>> get_signal() function could be slightly optimized, as folowes:
> 
> I don't understand. Why do you think it will be optimized? in what sense?
> 
>> 	clear_siginfo(&ksig->info);
>> 	ksig->info.si_signo = signr = SIGKILL;          --> missed si_code
> 
> because we do not need to set .si_code in this case?
> 
>> 	sigdelset(&current->pending.signal, SIGKILL);
>> 	trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO,  --> unnecessary SEND_SIG_NOINFO
> 
> Why do you think the usage of SEND_SIG_NOINFO is "unnecessary" or bad?
> To me this looks good.
> 

Since it is called "SEND_SIG_NOINFO", but here it is neither SEND_SIG
nor NOINFO.
It is get_signal() here, and ksig->info has also been partially
initialized before calling trace_signal_deliver(). Below "goto fatal", 
do_coredump() also use the initialized ksig->info.


>> @@ -2732,8 +2732,9 @@ bool get_signal(struct ksignal *ksig)
>>   		     signal->group_exec_task) {
>>   			clear_siginfo(&ksig->info);
>>   			ksig->info.si_signo = signr = SIGKILL;
>> +			ksig->info.si_code = SI_USER;
>>   			sigdelset(&current->pending.signal, SIGKILL);
>> -			trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO,
>> +			trace_signal_deliver(SIGKILL, &ksig->info,
> 
> Well. to me this look like the minor but unnecessary pessimization.
> 
> AFAICS, we do not need to initialize .si_code. The usage if ksig->info
> instead of  means that TP_STORE_SIGINFO() will actually read
> the memory.
> 
> Sorry, I don't understand the point at all :/
> 
> and it seems that we can simply kill clear_siginfo(), but this is
> another story.
> 



This is not right.

ksig->info will be passed to user space through do_coredump(), and the 
clear_siginfo() cannot be killed.


bool get_signal(struct ksignal *ksig)
{
..
                 if ((signal->flags & SIGNAL_GROUP_EXIT) ||
                      signal->group_exec_task) {
                         clear_siginfo(&ksig->info);
                         ksig->info.si_signo = signr = SIGKILL;
..
                         goto fatal;
                 }

         fatal:
..
                         do_coredump(&ksig->info);
                 }



void do_coredump(const kernel_siginfo_t *siginfo)
{
..
         struct coredump_params cprm = {
                 .siginfo = siginfo,
..
         };

..
        sub_info = call_usermodehelper_setup(..., &cprm);
..
        call_usermodehelper_exec(sub_info,...);




> Oleg.
>