linux-kernel - Re: 3.13: <module> disagrees about version of symbol <symbol>

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 7 Apr 2014 13:42:21 -0700
From:	Andi Kleen <ak@...ux.intel.com>
To:	Thomas Bächler <thomas@...hlinux.org>
Cc:	Al Viro <viro@...IV.linux.org.uk>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, tpowa@...hlinux.org,
	matt.fleming@...el.com, hpa@...or.com
Subject: Re: 3.13: <module> disagrees about version of symbol <symbol>

On Mon, Apr 07, 2014 at 10:10:46PM +0200, Thomas Bächler wrote:
> Am 07.04.2014 19:46, schrieb Thomas Bächler:
> > Am 07.04.2014 19:30, schrieb Andi Kleen:
> >>>> Do you have a specific config?
> >>>> Specific compiler version?
> >>>
> >>> Using gcc 4.8 from Arch Linux with the configuration at [1] and Linux 3.14.
> >>
> >> I tested this configuration (with gcc 4.8 on FC20/19) and it loads
> >> ext4 and all the other modules without any problems.
> >>
> >> Base tree: 
> >>
> >> commit e06df6a7eae1ab1ef4deb076aeeaed90e948e5c0
> >> Merge: c0fc3cb 9dd721c
> >> Author: Linus Torvalds <torvalds@...ux-foundation.org>
> >> Date:   Mon Mar 31 12:34:49 2014 -0700
> >>
> >> Must be something really archlinux specific. Please do some debugging.
> >> Also please double check that all your test procedures are correct.
> > 
> > Tetsuo was so kind to install Arch Linux and reproduce the exact
> > procedure I use to create the kernel (which includes the automated
> > creation of a pristine build environment) - his kernel booted just fine.
> > I will do more tests today on two of my own computers to narrow this down.
> 
> I think I found out why nobody could reproduce the problem.
> 
> I did a few more tests and it turns out that the problem only occurs
> when I boot the kernel with UEFI (using Gummiboot+EFISTUB). Now, except
> for OVMF virtual machines, there are barely any 32 Bit UEFI machines
> around, so nobody noticed. When I boot the kernel with 32 Bit BIOS, it
> boots fine.
> 
> Just to clarify: As mentioned in my first mail, some symbols still get a
> 0x0 CRC (which I still think is wrong), but the mismatch does not occur
> in BIOS mode.
> 
> On x86_64, the problem does not occur at all.

Thanks.

This sounds like the UEFI boot corrupts some memory? 

Copying some UEFI experts.

Maybe we need some CRC checksum checking in the kernel?

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/