No, all these were addressed in the article.<p>On 1) &quot; Hypervisor vulnerabilities emphatically exist; one cannot play up Linux kernel vulnerabilities as a silent menace while simultaneously dismissing hypervisor vulnerabilities as imaginary&quot;<p>This is obvious, but it&#x27;s true that people somehow think hypervisor vulnerabilities don&#x27;t exist.  Amazon and Linode just rebooted a bunch of machines because of a Xen vulnerability.  Could something like Xen be more secure than the Linux kernel?  Maybe.  That&#x27;s a good question, and one I haven&#x27;t seen the answer to.<p>I actually doubt it because emulating hardware is probably full of more &quot;C tricks&quot; than kernel code, but I&#x27;m not an expert here.  Another complication is that when you use a hypervisor, you always have Linux <i>in addition</i>.  You generally use its drivers for the real hardware.  It would seem that Linux + hypervisor is less secure than Linux alone.  But there are probably some mitigating factors.<p>2) &quot;And to the degree that unikernels don’t contain much code, it seems more by infancy (and, for the moment, irrelevancy) than by design.&quot;<p>I agree that unikernels are smaller at the moment mostly because they don&#x27;t have a lot of features.  (Writing in a memory safe language helps, but it also hurts!  Because I need to run linear algebra in production, etc.)  When you run them on a hypervisor, they actually rely on Linux for real drivers and such.  So you&#x27;re not actually getting rid of the code -- you&#x27;re moving it around.