This page on VM side channel attack mitigations is scary: github.com/firecracker-microvm

Using the Linux KVM API seems easy enough, but we have all this hidden danger now.

@kosinus Not really surprising to me. If Spectre/Meltdown communicates anything to us it's that software sandboxes don't really work. Not that we really have anything better in many circumstances.

@alcinnz @kosinus I’m not sure that is the point - side channel attacks is a hardware/firmware issue, yes? The only solution that was practical was to code around it. Everyone from OpenBSD to Ubuntu has some sort of software sandbox game. It’s a question of playing the hand we are dealt.

@Denderix @kosinus I guess all I'm saying is that sandbox or not, we need to be reasonably confident we're not running malware. Which is a bit too much for some businesses because they make it their job to run others' code.

@alcinnz @Denderix @kosinus sad thing is software sandboxes should be enough.

Processors became increasingly complex in an attempt to extend Moore's law (and we know complex things aren't secure). This was necessary because we never learned to effectively use multiple processors/cores. Had we figured that out, making software faster would simply be a matter of adding cores.

Instead we have complex insecure processors.

Follow

@teleclimber @Denderix @kosinus Sometimes I wonder what computers would bey like if we switched to a system based on a functional machine code.

That could've been easier for CPUs to extract parallelism from. So much so that we might not have needed to do it in software.

@teleclimber @Denderix @kosinus And on the topic of sandboxing, that's a core part of functional programming too.

@alcinnz @teleclimber @Denderix That wouldn’t necessarily exclude timing attacks or caches, I think?

CPU caches, branch prediction, Spectre, Meltdown and the like are all magic to me. What I took from the whole ordeal is that some of the optimisations made were (or turned out to be) bad decisions.

@kosinus @teleclimber @Denderix It's always a case that you can always put that stuff in, but with functional programming you wouldn't have to.

You could design it so the only thing you can Time is the input (the Functional Reactive Paradigm). Or you can schedule the output.

As for caches I'm not really clear what would help or hurt. But I think keeping the young generation entirely in per-core caches would help.

Sign in to participate in the conversation
FLOSS.social

FLOSS.social was launched on 1 April 2018 as a Mastodon instance for people who care about, support, or build Free, Libre, and Open Source Software (FLOSS). Of course, discussions aren't limited to just FLOSS -- let's share our unique interests! English is preferred for maximum conversation opportunities within the FLOSS community, but it is not required. Respect is required, however: Users on FLOSS.social agree to abide by the Contributor Covenant Code of Conduct. This service was installed and is maintained in part by Masto.Host with equipment located at OVH. You can support this instance financially through the Monthly Supporter Program, processed through CommitChange using the free software Houdini Project.