Hi,
-----Original Message-----
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Sent: Saturday, August 3, 2024 8:40 AM
To: herbertx/cryptodev
<reply+AAIFISMST74UQEQBJUWW7J6EXDLZNEVBMPHARJBRSY@reply.github.c
om>
Cc: herbertx/cryptodev <cryptodev@xxxxxxxxxxxxxxxxxx>; Author
<author@xxxxxxxxxxxxxxxxxx>; Justin He <Justin.He@xxxxxxx>; David S. Miller
<davem@xxxxxxxxxxxxx>; Catalin Marinas <Catalin.Marinas@xxxxxxx>;
linux-crypto@xxxxxxxxxxxxxxx; Will Deacon <will@xxxxxxxxxx>;
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Ard
Biesheuvel <ardb@xxxxxxxxxx>; Andy Polyakov <appro@xxxxxxxxxxxxxx>
Subject: Re: [herbertx/cryptodev] crypto: arm64/poly1305 - move data to
rodata section (47d9625)
On Fri, Aug 02, 2024 at 08:09:10AM -0700, Andy Polyakov wrote:
Formally speaking this is error prone, because there is no guarantee that linker
will be able to resolve it as argument to `adr` instruction above. I mean since the
address is resolved with `adr` instruction alone, there is a limit on how far the
label can be from the instruction in question. On a practical level, if/since it's
compiled as part of a kernel module, it won't be a problem, because the module
won't be large enough to break the limit, but it **is** a problem in general case.
Thanks,
Can this problem be resolved by changing "adr" to "adrp"?
Not by adrp alone, it has to be complemented with addition. I mean addrp
gives you the label's page address and you need to add the offset within
the page.
But why would objtool attempt to disassemble it? Does it actually attempt to
disassemble unreferenced spaces between functions? Note that the .Lzeros label
doesn't make it into .o file, so there won't be anything in the symbol table to
discover as potential entry point..
There is a similar patch (1253cab8a352) for x86. I guess that objtool/stacktool can be improved in this regard.
objtool is weird and arguably inconsistent. It does look at the symbol
table(*), and detects the return instructions(**), yet insists on
disassemble-ability of the whole .text segment... Oh well...
Cheers.
(*) For example it refuses to generated ORC metadata for the following
snippet
.text
foo: ret
It insists on foo being complemented with '.type foo,@function' as well
as meaningful .size.
(**) Since it does mark the region[s] past 'ret' as type:(und)
