netdev - Re: IAMT broken by commit 82776a4bcd7aa5fbcd2e6339b3ce88b727dd40ab

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:	Mon, 31 Jan 2011 12:36:05 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	aurelien@...el32.net
Cc:	bruce.w.allan@...el.com, jeffrey.t.kirsher@...el.com,
	netdev@...r.kernel.org
Subject: Re: IAMT broken by commit 82776a4bcd7aa5fbcd2e6339b3ce88b727dd40ab

From: Aurelien Jarno <aurelien@...el32.net>
Date: Mon, 31 Jan 2011 12:45:58 +0100

>> On recent kernels, IAMT support does not work after the machine has 
>> been powered-off. Even worse, it also goes into this state when I try
>> to reboot it.
>> 
>> I have done a bisect and got this commit:
>> 
>> | commit 82776a4bcd7aa5fbcd2e6339b3ce88b727dd40ab
>> | Author: Bruce Allan <bruce.w.allan@...el.com>
>> | Date:   Fri Aug 14 14:35:33 2009 +0000
>> | 
>> |     e1000e: WoL does not work on 82577/82578 with manageability enabled
>> |     
>> |     With manageability (Intel AMT) enabled via BIOS, PHY wakeup does not get
>> |     configured on newer parts which use PHY wakeup vs. MAC wakeup which causes
>> |     WoL to not work.  The driver should configure PHY wakeup whether or not
>> |     manageability is enabled.
>> |     
>> |     Signed-off-by: Bruce Allan <bruce.w.allan@...el.com>
>> |     Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
>> |     Signed-off-by: David S. Miller <davem@...emloft.net>
>> 
>> I have tried to revert it on recent kernels (2.6.34), and IAMT is then
>> working as expected. My machine is using a Gigabyte EQ45M-S2 motherboard
>> with an 82567LM-3 ethernet chip (8086:10de), that is a different model
>> than the one of the original problem.
>> 
>> I do wonder if the changes in the patch should not only be done on some 
>> chip models, and I will appreciate any help in fixing this issue.
>> 
> 
> Just a short mail to say this problem is still present in 2.6.38-rc2.
> The same solution still applies, that is reverting the above commit.
> Note that reverting the first hunk only is enough to get it working
> again.

Intel folks please look into this.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html