linux-kernel - Re: On EOMA-68 patent licensing...

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] [day] [month] [year] [list]

Date:	Sun, 24 Nov 2013 10:40:34 +0000
From:	Luke Kenneth Casson Leighton <lkcl@...l.net>
To:	Yuhong Bao <yuhongbao_386@...mail.com>
Cc:	"mjg59@...f.ucam.org" <mjg59@...f.ucam.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: On EOMA-68 patent licensing...

On Sun, Nov 24, 2013 at 3:35 AM, Yuhong Bao <yuhongbao_386@...mail.com> wrote:
> I read this: http://hardware.slashdot.org/comments.pl?sid=3102545&cid=41270883
> Makes me wonder what would happen if something similar was tried with EFI or ACPI?

 the EOMA68 project is unique in that it is a mass-volume *modular*
architecture [*1], and it is (until intel and amd pull their fingers
out their arses and properly get below the 2W barrier) using the
so-called "embedded" SoCs - you know, the ones that don't have a BIOS?
 the ones that are causing linus to throw toys-out-of-prams?  what's
the name again... oh yes - ARM!  yes, that's the ones, silly me how
could i forget.

 so with no BIOS a degree of cooperation between hardware and software
on *both* sides of the interfaces is therefore... critical.

 an example of the closest corresponding danger that's related to
single-board monolithic designs is CONFIG_SYS_GPIO.  access to GPIO is
typically disabled by default in distro-released kernels (e.g. debian)
and even there if you look at e.g. the CS5535 GPIO module it's
hard-coded into the kernel source that "unsafe" GPIO cannot be
accessed even if it's requested.

 in other words, what would normally be dealt with either by the
proprietary vendor's BIOS on a single-board design plus a tiiiny bit
of help from some linux kernel source, suddenly now that's all out the
window.

 the next closest corresponding danger is x86 BIOSes (coreboot,
tinybios) etc. which is where dangers related to EFI and ACPI would
properly come into play and that's not the linux kernel's problem,
it's coreboot, tinybios, phoenix bios etc. etc.'s BIOS's problem, so
i'd kiinda say it's out of scope.  unless anyone else knows different?

l.

[*1] designed to solve the toys-out-of-pram issue by reducing the
Linux Kernel Hell surrounding embedded products from an "N product
design types times M processors" problem to a manageable "N designs
*plus* M processor-modules" arena.
--
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/