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]

Date:	Sun, 21 Oct 2012 07:38:58 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Marcin Slusarz <marcin.slusarz@...il.com>
Cc:	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 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.

It's that simple. Don't expect anything else. Firmware is written by
people who have lost the will to live (why? Because they do firmware
development for a living), and the only thing keeping them going is
the drugs. And they're not the "fun" kind of drugs. The end result is
predictable. In their drug-induced haze, they make a mess.

So saying "ACPI is buggy" is like saying "water is wet". Deal with it.

> Nouveau calls this method: [...]
>
> with Arg0 == 0, Arg1 == 3 and gets:
>
> ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond end of region [VROM] (length 24) (20120913/exfldio-210)
> ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEGR.GFX0._ROM] (Node ffff88033e47fe88), AE_AML_REGION_LIMIT (20120913/psparse-536)
>
> We can workaround it by aligning Arg1 to 4096 (I'm wondering what is the minimal
> value), but do we really have to?

Yes, you really have to. You need to understand that ACPI has been
tested with one thing, and one thing only: Windows. Clearly windows
doesn't ask for some three-byte region. So it doesn't work. Big
surprise. Untested code written by monkeys on crack - what did you
expect?

So don't do "clever" things. When it comes to firmware, you need to
expect it to be buggy, and try to access it the way Windows accesses
it.

Now, whether Windows realy always does things with a 4kB-aligned
access, or whether you just need to make sure that you're (say)
4-byte-aligned, I don't know. Maybe doing things four (or eight, or
sixteen) bytes at a time will work. You can try. But if we know from
past experience that a 4kB block-size will work, I'd suggest just
saying

  "It's stupid, but stupid is good - we're working with firmware"

Think of firmware the way you think of hardware: it's buggy and needs
workarounds.

                Linus
--
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/