linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: vcaputo@pengaru.com
Cc: Pavel Machek <pavel@ucw.cz>,
	Olivier Galibert <galibert@pobox.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	jikos@suse.cz
Subject: Re: Linux 4.15-rc7
Date: Fri, 12 Jan 2018 21:11:38 +0100	[thread overview]
Message-ID: <CAK8P3a2FH=vbO=VaCdfja6bwSnSJ_bgc+18oyX-F6MRB0n=6uQ@mail.gmail.com> (raw)
In-Reply-To: <20180112172057.j33yhxb4gz6soscj@shells.gnugeneration.com>

On Fri, Jan 12, 2018 at 6:20 PM,  <vcaputo@pengaru.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

  reply	other threads:[~2018-01-12 20:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-07 22:55 Linux 4.15-rc7 Linus Torvalds
2018-01-08  7:20 ` Thomas Gleixner
2018-01-10 23:32 ` Pavel Machek
2018-01-11 11:29   ` Olivier Galibert
2018-01-11 14:06     ` Nikolay Borisov
2018-01-12 11:06     ` Pavel Machek
2018-01-12 13:23       ` Arnd Bergmann
2018-01-12 14:43         ` Pavel Machek
2018-01-12 17:20         ` vcaputo
2018-01-12 20:11           ` Arnd Bergmann [this message]
2018-01-12 22:04             ` vcaputo
2018-01-12 22:08               ` Arnd Bergmann
2018-01-12 22:58                 ` vcaputo
2018-01-12 17:34         ` Linus Torvalds
2018-01-12 19:38           ` Pavel Machek
2018-01-12 19:44             ` Linus Torvalds
2018-01-12 20:41               ` Pavel Machek
2018-01-13 12:52               ` kernel page table isolation for x86-32 was " Pavel Machek
2018-01-11 14:07   ` Jiri Kosina
2018-01-19 10:28     ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAK8P3a2FH=vbO=VaCdfja6bwSnSJ_bgc+18oyX-F6MRB0n=6uQ@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=galibert@pobox.com \
    --cc=jikos@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=torvalds@linux-foundation.org \
    --cc=vcaputo@pengaru.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).