linux-kernel - Re: Intermittent Qemu boot hang/regression traced back to INT 0x80 changes

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]

Message-ID: <20240424195157.GGZili3b-AxmUDlipA@fat_crate.local>
Date: Wed, 24 Apr 2024 21:51:57 +0200
From: Borislav Petkov <bp@...en8.de>
To: Paul Gortmaker <paulg@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org,
	Richard Purdie <richard.purdie@...uxfoundation.org>
Subject: Re: Intermittent Qemu boot hang/regression traced back to INT 0x80
 changes

On Wed, Apr 24, 2024 at 02:58:06PM -0400, Paul Gortmaker wrote:
..
> pci 0000:00:1d.0: [8086:2934] type 00 class 0x0c0300 conventional PCI endpoint
> pci 0000:00:1d.0: BAR 4 [io  0xc080-0xc09f]
> pci 0000:00:1d.1: [8086:2935] type 00 class 0x0c0300 conventional PCI endpoint
> pci 0000:00:1d.1: BAR 4 [io  0xc0a0-0xc0bf]
> pci 0000:00:1d.2: [8086:2936] type 00 class 0x0c0300 conventional PCI endpoint
> <hang - not always exactly here, but always in this block of PCI printk>

How would those commits have anything to do with such an early hang?!

Nothing that early is issuing INT80 32-bit syscalls, is it?

Btw, can you checkout the Linus tree at...

f35e46631b28 Merge tag 'x86-int80-20231207' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
f4116bfc4462 x86/tdx: Allow 32-bit emulation by default

<-- here and test that commit as the top one?

55617fb991df x86/entry: Do not allow external 0x80 interrupts 

which reminds me - that hang could be actually that guest kernel
panicking but the panic not coming out to the console.

When it hangs, can you connect with gdb to qemu and dump stack and
registers?

Make sure you have DEBUG_INFO enabled in the guest kernel.

Is this even a guest?

I know you had guests last time you reported the alternatives issue.

Right, and then test the tree checked out at this commit:

be5341eb0d43 x86/entry: Convert INT 0x80 emulation to IDTENTRY

The others should be unrelated...

b82a8dbd3d2f x86/coco: Disable 32-bit emulation by default on TDX and SEV

Hmm.

-- 
Regards/Gruss,
    Boris.

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