linux-kernel - Re: [PATCH] x86/boot: Fail the boot if !M486 and CPUID is missing

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]

Message-ID: <CALCETrWHi8K_kKvqs+0XE0DYZ_bUe2X2AZ2QVNMdCqXUqckxMg@mail.gmail.com>
Date:   Wed, 30 Nov 2016 10:28:53 -0800
From:   Andy Lutomirski <luto@...capital.net>
To:     One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:     Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Brian Gerst <brgerst@...il.com>,
        Matthew Whitehead <tedheadster@...il.com>
Subject: Re: [PATCH] x86/boot: Fail the boot if !M486 and CPUID is missing

On Wed, Nov 30, 2016 at 5:18 AM, One Thousand Gnomes
<gnomes@...rguk.ukuu.org.uk> wrote:
>> Rather than trying to work around these issues, just have the kernel
>> fail loudly if it's running on a CPUID-less 486, doesn't have CPUID,
>> and doesn't have CONFIG_M486 set.
>
> NAK
>
> This still breaks the Geode at the very least and I think the ELAN and
> some of the other older socket 7 devices. These have their own config CPU
> type (and in some cases *need* it selected) but do not have CPUID.
>
> Given the cores without CPUID are often post 486 in other respects this
> seems a bit odd. In fact I can't help thinking that the problem is that
> sync_core tests CONFIG_M486 whereas we should have and test
>
> HAVE_CPUID
>
> and set this by processor type (M586/M486/GEODEGX1/GEODE_LX1/Cyrix plus I
> think ELAN not having it)
>
> I'd been wondering why Geode wasn't working on modern kernels, now I
> think I know 8)
>

Ick.  Am I understanding correctly that this isn't a regression per se
since the affected machines were already broken?  If so, let's fix it
for real rather than just reverting this patch.

--Andy