linux-kernel - Re: sev_es_trampoline_start undefined symbol referenced errors during kunit run

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] [day] [month] [year] [list]

Message-ID: <20250416091830.GBZ_915oVG0seSQp0O@fat_crate.local>
Date: Wed, 16 Apr 2025 11:18:30 +0200
From: Borislav Petkov <bp@...en8.de>
To: David Gow <davidgow@...gle.com>
Cc: Shuah Khan <skhan@...uxfoundation.org>, thomas.lendacky@....com,
	"x86@...nel.org" <x86@...nel.org>,
	Brendan Higgins <brendan.higgins@...ux.dev>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: sev_es_trampoline_start undefined symbol referenced errors
 during kunit run

On Wed, Apr 16, 2025 at 08:32:08AM +0800, David Gow wrote:
> - make ARCH=um mrproper # Clean the source tree, but incompletely, as
> the original kernel was built with ARCH=x86_64, not ARCH=um
> # As a result, the pasyms.h file will be left in the tree, as it's not
> part of the UML build

Yeah, or you do:

$ git clean -dqfx

and the thing is gone. :-P

> - ./tools/testing/kunit/kunit.py run --arch x86_64 # Attempt to
> build/run an out-of-tree x86_64 kernel.
> # This will not tell you to clean the source tree, as it was
> (incorrectly) cleaned for the wrong architecture, but will fail due to
> the wrong pasyms.h still being present.
> 
> I'm not sure if this is the same cause as what you're seeing, Shuah,
> but it seems plausible enough. If so, this is really an issue with the
> Makefiles suggesting the wrong make mrproper command (assuming that
> the architecture hasn't changed), or failing to detect that the source
> tree still isn't clean. Maybe that's something we could work around in
> either the arch/um makefiles or in kunit.py (or at least the
> documentation), if we don't want to rework how dirty trees are
> detected.

ARCH=um has always been weird in that regard and we have had "bugs" like that in
the past.

I guess the simplest thing to do is to whack ARCH=um too when you clean, in
addition to x86_64. Or use the above git command if you're in a git repo...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette