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]

Date:   Thu, 16 Sep 2021 23:25:17 +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

On Thu, Sep 16 2021 at 22:27, Ondrej Zary wrote:
> On Thursday 16 September 2021 19:09:31 Thomas Gleixner wrote:
>> Can you please run that failing program with GDB and figure out which
>> instruction causes #GP and what the register content is.
>
> (gdb) run
> Starting program: /opt/hp/hp-health/bin/IrqRouteTbl
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xf7fc509b in ?? ()
> (gdb) bt
> #0  0xf7fc509b in ?? ()
> #1  0x08048848 in ?? ()
> #2  0x08048aa1 in ?? ()
> #3  0x08048e05 in ?? ()
> #4  0xf7df9e46 in __libc_start_main () from /lib32/libc.so.6
> #5  0xf7ffd000 in ?? () from /lib/ld-linux.so.2
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> (gdb) x/3i $pc
> => 0xf7fc509b:  cli
>    0xf7fc509c:  push   %ebp
>    0xf7fc509d:  mov    %esp,%ebp
>
> OMG, maybe is it calling into the mmapped BIOS area?

Pretty much so. From your initial report:

openat(AT_FDCWD, "/dev/mem", O_RDWR)    = 3
mmap2(NULL, 8342, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED, 3, 0xf0000) = 0xf7fc1000
close(3)                                = 0
iopl(3)                                 = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---

offset 0xf0000 of /dev/mem is clearly the BIOS area. Daft.

That's really qualiteee stuff.

Thanks,

        tglx