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:	Fri, 9 Jan 2015 14:11:55 +0000
From:	"Ong, Boon Leong" <boon.leong.ong@...el.com>
To:	Bryan O'Donoghue <pure.logic@...us-software.ie>,
	Darren Hart <dvhart@...radead.org>
CC:	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"hpa@...or.com" <hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>,
	"platform-driver-x86@...r.kernel.org" 
	<platform-driver-x86@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 2/2] platform/x86: Add Intel Galileo platform specific
 setup

>
>On 09/01/15 11:17, Bryan O'Donoghue wrote:
>>> So this will load on any Quark device, Galileo or not, that doesn't
>>> provide a system_id. Is there any reason we need to support 0.8.0 and
>>> earlier firmware?
>>
>> Every Galileo Gen1 device ships with firmware version 0.7.5. You can
>> do an EFI capsule update to 0.8.0 which still isn't DMI-enabled - or
>> you can go and get a firmware greater than 0.9.0 and get DMI strings.
>
>I should add to that. Hundreds of the Gen1 devices were given away @
>MakerFaire Rome 2013, and AFAIK thousands were given to universities. So
>there's probably a few thousands boards floating around with the 0.7.5
>firmware that we want to support.
>
>Like I say - I think the fall-back is the simplest option and is also safe. I can add in
>the old way of identifying the boards and we can review it for appropriateness.
>I didn't include that old method for the fallback because it involves mapping SPI
>flash and parsing custom headers but - it works - even if it is ugly.
>

I agree with Bryan on his view-point. The logic to default to Galileo Gen-1 with older-firmware.
seems reasonable to me too. We cannot for sure older Galileo Gen-1 user will upgrade to newer
version of firmware. I suspect that many will not (because lack of understanding of how
UEFI capsule can do that or lack of equipment to flash it too, especially university students). 

So for the lack of better & robust approach, the default fallback when DMI string is not
detectable to GENv1 seems reasonable.

My 2 cents.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ