Reducing attack surface is definitely a plus but it is nowhere close to the number one security benefit of running unikernels.
That's why I never really liked talking about "reducing attack surface" that much because folk inevitably turn to lines and code, which while reducing is good, just simply doesn't communicate what the biggest problem truly is.
Vuln exploitation is the number one entry point for data breaches and os command injection is the number one CWE in CISA Kev from last year.
System intrusion was repeated something like 64 times in last year's DBIR.
The operating system itself is literally the problem as it's inherently meant to run many different programs whereas unikernels only run one.
Honestly, I think there is a lot of similarities between unikernels, at least the one I'm active with and qubes. The big difference to me is that qubes is more desktop/consumer focused and nanos (the one I'm involved with) is more server-focused but the same sort of ideology/principles gets exposed - just at varying levels and because of the end environment they get architected differently.
That's why I never really liked talking about "reducing attack surface" that much because folk inevitably turn to lines and code, which while reducing is good, just simply doesn't communicate what the biggest problem truly is.
Vuln exploitation is the number one entry point for data breaches and os command injection is the number one CWE in CISA Kev from last year.
System intrusion was repeated something like 64 times in last year's DBIR.
The operating system itself is literally the problem as it's inherently meant to run many different programs whereas unikernels only run one.
Unless you rely on security through compartmentalization. See: https://qubes-os.org