linux-kernel - Re: [PATCH] x86/i8259: Work around buggy legacy PIC

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: <YJ6jHYM5oXyYHIX9@gmail.com>
Date:   Fri, 14 May 2021 18:19:41 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     David Laight <David.Laight@...lab.com>
Cc:     'Thomas Gleixner' <tglx@...utronix.de>,
        'Maximilian Luz' <luzmaximilian@...il.com>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, Sachi King <nakato@...ato.io>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH] x86/i8259: Work around buggy legacy PIC


* David Laight <David.Laight@...LAB.COM> wrote:

> > > It is also worth noting that the probe code is spectacularly crap.
> > > It writes 0xff and then checks that 0xff is read back.
> > > Almost anything (including a failed PCIe read to the ISA bridge)
> > > will return 0xff and make the test pass.
> > 
> >         unsigned char probe_val = ~(1 << PIC_CASCADE_IR);
> > 
> > 	outb(probe_val, PIC_MASTER_IMR);
> > 	new_val = inb(PIC_MASTER_IMR);
> > 
> > How is that writing 0xFF?
> 
> Sorry I misread the code and diagnostic output.
> 
> In any case writing a value and expecting the same value back
> isn't exactly a high-quality probe.

It's not, and it's not intended to be: 0x21 is a well-known port nobody was 
crazy enough to override yet, so that probe basically filters out the 
"there is nothing at that port, at all" case, which would normally return 
0xff, or in a few weird cases 0x00 perhaps.

Writing something inbetween those values and getting the same value back 
tells us that something functional occupies that well-known IO-port, 
pretending to be a i8259 PIC.

Which is what we wanted to know, given the context.

Thanks,

	Ingo