[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<GV2PR08MB92062BC06FFCFD28B8707592F7BE2@GV2PR08MB9206.eurprd08.prod.outlook.com>
Date: Mon, 5 Aug 2024 13:11:25 +0000
From: Justin He <Justin.He@....com>
To: Herbert Xu <herbert@...dor.apana.org.au>, Andy Polyakov
<appro@...ptogams.org>, herbertx/cryptodev
<reply+AAIFISMST74UQEQBJUWW7J6EXDLZNEVBMPHARJBRSY@...ly.github.com>
CC: herbertx/cryptodev <cryptodev@...eply.github.com>, Author
<author@...eply.github.com>, "David S. Miller" <davem@...emloft.net>, Catalin
Marinas <Catalin.Marinas@....com>, "linux-crypto@...r.kernel.org"
<linux-crypto@...r.kernel.org>, Will Deacon <will@...nel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, Ard Biesheuvel <ardb@...nel.org>
Subject: RE: [herbertx/cryptodev] crypto: arm64/poly1305 - move data to rodata
section (47d9625)
Hi Andy,
> -----Original Message-----
> From: Herbert Xu <herbert@...dor.apana.org.au>
> Sent: Saturday, August 3, 2024 8:40 AM
> To: herbertx/cryptodev
> <reply+AAIFISMST74UQEQBJUWW7J6EXDLZNEVBMPHARJBRSY@...ly.github.c
> om>
> Cc: herbertx/cryptodev <cryptodev@...eply.github.com>; Author
> <author@...eply.github.com>; Justin He <Justin.He@....com>; David S. Miller
> <davem@...emloft.net>; Catalin Marinas <Catalin.Marinas@....com>;
> linux-crypto@...r.kernel.org; Will Deacon <will@...nel.org>;
> linux-arm-kernel@...ts.infradead.org; linux-kernel@...r.kernel.org; Ard
> Biesheuvel <ardb@...nel.org>; Andy Polyakov <appro@...ptogams.org>
> 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"?
> >
> > 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.
--
Cheers,
Justin (Jia He)
Powered by blists - more mailing lists