linux-kernel - Re: [PATCH 1/2] powerpc/process: fix nested output in show_user

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]

Message-ID: <ebf2318b-7d72-6f20-2457-f97064d28164@c-s.fr>
Date:   Thu, 6 Sep 2018 11:04:40 +0200
From:   Christophe LEROY <christophe.leroy@....fr>
To:     Michael Ellerman <mpe@...erman.id.au>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>, muriloo@...ux.ibm.com
Cc:     linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH 1/2] powerpc/process: fix nested output in
 show_user_instructions()



Le 21/08/2018 à 08:27, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@....fr> writes:
> 
>> When two processes crash at the same time, we sometimes encounter
>> nesting in the middle of a line:
> 
> I think "interleaved" is the right word, rather than "nesting".
> 
> They're actually (potentially) completely unrelated segfaults, that just
> happen to occur at the same time.
> 
> And in fact any output that happens simultaneously will mess things up,
> it doesn't have to be another segfault.

Ok, i reworded in v2.

> 
>> [    4.365317] init[1]: segfault (11) at 0 nip 0 lr 0 code 1
>> [    4.370452] init[1]: code: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
>> [    4.372042] init[74]: segfault (11) at 10a74 nip 1000c198 lr 100078c8 code 1 in sh[10000000+14000]
>> [    4.386829] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
>> [    4.391542] init[1]: code: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
>> [    4.400863] init[74]: code: 90010024 bf61000c 91490a7c 3fa01002 3be00000 7d3e4b78 3bbd0c20 3b600000
>> [    4.409867] init[74]: code: 3b9d0040 7c7fe02e 2f830000 419e0028 <89230000> 2f890000 41be001c 4b7f6e79
>>
>> This patch fixes it by preparing complete lines in a buffer and
>> printing it at once.
>>
>> Fixes: 88b0fe1757359 ("powerpc: Add show_user_instructions()")
>> Cc: Murilo Opsfelder Araujo <muriloo@...ux.ibm.com>
>> Signed-off-by: Christophe Leroy <christophe.leroy@....fr>
>> ---
>>   arch/powerpc/kernel/process.c | 17 +++++++++--------
>>   1 file changed, 9 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
>> index 913c5725cdb2..c722ce4ca1c0 100644
>> --- a/arch/powerpc/kernel/process.c
>> +++ b/arch/powerpc/kernel/process.c
>> @@ -1303,32 +1303,33 @@ void show_user_instructions(struct pt_regs *regs)
>>   {
>>   	unsigned long pc;
>>   	int i;
>> +	char buf[96]; /* enough for 8 times 9 + 2 chars */
>> +	int l = 0;
> 
> I'm sure your math is right, but still an on-stack buffer with sprintf()
> is a bit scary.
> 
> Can you try using seq_buf instead? It is safe against overflow.
> 
> eg, something like:
> 
> struct seq_buf s;
> char buf[96];
> 
> seq_buf_init(&s, buf, sizeof(buf));
> ...
> seq_buf_printf(&s, ...);

Ok, I did that in v2. In the meantime I reworked the loop to avoid this 
uggly test against i % 8 and this duplication of the pr_info() of the 
code line.

Christophe