linux-kernel - Re: IOPL emulation breaks hpasmd (hp-health) needed by HP DL380 G4 servers

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: <87pmt8a1mc.ffs@tglx>
Date:   Thu, 16 Sep 2021 19:09:31 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Ondrej Zary <linux@...y.sk>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: IOPL emulation breaks hpasmd (hp-health) needed by HP DL380 G4
 servers

Ondrej,

On Wed, Sep 15 2021 at 14:23, Ondrej Zary wrote:
> after upgrading Debian from 10 (kernel 4.19.194) to 11 (kernel 5.10.46) on HP
> DL380 G4 servers, hpasmd segfaults. Booting the 4.19.194 kernel allows hpasmd
> to work.
>
> Noticed the iopl(3) call. Checked out a kernel before "x86/iopl: Remove legacy IOPL option"
> (a24ca9976843156eabbc5f2d798954b5674d1b61) and built with CONFIG_X86_IOPL_LEGACY.
> It works!.
>
> I even disassembled /opt/hp/hp-health/bin/IrqRouteTbl (it's only 5952 bytes
> and does not use any hp libs). There's no CLI, only a couple of INs and OUTs:
> ...
>  8048f75:       66 ba 84 00             mov    dx,0x84
>  8048f79:       66 b8 00 00             mov    ax,0x0
>  8048f7d:       ee                      out    dx,al
>  8048f7e:       66 ba 85 00             mov    dx,0x85
>  8048f82:       ee                      out    dx,al
>
> But I still don't know what's going on.

That's weird. Let me think about a way to debug that. I just ran a
trivial test program which issues iopl(3) and reads all ports from
0-65535. That works like a charm.

#include <stdio.h>
#include <sys/io.h>

int main(void)
{
	unsigned int i;
	int ret;

	ret = iopl(3);
	if (ret)
		return ret;

	for (i = 0; i < 65536; i++)
		printf("%5u: %02x\n", i, inb(i));

	return 0;
}

Which CPU is in that machine?

Can you please run that failing program with GDB and figure out which
instruction causes #GP and what the register content is.

Thanks,

        tglx