[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a2FH=vbO=VaCdfja6bwSnSJ_bgc+18oyX-F6MRB0n=6uQ@mail.gmail.com>
Date: Fri, 12 Jan 2018 21:11:38 +0100
From: Arnd Bergmann <arnd@...db.de>
To: vcaputo@...garu.com
Cc: Pavel Machek <pavel@....cz>, Olivier Galibert <galibert@...ox.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
jikos@...e.cz
Subject: Re: Linux 4.15-rc7
On Fri, Jan 12, 2018 at 6:20 PM, <vcaputo@...garu.com> wrote:
> On Fri, Jan 12, 2018 at 02:23:20PM +0100, Arnd Bergmann wrote:
>> Could you be more specific which 32-bit x86 chips you have that are
>> affected by Meltdown? Do you mean pre-2004 Pentiums or Core-Duo
>> laptops? I would guess that Cyrix/Natsemi/AMD 6x86/MediaGX/Geode
>> and AMD NexGen K6/K7 also affected by Spectre but probably not
>> Meltdown, and most other 32-bit microarchitectures seem to be purely
>> in-order.
>>
>
> I have some Celeron D, 4GiB dedicated servers with a 32-bit stack.
> They've proven to be very reliable boxes, and are the most affordable
> baremetal x86 machines I've found. I'd appreciate a PTI implementation
> on them.
That's an interesting setup for a number of reasons:
- Celeron D are mostly 64-bit CPUs, but it depends on the particular
model/stepping, so if you have a couple of them, you might be able to
avoid the meltdown bug by running a 64-bit kernel with KPTI at least on
some of them, or trivially replace the CPU on others. This usually
works without changing user space, and tends to result in a faster
system than running a 32-bit kernel as you avoid highmem.
- I haven't found a definite answer on whether Netburst-based CPUs
are affected by meltdown at all. Some people claim it's affected,
others say it's not. If the code from https://github.com/IAIK/meltdown
is successful on your Celeron D, then we know it's affected, if not,
then you could decide to not care about KPTI (Spectre would still
be an issue).
- A 32-bit system running with mostly highmem (only the low 768 MB
out of 4GB are directly mapped) means some of the exploits are
harder to do in practice, as most of the page cache is not visible
in the kernel, and reading data from other processes will fail more
often that succeed.
- Economically, it seems barely worth running these if you pay for
the electricity: the CPU costs a few dollars/euros, it only takes
a couple of weeks of continuous operation to exceed that in
operating cost. Replacing the mainboard with a modern low end
all-in-one board at 10W might pay off within a year. If you don't pay
for electricity, that obviously doesn't work.
Arnd
Powered by blists - more mailing lists