Earlier quoted context omitted.
Lambda and Fargate.
It was true for Fargate some time ago, but is not true anymore since quite a while. All Fargate tasks run on EC2 instances today.
Why Oxide Chose Illumos
81–90 of 177 posts
Re: Why Oxide Chose Illumos
#82Re: Why Oxide Chose Illumos
#83> QEMU is often the subject of bugs affecting its reliability and security. {{citation needed}}? When I ran the numbers in 2019, there hadn't been guest exploitable vulnerabilities that affected devices normally used for IaaS for 3 years. Pretty much every cloud outside the big three (AWS, GCE, Azure) runs on QEMU. Here's a talk I gave about it that includes that analysis: slides - https://kvm-forum.qemu.org/2019/kvm…
What do the big three use?
Oracle Cloud - QEMU/KVM
Scaleway - QEMU/KVM
Re: Why Oxide Chose Illumos
#84Somewhat related, they discussed why they chose to use ZFS for their storage backend as opposed to (say) Ceph in a podcast episode: * https://www.youtube.com/watch?v=UvEKSqBBcZw Certainly they already had experience with ZFS (as it is built into Illumos/Solaris), but as it was told to them by someone they trusted who ran a lot of Ceph: " Ceph is operated, not shipped [like ZFS] ". There's more care-and-feeding requir…
Re: Why Oxide Chose Illumos
#85I wonder if CockroachDB abandoning the open source license[0] will have an impact on their choice to use it. It looks like the RFD was posted 1 day before the license switch[1], and the RFD has a section on licenses stating they intended to stick to the OSS build: > To mitigate all this, we’re intending to stick with the OSS build, which includes no CCL code. [0] https://news.ycombinator.com/item?id=41256222 [1] http…
Re: Why Oxide Chose Illumos
#86> QEMU is often the subject of bugs affecting its reliability and security. {{citation needed}}? When I ran the numbers in 2019, there hadn't been guest exploitable vulnerabilities that affected devices normally used for IaaS for 3 years. Pretty much every cloud outside the big three (AWS, GCE, Azure) runs on QEMU. Here's a talk I gave about it that includes that analysis: slides - https://kvm-forum.qemu.org/2019/kvm…
I thought AWS uses KVM, which is the same VM that QEMU would use? Or am I mistaken?
Re: Why Oxide Chose Illumos
#87> QEMU is often the subject of bugs affecting its reliability and security. {{citation needed}}? When I ran the numbers in 2019, there hadn't been guest exploitable vulnerabilities that affected devices normally used for IaaS for 3 years. Pretty much every cloud outside the big three (AWS, GCE, Azure) runs on QEMU. Here's a talk I gave about it that includes that analysis: slides - https://kvm-forum.qemu.org/2019/kvm…
Re: Why Oxide Chose Illumos
#88Somewhat related, they discussed why they chose to use ZFS for their storage backend as opposed to (say) Ceph in a podcast episode: * https://www.youtube.com/watch?v=UvEKSqBBcZw Certainly they already had experience with ZFS (as it is built into Illumos/Solaris), but as it was told to them by someone they trusted who ran a lot of Ceph: " Ceph is operated, not shipped [like ZFS] ". There's more care-and-feeding requir…
Re: Why Oxide Chose Illumos
#89> QEMU is often the subject of bugs affecting its reliability and security. {{citation needed}}? When I ran the numbers in 2019, there hadn't been guest exploitable vulnerabilities that affected devices normally used for IaaS for 3 years. Pretty much every cloud outside the big three (AWS, GCE, Azure) runs on QEMU. Here's a talk I gave about it that includes that analysis: slides - https://kvm-forum.qemu.org/2019/kvm…
>Pretty much every cloud outside the big three (AWS, GCE, Azure) runs on QEMU. QEMU typically uses KVM for the hypervisor, so the vulnerabilities will be KVM anyway. The big three all use KVM now. Oxide decided to go with bhyve instead of KVM.
Usually QEMU runs heavily confined, but remote code execution in QEMU (remote = "from the guest") can be a first step towards exploiting a more serious local escalation via a kernel vulnerability. This second vulnerability can be in KVM or in any other part of the kernel.