On Tue, 2024-12-03 at 09:35 +0100, Ard Biesheuvel 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];
That also works for me.
> 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.
I'm not so sure about that:
static const u8 __section(".bss.init,\"a\",@nobits #") ptext1[16];
Also works for me.
> 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.
What I meant was that uninitialized static __initX variables point to
the bss section. We don't seem to have a discardable init bss section,
so they remain allocated for the life of the kernel.
> 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.
Hm, that's going to cause some problems: I'm on openSUSE Leap.
Although all gcc's up to gcc-13 can be installed, the default compiler
is still gcc-7
Regards,
James
