[PATCH 1/2] fips: Use ELF header to find .rodata1 section
Florian Weimer
fweimer at redhat.com
Tue Mar 1 12:17:06 CET 2022
* Clemens Lang:
> From what I can see, it currently uses the same approach, and probably
> has the same issue where the compiler could assume that the HMAC is 0
> and constant-propagate that. Again, this currently works just fine with
> GCC, but I don’t think it’s a good idea to rely on GCC’s unwillingness
> to replace a memcmp(3) with a few assembly instructions.
Maybe GCC should provide an explicit way to treat a data object as
constant for linking purposes, while having a compiler barrier around
that.
Separate compilation does that, but the data object must not be compiled
with LTO, and that probably any whole-world assumption that makes LTO so
successful.
> The currently merged state assumes the offset in the file matches the
> address at runtime. This is probably not a good assumption to make. How
> would you determine the offset of a symbol in a file given its runtime
> address? Find the matching program header entry that must have loaded it
> and subtracting the difference between p_vaddr and p_offset?
Yes, I think that should work.
Thanks,
Florian
More information about the Gcrypt-devel
mailing list