linux-kernel - RE: [PATCH -next V7 0/7] riscv: Optimize function trace

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]

Message-ID: <90ad3009049e4d39a952b6e4c170740b@AcuMS.aculab.com>
Date:   Thu, 9 Feb 2023 22:46:53 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Guo Ren' <guoren@...nel.org>, Mark Rutland <mark.rutland@....com>
CC:     Evgenii Shatokhin <e.shatokhin@...ro.com>,
        "suagrfillet@...il.com" <suagrfillet@...il.com>,
        "andy.chiu@...ive.com" <andy.chiu@...ive.com>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Guo Ren <guoren@...ux.alibaba.com>,
        "anup@...infault.org" <anup@...infault.org>,
        "paul.walmsley@...ive.com" <paul.walmsley@...ive.com>,
        "palmer@...belt.com" <palmer@...belt.com>,
        "conor.dooley@...rochip.com" <conor.dooley@...rochip.com>,
        "heiko@...ech.de" <heiko@...ech.de>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "mhiramat@...nel.org" <mhiramat@...nel.org>,
        "jolsa@...hat.com" <jolsa@...hat.com>, "bp@...e.de" <bp@...e.de>,
        "jpoimboe@...nel.org" <jpoimboe@...nel.org>,
        "linux@...ro.com" <linux@...ro.com>
Subject: RE: [PATCH -next V7 0/7] riscv: Optimize function trace

From: Guo Ren
> Sent: 09 February 2023 01:31
...
> > I'm a bit confused there; I thought that the `symbol(reg)` addressing mode was
> > generating additional bits that the AUPIC didn't -- have I got that wrong?
> >
> > What specifies which register the JALR will write the link address to?
>
> According to the spec, auipc t1,0x0 should write PC + 0x0<<12 (which
> is equal to PC) to t1 and then jalr t0, (t0)0 jumps to the address
> stored in t0 + 0x0 and stores the return address to t0.
> 
> That means auipc defines xxx << 12 bits, jalr defines lowest 12 bits.

...
> What I want to point out:
> If we keep "auipc (addr+00)" fixed, we could use the different
> trampolines at "jalr (addr+0x4)" (All of them must be in one 2k
> aligned area).

I looked up auipc:
"AUIPC is used to build PC-relative addresses and uses the U-type format.
AUIPC forms a 32-bit offset from the U-immediate, filling in the lowest
12 bits with zeros, adds this offset to the address of the AUIPC instruction,
then places the result in rd."

So it generates 'pc + (val << 12)'.
And the jalr then adds in a 12bit offset.

I think that means that if you have two trampolines you might need
to change both instructions even if the two trampolines are actually
adjacent instructions.
It is the distance from the call site that mustn't cross a 2k
boundary - not the absolute address of the trampoline itself.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)