On Tue, Dec 3, 2024 at 5:35 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
>
> On Mon, 2 Dec 2024 at 21:27, James Bottomley
> <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > I'm getting this in 6.13-rc1:
> >
> > /home/jejb/git/linux-tpm/lib/crypto/aesgcm.c:212:29: error: ptext1
> > causes a section type conflict with aesgcm_tv
> > static const u8 __initconst ptext1[16];
> > ^~~~~~
> > /home/jejb/git/linux-tpm/lib/crypto/aesgcm.c:570:9: note: ‘aesgcm_tv’ was declared here
> > } const aesgcm_tv[] __initconst = {
> > ^~~~~~~~~
> > make[5]: *** [/home/jejb/git/linux-tpm/scripts/Makefile.build:194: lib/crypto/aesgcm.o] Error 1
> > /home/jejb/git/linux-tpm/lib/crypto/aesgcm.c:212:29: error: ptext1 causes a section type conflict with aesgcm_tv
> > static const u8 __initconst ptext1[16];
> > ^~~~~~
> > /home/jejb/git/linux-tpm/lib/crypto/aesgcm.c:570:9: note: ‘aesgcm_tv’ was declared here
> > } const aesgcm_tv[] __initconst = {
> > ^~~~~~~~~
> > make[5]: *** [/home/jejb/git/linux-tpm/scripts/Makefile.build:194: lib/crypto/aesgcm.o] Error 1
> >
> > I think it's way older than 6.13-rc1, but the inclusion of the sevguest
> > driver in the merge window now means that something actually selects
> > it. I can fix it simply by adding a zero initialization to the file:
> >
> > -static const u8 __initconst ptext1[16];
> > +static const u8 __initconst ptext1[16] = { 0 };
> >
> > Which I think means that by default the traditional zero initialization
> > of a static variable is in the wrong section (and actually likely is
> > wrong for all our __initX variables as well).
> >
> > In case it matters, this is with gcc-7
> >
>
> This also works
>
> static const u8 __section(".init.rodata,\"a\",@progbits #") ptext1[16];
>
> and so this suggests that without the @progbits annotations, the
> compiler is placing ptext1 into a SHT_NOBITS section, causing a
> conflict with the SHT_PROGBITS annotation of aesgcm_tv.
>
> Given how unusual it is to have a static const variable without an
> initializer, I don't think this suggests that there is a wider issue
> with __initconst/__initdata.
>
> We're about to bump the minimum GCC version to 8 for other reasons,
> and I couldn't reproduce it with GCC 8.5.0. But the fix is
> straight-forward and actually clarifies this rather odd occurrence, so
> I think we should apply it nonetheless.
>
> --
> Ard.
So, this 16-byte zero data is stored in the kernel image due to
the __initconst section?
Without the __initconst annotation, it would go to the BSS section,
saving the kernel image size?
Anyway, up to the crypt maintainer.
Personally, I do not have much interest in an old compiler issue.
--
Best Regards
Masahiro Yamada
