17:00 <raboof> will the 'costly workarounds' for the CPU bugs that are making the rounds amplify the performance advantage of unikernels? or is that wishful thinking? :)

17:04 <dstolfa> raboof: if anything, it makes it more dangerous to run unikernels because the guarantees you had before are now broken with timing sidechannels on the cache and your unikernel can read host's memory

17:04 <dstolfa> it's essentially rowhammer 2.0

17:05 <dstolfa> of course, it's not *easy* to do so, but it's possible

17:05 <dstolfa> datacenters are going to have some fun :)

17:05 <raboof> right, it's more dangerous to run 3rd-party code (whether or not it's packaged as a unikernel)

17:07 <dstolfa> raboof: yeah. this is a local vulnerability. meltdown utilizes TSX on Intel to expose secrets within the kernel (thus breaking KASLR and other things, assuming we have no other leaks, which there usually are) and is more targeted towards Intel, although their toy examples work on AMD and ARM. Spectre is more difficult to set up and works by essentially training the branch predictor to assume a branch is

17:07 <dstolfa> taken, then creates a situation where it's not taken and ensures the right information is loaded into the cache (by inspecting the code and hand-crafting it). you can then easily time to find out what was in there

17:07 <dstolfa> there are papers on both if you'd like to read up on it, but essentially it's a microarchitectural problem and solvable (either by slower software solutions or a hardware solution, which will still probably slow things down)

17:09 <dstolfa> the important thing to note here is that while this is a somewhat generic way to develop exploits on current CPUs, software usually has much more glaring vulnerabilities that can be exploited and you probably won't be affected by this on your desktop (as long as you don't store passwords in chrome, because there's a PoC for that, expect it to develop further)

17:10 <dstolfa> as for mirage, you'd essentially have to willfully run a mirage unikernel which has this timing sidechannel inside of it

17:11 <dstolfa> so, as long as you look at the code you run and don't start running things arbitrarily (which you shouldn't be doing anyway, as there are much more dangerous things that can happen), you'll be fine :)

17:11 <raboof> yeah, those rumors of browser attack vectors make me uneasy ;)

17:11 <dstolfa> the PoC for chrome was essentially reading in-process memory from JS, which could be used to read your passwords if you store them in there

17:12 <dstolfa> but if you do what you should be doing anyway and using a different process to do so, that PoC can't be used for that. that's not to say someone can't create a very sophisticated exploit that goes further into kernel memory and targets other things

17:12 <dstolfa> but again... that dedicated of an attacker can do so more easily

23:54 <gentauro> anybody awake? :)

23:55 <gentauro> So I made a xen unikernel (mirage-skeleton/tutorial/hello/hello.xen) and I would like to run it from my Qubes OS?

23:55 <gentauro> What do I need to do? Thx :)