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:	Thu, 12 Dec 2013 22:24:18 +0200
From:	Ivajlo Dimitrov <ivo.g.dimitrov.75@...il.com>
To:	Ben Hutchings <bhutchings@...arflare.com>,
	Dan Williams <dcbw@...hat.com>
CC:	Ivajlo Dimitrov <ivo.g.dimitrov.75@...il.com>,
	Pali Rohár 
	<pali.rohar@...il.com>, Kalle Valo <kvalo@...rom.com>,
	Luciano Coelho <luca@...lho.fi>,
	"John W. Linville" <linville@...driver.com>,
	linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, freemangordon@....bg,
	aaro.koskinen@....fi, pavel@....cz, sre@...g0.de,
	joni.lapilainen@...il.com,
	Johannes Berg <johannes@...solutions.net>,
	Felipe Contreras <felipe.contreras@...il.com>
Subject: Re: [PATCH v2 15/16] wl1251: Add sysfs file address for setting permanent
 mac address


On 12.12.2013 21:55, Ben Hutchings wrote:
> On Wed, 2013-12-11 at 16:53 -0600, Dan Williams wrote:
>> On Wed, 2013-12-11 at 22:15 +0000, Ben Hutchings wrote:
>>> On Wed, 2013-12-11 at 23:35 +0200, Ivajlo Dimitrov wrote:
>>>> On 11.12.2013 23:17, Ben Hutchings wrote:
>>>>> I think that's an even worse idea.  This is not firmware and it already
>>>>> exists in separate storage.
>>>>>
>>>>> I think that rx51_init_wl1251() in
>>>>> arch/arm/mach-omap2/board-rx51-peripherals.c should either copy the MAC
>>>>> address out of NVRAM, or if it's too early to do that, then schedule a
>>>>> function to run later and only then set up wl1251 platform data.
>>>>>
>>>>> Ben.
>>>>>
>>>> And how will that work with DT when board files will be in the history?
>>> 1. Boot loader reads the MAC address from NVRAM and puts it in the DT
>>> node.
>>> or
>>> 2. NVRAM reading is done by a tiny driver that is loaded based on the
>>> platform name and updates the DT node in memory.  (But I don't know how
>>> wl1251 should decide to defer probing if it's probed before that other
>>> driver.)
>> I'm uncomfortable with it too, and yes the permanent MAC should really
>> be known before the interface is even registered, but...
>>
>> Imagine if the MAC address for your ethernet device was stored
>> in /etc/my-mac-addr.txt, except that /etc was a read-only protected
>> partition from a very small SSD.  That's essentially the N900; it's
>> stored in a file in a normal ext2/ext3 (?) filesystem on a partition of
>> the internal flash.
> Oh, from my quick look I got the impression that this 'CAL' was stored
> directly in a specific flash partition.
>
>>    It seems like overkill to write a small driver that
>> duplicates the ext3 + MTD drivers just to read the MAC.
> [...]
>
> I don't see that anything would need to be duplicated.  But reading
> files from the kernel is really ugly, and deciding when to read the file
> would be another problem (as you noted).
>
> Ben
>
Yes, CAL is stored in /dev/mtd1, a dedicated partition in the NAND 
flash. But reading the data stored in it from the kernel is not a 
trivial task, as it uses its own pseudo-fs format etc. Not impossible (I 
RE-ed libcal a while ago [0], so there is a code that could be reused, 
calvaria works too afaik), but still doesn't sound like a very good idea.

[0] 
https://gitorious.org/community-ssu/libcal/source/d4c5fd9293ddb693c9b032b4c084cd0343b3ea26:

Ivo
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ