linux-kernel - Re: 2.6.18 suspend regression on Intel Macs

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] [day] [month] [year] [list]

Date:	Wed, 11 Oct 2006 07:35:04 -0700 (PDT)
From:	Linus Torvalds <torvalds@...l.org>
To:	Len Brown <lenb@...nel.org>
cc:	Pavel Machek <pavel@....cz>,
	Frédéric Riss <frederic.riss@...il.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.18 suspend regression on Intel Macs



On Wed, 11 Oct 2006, Len Brown wrote:
> 
> It is troubling that Linux now gets to add the burden of MacOS bug compatibility to
> Windows bug compatibility.  I asked the apple folks and they
> said they didn't see anyplace in MacOS where SCI_EN is restored
> from the OS, so perhaps we are following a different path through
> their firmware...

We definitely are. MacOS uses EFI. Linux (if you want to use a standard 
Linux distro image) uses Boot Camp, aka BIOS emulation.

> I don't think the risk here isn't that setting SCI_EN is going to break something.
> The risk is that excluding it from ACPI_PM1_CONTROL_PRESERVED_BITS
> will allow other writes to this register to clear that bit from the OS,
> which is clearly counter to what the spec says to do.

Is there _ever_ any valid reason to clear it? I wouldn't object at all to 
a patch that just forces it..

That said, I could imagine some strange AML sequence that clears that bit 
in order to do something really nasty (and then sets it again at the end). 
There's no limit to what horrors can lurk in peoples BIOSes.

		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/