Post 2748808 by kosinus@mastodon.social
(DIR) More posts by kosinus@mastodon.social
(DIR) Post #2748808 by kosinus@mastodon.social
2019-01-07T21:56:01Z
0 likes, 1 repeats
This page on VM side channel attack mitigations is scary: https://github.com/firecracker-microvm/firecracker/blob/master/docs/prod-host-setup.mdUsing the Linux KVM API seems easy enough, but we have all this hidden danger now.
(DIR) Post #2748980 by alcinnz@floss.social
2019-01-07T22:07:29Z
0 likes, 0 repeats
@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.
(DIR) Post #2753797 by Denderix@fosstodon.org
2019-01-08T01:13:55Z
0 likes, 0 repeats
@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.
(DIR) Post #2754272 by alcinnz@floss.social
2019-01-08T01:32:34Z
0 likes, 0 repeats
@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.
(DIR) Post #2754290 by Denderix@fosstodon.org
2019-01-08T01:33:20Z
0 likes, 0 repeats
@alcinnz @kosinus agreed
(DIR) Post #2775087 by teleclimber@social.tchncs.de
2019-01-08T17:33:25Z
0 likes, 0 repeats
@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.
(DIR) Post #2775320 by alcinnz@floss.social
2019-01-08T17:43:57Z
0 likes, 0 repeats
@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.
(DIR) Post #2775538 by alcinnz@floss.social
2019-01-08T17:53:31Z
0 likes, 0 repeats
@teleclimber @Denderix @kosinus And on the topic of sandboxing, that's a core part of functional programming too.
(DIR) Post #2775828 by kosinus@mastodon.social
2019-01-08T18:06:31Z
0 likes, 0 repeats
@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.
(DIR) Post #2776241 by alcinnz@floss.social
2019-01-08T18:21:49Z
0 likes, 0 repeats
@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.