Re: [herbertx/cryptodev] crypto: arm64/poly1305 - move data to rodata section (47d9625)

[Andy Polyakov]

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)