Re: Linux 4.15-rc7

[vcaputo]

On Fri, Jan 12, 2018 at 09:11:38PM +0100, Arnd Bergmann wrote:
> On Fri, Jan 12, 2018 at 6:20 PM,  <vcaputo@xxxxxxxxxxx> 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.
>

This may be possible, I'll need to try booting a x86_64 kernel on one
and see.  I would rather not change all of userspace.

> - 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).
>

I tried that when the code was first made public, but libkdump doesn't
support 32-bit; it's full of 64-bit register use in the assembly bits.

> - 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.
>

Well that's good news.

> - 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.
> 

I don't pay for the electricity, these are old dedicated servers hosted
by a third party.  Not my hardware, and any more modern dedicated x86
servers I've found are substantially more expensive and always SMP.

This particular hosting provider has tried selling me upgrades to their
current low-end offering (which is still SMP), the price basically
doubles.  These boxes are mostly idle, performing just personal email
and ssh duties.  For this situation reliability and security is the
priority, power efficiency and performance are not.

Thanks,
Vito Caputo