linux-kernel - Re: [PATCH] net: phy: Add sysfs attribute to prevent PHY suspend

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGVrzcaMn2gevGK2=NrGO6-V31XvExQANz89Mk=EGZqxjdmWSA@mail.gmail.com>
Date:	Mon, 10 Mar 2014 09:56:49 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	David Miller <davem@...emloft.net>,
	Rob Landley <rob@...dley.net>, Andrew Lunn <andrew@...n.ch>,
	netdev <netdev@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] net: phy: Add sysfs attribute to prevent PHY suspend

2014-03-10 7:25 GMT-07:00 One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>:
> On Mon, 10 Mar 2014 01:53:33 +0100
> Sebastian Hesselbarth <sebastian.hesselbarth@...il.com> wrote:
>
>> On 03/10/2014 01:41 AM, David Miller wrote:
>> > From: Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
>> > Date: Mon, 10 Mar 2014 01:37:32 +0100
>> >
>> >> The mechanism is manual, no automatic way to determine it.
>> >
>> > We recognize BIOS and ACPI bugs and work around them, by looking at
>> > version information and whatnot, so you really can't convince me that
>> > something similar can't be done here perhaps in the platform code.
>>
>> Hmm, if the is a way to determine the version of that particual u-boot
>> I'd be happy to exploit that information.
>
> If there isn't a way for a kernel to determine the U-boot version then
> maybe that should get fixed instead. That also solves your problem
> because if you can't find the uboot version you know its too old.

Once you have fixed how to determine the u-boot version (which BTW, is
probably much simpler to determine from user-space by reading from the
MTD partition exposing it, and using strings on the binary blob), you
are left with the other bootloaders out there which also do not clear
the BMCR_PWRDOWN bit of your PHY and will fail booting off the network
as well.

While I agree that there should be something done to help any OS
determine which bootloader version/model it got booted from (ala. x86
with type_of_bootloader), we still need a way to control this policy
(auto-suspending the unused Ethernet PHYs) from Linux, regardless of
whether the boot program is broken or not.
-- 
Florian
--
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/