linux-kernel - RE: [PATCH 2/2] platform/x86: Add Intel Galileo platform specific setup

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]

Message-ID: <AF233D1473C1364ABD51D28909A1B1B7326E3F6C@PGSMSX105.gar.corp.intel.com>
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/