Spectre & Meltdown & Zombieload oh my!

[Deb-fan]

Ok extremely oddball concept here, while contemplating all this side-channel attack madness going on, Spectre, Meltdown, Zombieload etc. The following popped into my head, can someone run more than one gnu/Linux kernel on an gnu/nix operating system at the same time ? After a tad of thought, I believe the answer is yes. That being VM's/true hypervisors such as Kvm, Xen etc. While of course they still all have access to the systems underlying cpu(s), applications launched in these VM's should still totally be subject to the kernel they're running under in the guest OS. Wth does this matter you may be wondering at this point ? Well I've long taken to compiling my own kernels, also long been a performance junkie and doing whatever is reasonable to boost kernel performance/speed etc is one of the priorities. So in the recent past I've actually been researching ways to get rid of many of the new mitigations coming down the pipe for Spectre/MD/ZL etc.

Compiled out Retpoline, found the config to compile out PTI = Page table isolation and researching all the boot parameters someone can add to ie: /etc/default/grub to disable whichever mitigations they choose. Depending upon the kernel version you're running etc. While I overall like this and am interested in it, one thing about all these side-channel buggers and beasties is that folks are saying it's possible these exploits can be pulled off via javascript (web-browsers.) Which doesn't make me feel all warm and fuzzy inside when coupled with my having stripped away many of the mitigations for the kernel I'm running in the hopes of reclaiming any lost performance on my ole Intel cpu (atm era 2009ish). Although I do use noscript the Firefox addon to stop javascripts from running unless cleared on a website by the user. Still thinking eventually if this javascript vunerability is in fact possible that these exploits will trickle down and sooner or later become more common place. More widespread ...

This is what got me to thinking about having web-browsers run under a separate kernel. One with all mitigations in full effect, running under a hypervisor to keep them isolated. A barebones gnu/Linux guest VM, could be fairly well tiny. Even with all the goodies, Xorg, display manager, windows manager etc etc etc running, much of which may not strictly be necessary on a minimal VM guest OS, my install(s) still weigh in under 100mbs-ram total at idle. A stripped down VM guest strictly meant for running web browsers could be a drop in the resource bucket compared. Though with as hardened a kernel as someone prefers, while leaving the host OS, to do it's thing sans all these potentially performance bogging patches. While I've seen it said for desktop users with most workloads the mitigations don't really matter anyway, shrugs.

Now at this point, am tossing around ways to set this dorkishness up reasonably transparently, meaning when xyz-browser(s) are launched on the host, minimal VM/guest fires up to manage them, with it's hardened kernel hopefully preventing such browser(s) from being able to be messed with by Spectre/MD/ZL on the webz. Got some decent ideas on the matter but mostly just wanted to post this for the heck of it. Get people's feedback and opinions. While of course the affected system would have to be capable of virtualization ( mine isn't anyway.) Still thought this idea is somewhat interesting and worth sharing. Also pointlessly pointing out the obvious, this is seriously bad mojo for Intel, will be looking to AMD in future, have long prefered them anyway. Though depending upon the specs/price not going to pass up a good Intel based system that comes down the pike either. What say you fellows ?

[Deb-fan]

Arghhh, this says zombieload can still get at the host os, even via vm! https://www.zdnet.com/google-amp/articl ... ombieload/ Painful though this junk may be, still think it's interesting and has some merit. DAMN YOU INTEL!!! Also honestly believe this crap just didn't happen by coincidence. Think this flawed chip architecture was by design. Only most of us are just now finding out about it!

* Takes off tinfoil hat. :p

Ps, my take on these vulnerabilities from a desktop nixers perspective, is that they're way overblown and odds of someone being able to remotely compromise a web browser via some Javascript attack incredibly unlikely. On a multiuser system, where nobody knows, who all is doing what all, vps etc, yeah more cause for concern but avg desktop nixers, not so much. Just my opinion on it.

[CwF]

I prefer to build supermicro/intel, ya know the ones with the extra back-door eth chip, and there is no amd equivalent that has ever remotely exited me.
So far I have no indication this current scare is of any concern whatsoever outside of a giga blade data center compromised by physical access. On the home system there are many avenues for protection, #1 is 24/7/365 customer access is not required, so the ability to reach in and grab data can be nil. #2 is you data is outside of direct control once it enters the network. It can and has been scarfed while within providers networks.
Good to use VM's for browsers. Good to watch traffic. Lock down VM's for focused use, as in certain vms's only go to particular sites, no cross talk. Every week I see a site that suck cpu and memory beyond normal, soft lock the vm, allow me time to digest while I balloon memory into a recovered state. Sometimes I go after sites like that, capture their crap, see what happens, then wipe the runtime layer of the vm and start over clean in the next few minutes...
#3 If you are a target, good luck. If you are not, stop clicking on shit and you'll be fine.

[Deb-fan]

That's it, I'm going back to carrier pidgeons and calculators !!! You won't get me Zombieload !!!

Mostly agree that this sounds like a perfect thing for someone with physical access to a system/network or at very least creds to log into it remotely. Which in that case, all bets are off anyway and someone with decent tech skills could likely trash a target system one of many ways that'd be easier than side channel attacks, that even many people at NASA don't seem to understand. Same time remotely exploiting = a good penn tester, which would require the targeted system already have holes in it for them to get a foot hold ie: vulnerable software, services running (badly misconfigured etc etc.) Again imo, while having something like Zombileload, fallout ... whichever is the latest side channel scare may aid them to some extent, still would have to be involved, with no shortage of other exploits available to take it from there and the avg user isn't likely to be targeted by a professional penn tester regardless. More like script kiddie/automated junk and would still require they do something really foolish to remotely leave a way into their system/network anyway.

If someone installs some web nasty (software-packages)from untrusted sources and gives it priv's on their system(s) are plenty of ways someone can compromise them anyway, without resorting to all this Spectre/meltdown, super boogeyman on crack nonsense. Also noticed that many of the people feeding the flames of fear as pertains to these cpu exploits often have "we help our client$" or "if you need to contact u$" in the scary sounding info they're putting on their websites. Meaning they are obviously out for some ca$h. Plus many of them don't seem to really understand it themselves. This is really starting to remind me of Y2K, which I called BS on while it was oncoming-ongoing too. Though a bazillion dollars was spent mitigating Y2K too, shrugs. Don't doubt these side channel shenanighans are valid exploits just think they're mostly just more exploits in addition to the tons of already existing ones. In an enterprise-commercial (multiuser environment, yep, they don't have much choice but to take some action against this junk.)

End of the day, not going to lose sleep over this. More than likely will just keep stripping out any mitigations that I don't like until it becomes counter productive and as mentioned will focus more on AMD system(s)here forward just cause all this crap has me seriously annoyed at friggin Intel. Personally been saying for years, people don't have a clue what's in the lowest levels of software that's running on their systems anyway ie: bios/uefi ... proprietary drivers etc etc. All of which is lovingly loaded onto our pc's in far east countries, long before we even get our hands on the hardware. Chit ... just had a brainfart concept and hurried to post about the idea. Very unlikely will bother messing with VM's to run a dang web browser. Actually can't, this old laptop doesn't support virtualization anyway. Still think it's quasi interesting and could have some use. Noting of course that I'm a long way from an expert on the topic or on VM's either. Have read enough about this junk to know I don't want to read anymore !!!

Still folks, feedback and comments welcome ... Sorry for the rant.

[CwF]

I'm going back to carrier pidgeons and calculators

I think you mean slide rules. Calculators led to the metric conversion issue that led us crashing into Mars!

I don't think the worry for a commoner is local infestation. The threat is the multiple devices they allow to contribute to distributed code bots. The local computer doesn't notice and the aggregate of thousands allows action not observable by any one surveillance method. Only the top level aggregators are identifiable, and also disposable pawns.

I do browse in a vm, eight possible on a single read only base (1.4GB), each with a unique read only mid layer (~150MB), and a disposable top layer. I have no browsers installed on bare metal. I rock a flip phone, leave a message.

[Head_on_a_Stick]

my ole Intel cpu (atm era 2009ish)

That doesn't offer hyperthreading and so is immune to Meltdown

Check with

Code: Select all

grep -R . /sys/devices/system/cpu/vulnerabilities

+1 for AMD.

Disable all mitigations by applying this kernel parameter:

Code: Select all

mitigations=off

Not advised though. I can measure no difference with the mitigations enforced when running (eg) Blender or CS:GO so it seems wise to keep them enabled. And disable SMT for all Intel processors 'cos those fuckers just don't know what they're doing.

[Deb-fan]

^Woah! Cwf

Am also going to have to fallback to horses and buggies, lots electronics and software in modern forms of transport. Surely zombiemelt will kill us all! Did think of something to add to this jazz, Intel_microcode, need to track down some archived versions of it. After spending a bunch of time trying to roll back mitigations in the kernel, don't want to install microcode from Intel and have whatever hurried mitigations they've rolled out in some microcode for my cpu, potentially crapping up my efforts to whatever extent.

Was a thread by Head_on which reminded me of this aspect. You (CwF) mentioned in that thread that you disable hyper-threading on some Intel chips, mind if I ask what kind of performance impact that has? Also just for the record am not advising anyone to do anything in this madcap thread. Employ every side channel mitigation you can get hands on, if it makes you feel better. I'm just doing what works for me as regards this.

Plus would be somewhat more worried if we're dual booting with anything m$, particularly on bare metal. Though who we kidding those people are sitting ducks anyway, Meltzombie or no Zombiemelt.

Ps, ninja'd by HOAS, yeah partner I know but as ever you know your stuff. This old thing no HT and have the mitigations=off, in a newer os, don't believe this kernel version supports that parameter. Dang it one more edit, mention I custom compile so anything Debian backports etc doesn't matter to me.

[Head_on_a_Stick]

disable hyper-threading on some Intel chips, mind if I ask what kind of performance impact that has?

I have two custom scripts for enabling & disabling SMT on my AMD system — turning it off allows greater heat dissipation in the physical cores and adds ~10fps to CS:GO

[Deb-fan]

Cool hey thanks HOAS. Good to get 1st hand feedback from someone I respect fellow nixer. Is some performance hit disabling HT though? For some things, you'd just leave it permanently disabled if not right?

[Deb-fan]

Also have to ask HOAS. When you say you notice no performance impact with all mitigations left stock you are talking about an Intel chip, not Ryzen/AMD? In which case that'd be reasonable mitigations having a minimal effect, AMD isnt suppose to be effected by this side channel madness. So if it's an AMD chip, it'd be grossly unfair if fixes for them had a negative effect on their (and customers) stuff.

Have seen plenty of benchmark which report a significant impact on Intel chips, then of course others claiming otherwise. Common sense tells me that yes there's gotta be an impact for effected chips. Too tired/lazy right now to bother with this anymore. Just going to keep doing as I was, see how things turn out.

Ps, and expecting people to disable hyperthreading isn't a solution and a long way from reasonable but I guess Intel idea of a solution is everybody should just buy one of their 8-9th Gen chips. Which they apparently say aren't effected now. :p

[Head_on_a_Stick]

When you say you notice no performance impact with all mitigations left stock you are talking about an Intel chip, not Ryzen/AMD? In which case that'd be reasonable mitigations having a minimal effect, AMD isnt suppose to be effected by this side channel madness. So if it's an AMD chip, it'd be grossly unfair if fixes for them had a negative effect on their (and customers) stuff.

Yes, that's true. I have an AMD system.

But perhaps try some actual benchmarks before discarding the protections.

[CwF]

mind if I ask what kind of performance impact that has?

I approach performance differently. It's not a question of getting all you can out of your hardware. You get what you need and build accordingly. I like all the horsepower you need with the headroom required to relax. Yes, it castrates performance, so what, double up. The available current to hold clock and the resulting thermal headroom results in a per core improvement. My extreme example would be my newest XP machine that I cut from dual 4 core 8 thread to dual dual core. Thats 4 real cores in 2 135w sockets. It will hold 3.9+GHz endlessly and do so nearly silent. It also sports an amd Pitcairn XT 4GB also built stout that yes, runs on 32bit XP. A phenomenal machine. It's all-around perfomance simply can't be matched by a similar family quad core or HT dual core. Booted into debian it gets all 8, don't need the threads. I have more examples. Waste? Sure, but when I ride to the grocery I can loft the front wheel. That's not a waste. Moral; when it's good, get 2. Or more...

I run most vm's with 2 cores, one with av stuff gets 6 and more doesn't help much without clock to drive it. It's not hard or really that expensive for a modern desktop to have 12+ real cores. Note my expense expectations were set years ago, so I think desktop computers are dirt cheap.

[stevepusser]

For recent Intel CPUs (third generation or better), if thermal throttling is a performance bottleneck when they are under maximum load, undervolting the processor will let it run at a higher speed. Other benefits apart from that, even if there's no speed up, is lowering the system temperature under load and extending mobile devices' battery life. That can end up being more important than any kernel tweaks.

[Deb-fan]

Sheesh CwF sounds like you really know your way around configing hardware partner.

Dang it I majorly pulled my own thread way off topic. Was a brainfart about an approach for browsers mitigation against all these nasty sounding side channel monsters. Which hey is reasonable, sandboxing browsers or sheesh just getting rid of javascript, both etc. Not that I' even know if it's effective against the damn things at this point ! Turned it into an all around all things side channel scary, with myself actually obviously leaning towards it's mostly being a joke and smoke and mirrors for majority of gnu/Linux desktop users. Think most of the hubbub surrounding this junk, is meant towards enterprise gnu/Linux, vps's, cloud computing etc etc. Believe me I've been up, down and sideways on this crap, because I'm uber anal. So have read and reviewed aplenty. Am not saying jettisoning all mitigations is right for everybody, in every use case either. That's up to whichever admin right ?

On the other hand, one big regret I do have about all this ... Zombieload hasn't eaten this damn Android phone yet, I HATE THE THING !!!

[CwF]

undervolting the processor

Yep, another avenue taking advantage of the same headroom. Amperage is the ultimate clamp, set by thermals. Lower voltage can start off in a better condition.