linux-kernel - Re: [PATCH v2 3/2] RISC-V: sbi: remove sbi

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: <DAWB9QUQGPAZ.Z5454RAZXOF7@ventanamicro.com>
Date: Thu, 26 Jun 2025 10:10:48 +0200
From: Radim Krčmář <rkrcmar@...tanamicro.com>
To: "David Laight" <david.laight.linux@...il.com>
Cc: "Palmer Dabbelt" <palmer@...belt.com>,
 <linux-riscv@...ts.infradead.org>, <linux-kernel@...r.kernel.org>, "Paul
 Walmsley" <paul.walmsley@...ive.com>, <aou@...s.berkeley.edu>, "Alexandre
 Ghiti" <alex@...ti.fr>, "Atish Patra" <atishp@...osinc.com>,
 <ajones@...tanamicro.com>, <cleger@...osinc.com>,
 <apatel@...tanamicro.com>, <thomas.weissschuh@...utronix.de>, "Jeff Law"
 <jlaw@...tanamicro.com>
Subject: Re: [PATCH v2 3/2] RISC-V: sbi: remove sbi_ecall tracepoints

2025-06-25T09:34:15+01:00, David Laight <david.laight.linux@...il.com>:
> On Wed, 25 Jun 2025 09:51:45 +0200
> Radim Krčmář <rkrcmar@...tanamicro.com> wrote:
>> 2025-06-24T15:09:09+02:00, Radim Krčmář <rkrcmar@...tanamicro.com>:
>> > For another example, let's have the following function:
>> >
>> >   struct sbiret some_sbi_ecall(uintptr_t a0, uintptr_t a1)
>> >   {
>> >     return sbi_ecall(123, 456, a0, a1);
>> >   }
>> >
> ...
>> 
>> GCC 15.1 still leaves "mv" outside the branch, but at least seems to be
>> on the right track (undesired overhead is marked with leading stars):
>> 
>>    0xffffffff800236e8 <+0>:	addi	sp,sp,-48
>>    0xffffffff800236ea <+2>:	sd	s0,32(sp)
>>    0xffffffff800236ec <+4>:	sd	ra,40(sp)
>>    0xffffffff800236ee <+6>:	addi	s0,sp,48
>> *  0xffffffff800236f0 <+8>:	mv	a4,a0
>> *  0xffffffff800236f2 <+10>:	mv	a5,a1
>>    0xffffffff800236f4 <+12>:	nop
>> *  0xffffffff800236f8 <+16>:	mv	a0,a4
>> *  0xffffffff800236fa <+18>:	mv	a1,a5
>>    0xffffffff800236fc <+20>:	li	a7,123
>>    0xffffffff80023700 <+24>:	li	a6,456
>>    0xffffffff80023704 <+28>:	ecall
>> *  0xffffffff80023708 <+32>:	mv	a5,a0
>> *  0xffffffff8002370a <+34>:	mv	a2,a1
>>    0xffffffff8002370c <+36>:	nop
>>    0xffffffff80023710 <+40>:	ld	ra,40(sp)
>>    0xffffffff80023712 <+42>:	ld	s0,32(sp)
>> *  0xffffffff80023714 <+44>:	mv	a0,a5
>> *  0xffffffff80023716 <+46>:	mv	a1,a2
>>    0xffffffff80023718 <+48>:	addi	sp,sp,48
>>    0xffffffff8002371a <+50>:	ret
>>    [Tracing goes to +126]
>
> How much do a few register moves/spills matter compared to the
> cost of the called code?

I didn't do any serious analysis... In general, simpler functions are
going to suffer a higher ratio of overhead from adding tracepoints, and
the constant overhead per added tracepoint increases with the number of
its arguments.

For a trap to kernel mode that passes through a dozen tracepoint sites,
we could save under a hundred instructions if disabled tracepoints had
the minimal overhead.  I don't have a good idea how much of the total
trap execution-time/instruction-count/entropy-increase that actually is.

> There will but much worse things out there if you look.

Definitely, I am trying my best not to look, but I sometimes happen to
stumble upon something, and try to understand it.

Waiting till the tracepoint overhead resolves itself sounds fine to me.

Thanks.