πŸŒ™β„οΈπŸŒ¨οΈ yomimono πŸŒ¨οΈβ„οΈπŸŒ™ utilise witches.town. Vous pouvez lΓ¦ suivre et interagir si vous possΓ©dez un compte quelque part dans le "fediverse".

@gentauro @Kensan In another significant way they are not affected - since there is no divide between userspace memory and kernel memory, the mitigation which causes the performance hit (evicting all the pages on context switch) is not relevant. So the flaw is absolutely relevant in the context of the hypervisor hosting the unikernel, but not within the unikernel itself (as it would be for a traditional guest VM).

@yomimono @gentauro Indeed, AFAIUI unikernels are not affected by Meltdown.

My comments were focused on Specter which currently have no generally applicable fix beyond removing (high res) timing sources (which is a common countermeasures against all timing side channels).

The problem (and the "solution") is really not in MirageOS but the hypervisor/kernel.

@Kensan @gentauro Ah, sorry for the noise! I have the Specter paper open in another tab, I'll read it before wading in again :)

@yomimono @gentauro No noise at all! Thank you for stressing the point that unikernels are (by construction) not affected by Meltdown.

I have to read more myself so I may very well be taking rubbish :p

@Kensan @gentauro @yomimono Aren't unikernels running under a hypervisor that has a linear map of physical memory still subject to meltdown attacks from other guests?

πŸŒ™β„οΈπŸŒ¨οΈ yomimono πŸŒ¨οΈβ„οΈπŸŒ™ @yomimono

@qrs Yes, absolutely (and the hypervisor and other guests are vulnerable to meltdown attacks from the unikernel, for that matter).

Β· 0 Β· 2