Vad betyder "hårdvarustödda virtuella maskiner" mer än att den isolering de erbjuder numera har olika former av HW-acceleration i kisel?
Hypervisors ("VMs") och OS-kärnor gör i grunden exakt samma sak: de hanterar resurser och erbjuder olika former av services till sina "applikationer", en av de viktigaste services man erbjuder är isolering från övriga "applikationer".
För en hypervisor är applikationerna OS-kärnor, för OS-kärnor är applikationer "vanliga" applikationer (user-land processer).
HW-stödet för isolering kommer primärt ned till MMU. Hypervisors har en MMU av MMUs, kärnor har en MMU.
Båda har buggar, både i programvara och definitivt även i HW (nu när AMD börjar få en relevant andel i datacenter börjar också antalet hittade HW-buggar ökar rejält, tyvärr lär samma gälla ARM64 men där finns ändå fundamentala fördelar i att det är en långt renare/enklare ISA).
Hypervisors och OS-kärnor har olika uppgifter. Om vi delar dator-HW i ett datacenter används naturligtvis en hypervisor för att ge oss en OS-kärna var.
Men som utvecklare/organisation, ge ett enda relevant use-case (utöver att man av någon anledning måste köra saker på olika OSes) där det finns en fördel med VMs över containers. Det man vill uppnå är separation mellan olika services, containers har en högre grad av isolation än "vanliga" applikationer och egentligen räcker det stöd OS:et ger, men av pakteringsmässiga och mer eller mindre dålig ingenjörskonst i programmeringdesign har det visat sig väldigt fördelaktigt att paketera services i "containers".
Själva containers/applikationer har aldrig behövt köras som root, däremot behövde docker-services:eb köras som det för att kunna göra sin "magi" mot Linux cgroups/namespaces.
Detta var ett problem som löstest i kärnan 2016 med cgroups v2 och som markerats "stabilt" i Docker sedan 2020, v20.10.
Värt att notera är att Docker-desktop (Windows/MacOS) aldrig behövt köras som root då man där kör QEMU under huven då containers faktiskt kör Linux.
Edit: och att man alltid kan köra som "root" i containers är ju inget problem. Detta är ju en funktion hos Linux namespaces där både PIDs (via PID namespace) och användare (via USER namespace) har ett värde inuti container, men har något annat på "host" (så root i container kan vara vilken användare som helst på host).
En container har visserligen isolering mellan processer men man delar tyvärr väldigt mycket med kerneln.
Container-escape-sårbarheter är rätt vanliga och framförallt klart vanligare än VM-escapes.
Det finns gott om sårbarheter i kerneln eller andra delade resurser som man måste tänka på.
Andra problem är att det inte bara är kerneln man delar utan även annan HW.
T.ex ska du prata med ett annan hårdvara som delas mellan containrar eller kerneln:
(Såklart blir det samma problem om man delar hw mellan VMar, men det är klart mer ovanligt)
Men de två andra delarna som ger större problem för containrar än dedeikerade VMar är filsystem och nätverk.
Om t.ex OSet du kör container-runtimen på har massa nätverkstjänster som bindar resurser till alla nätverksinterface är/kan dessa också exponerade i en container. Vissa tjänster som t.ex en redis-databas är by default inte ens uppsatt med auth...
För filsystem har det visat sig rätt svårt att isolera bort filsystemet från en container när du samtidigt måste t.ex expnera /proc.
Och tittar man på docker så är det ju inte ovanligt att man exponerar hela sitt filsystem för alla containrar.
Sagan om root är också problematisk, för även om en process i en container som är root, inte är root för "kerneln" så är du root på filsystemet. Många applikationer är inte designade i sig för att köras med höga behörigheter och ger därför inbyggda sårbarheter såsom att man får skrivrättigheter till delar av sitt filsystem man annars inte ska köra.
Det jag vill säga att vi är rätt många som anser att Containrar inte alls är lika säker för separation som VMar.
