Re: Meltdown and Spectre - What to do about it

Top Page
Message as email
+ (text/plain)
+ (text/plain)
Delete this message
Reply to this message
Author: der.hans
To: Main PLUG discussion list
Subject: Re: Meltdown and Spectre - What to do about it
Am 08. Jan, 2018 schwätzte so:

moin moin,

Raspberry Pi is not vulnerable to Meltdown or either Spectre, so use it if
you can :).

For desktops, disable as much JavaScript as you can in addition to the
Chromium setting you mentioned.

uMatrix does a pretty good job of disabling 3rd party JavaScript for web
sites. At this point I recommend removing the "* 1st-party * allow" option
under "My Rules".

I also removed "* 1st-party frame allow".

See the bottom of the pdf of the slides for a table of what each affects.

The next post requires JavaScript. You should make sure pcid is available
on base OS and also on guest OS if you're using VMs. His testing found
it's on for VMware.

Subsequent reading elsewhere shows that AWS paravirtualized probably
doesn't have it, but hardware virtualized does.

A QEMU post says that KVM doesn't yet support pcid.

grep pcid /proc/cpuinfo!topic/mechanical-sympathy/L9mHTbeQLNU



> Hi,
> I'm looking for more info or ideas on how one might protect them self
> given Meltdown and Spectre.
> Now that it has come to light that computer memory is not completely
> segregated or kept private by the CPU hardware... a failure in design
> allowing a hacker access to even the CPU Kernel memory. This is
> catastrophic.
> I'm reading the initial solution is for the O/S manufactures to patch
> their Kernel to secure the memory at its boundaries. In and of itself
> this seems to be a weak approach, however probably the only one at this
> point.
> I am reading that the real solution is a new bread of CPU that does not
> have this vulnerability. It would seem even modifying the existing CPUs
> and manufacturing them would take months if not a year or so. In the
> meantime we have to survive with hardware patched with software.
> I read that desktops are the most vulnerable. Maybe that should be any
> devise that runs a browser. The browser is the point of failure.
> Introduce some rogue JavaScript and your memory is compromised.
> This article says [1] one should enable site isolation using Chrome.
> At this point my preventative steps are:
> 1) flush all browsers of any usernames, passwords and history.
> 2) Only run the latest version of Chrome and only Chrome.
> 3) Configure Chrome to run in isolation mode.
> Anyone have any other thoughts?
> Thank you in advance.
> Keith
> Links:
> ------
> [1]

# If it's not a toy you're looking at it wrong. -- der.hans---------------------------------------------------
PLUG-discuss mailing list -
To subscribe, unsubscribe, or to change your mail settings: