linux-kernel - Re: Linux 3.7-rc1 (nouveau_bios

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: <2998525.z8RPfWksxL@al>
Date:	Sun, 21 Oct 2012 22:07:27 +0200
From:	Lekensteyn <lekensteyn@...il.com>
To:	Marcin Slusarz <marcin.slusarz@...il.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-acpi@...r.kernel.org, Len Brown <lenb@...nel.org>,
	Heinz Diehl <htd@...tha.org>,
	Martin Peres <martin.peres@...ri.fr>,
	Heinz Diehl <htd@...cy-poultry.org>,
	David Airlie <airlied@...ux.ie>,
	Ben Skeggs <bskeggs@...hat.com>,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	Paweł Sikora <pawel.sikora@...k.net>
Subject: Re: Linux 3.7-rc1 (nouveau_bios_score oops).

On Sunday 21 October 2012 16:49:08 Marcin Slusarz wrote:
> On Sun, Oct 21, 2012 at 07:38:58AM -0700, Linus Torvalds wrote:
> > On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz
> > 
> > <marcin.slusarz@...il.com> wrote:
> > > This looks like ACPI bug...
> >
> > I'm shocked to hear that firmware would be fragile.
> >
> > Anyway, here's the #1 thing to keep in mind about firmware:
> > 
> >  - firmware is always buggy.
> 
> I know. But this bug is not about broken firmware. It's about Linux kernel
> ACPI implementation, which (I think) wrongly interprets ACPI script.

The ACPI implementation is fine, it is just the fw engineers that suck. I see I 
have not cc'd the linux-vger ml when replying to a previous mail. I'll paste 
it below:

Since commit 9a334cd "drm/nouveau/bios: fix shadowing of ACPI ROMs larger than 
64KiB" chunks are not always read in multiples of 4KiB anymore (less is 
possible). That is the only obvious thing I can think of atm (besides the 
kmalloc(0) bug for which Martin submitted a patch in the previous mail).

Do you still still have an Asus laptop with the same BIOS as in 
https://bugzilla.kernel.org/show_bug.cgi?id=19702? (if yes, then the acpidump 
from that bug still applies).

This is the ACPI _ROM method that is being called:
Method (_ROM, 2, NotSerialized)  // _ROM: Read-Only Memory
{
    Add (Arg0, RBUF, Local0)
    ShiftLeft (Arg1, 0x03, Local1) // times 8, bytes to bits?
    Name (VBUF, Buffer (Arg1) {}) 
    OperationRegion (VROM, SystemMemory, Local0, Local1)
    Field (VROM, ByteAcc, NoLock, Preserve)
    {   
        ROMI,   65536
    }   

    Store (ROMI, VBUF)
    Return (VBUF)
}

Arg0 is the offset (0 when first reading the size), Arg1 is the number of read 
bytes (3). Note the use of Local1 in OperationRegion. The meaning there is 
bytes, but a multiple of the requested bytes is passed. So if we request 4096 
bytes, we end up with a VROM of size 32KiB. ROMI is 65536 bits (or 8192 
bytes), hence reading 4096 does not give errors. But reading only 3 bytes will 
fail. Martin, I saw your second patch (https://lkml.org/lkml/2012/10/20/150) 
which takes care of the first case, but it skips the case where the ROM is of 
an odd size (does that even happen, something like 64KiB+1 bytes? No idea.)

Addition: Conclusion: this means that the request must have a length must be 
at least 1 KiB or it will fail with the ACPI error that you have seen before. 
This AML snippet suck.

Regards,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/