gophering on
HN Gopher Feed (2017-07-10) - page 1 of 10
Unikernels are secure
139 points by ingve
eriknstr - 6 hours ago
> What we need is this:> * packet interface for the network> * a
block interface for some storage> * a serial port to output console
dataSome applications need additional devices, such as for example
hardware RNG, atomic clocks and/or GPGPU.
kasey_junk - 3 hours ago
I'm interested that they didn't list the "old" reason people
thought unikernels could be more secure.  That is that they could
be small enough to be completely written in higher languages.  With
something like you could bring
to bear formal methods in more straight forward ways.This of course
left the host still needing to be secured using traditional
approaches but that surface area was smaller.I'd buy that you can't
list that in an article about why all unikernels are already
secure, but that seemed to be the heart of the pitch to me when I
first started hearing it.
  woodrowbarlow - 1 hours ago
  well, you also have to keep in mind that this article is written
  by the CEO of a company producing a particular unikernel
  implementation -- one that isn't written in a higher language.
PieSquared - 6 hours ago
In addition to the blog post, there's an interesting discussion on
Github that happened before the blog post was published:
  Danihan - 6 hours ago
  Excellent discussion.  I'm not knowledgeable enough in Linux
  internals to know whether the ring0 versus ring3 criticism is
  warranted.  Is it just a matter of if/when an attacker achieves
  escalated privileges they will have far more attack surface on
    tscs37 - 4 hours ago
    There is quite a difference.Ring 3 is userspace, you can't
    interact with hardware or the operating system or anything not
    in Ring 3 directly.Ring 0 is everything. There are no
    restrictions and nothing stops you from writing "Ahahah You
    didn't say the magic word!" over your entire memory until the
    CPU crashes.Having root on a linux kernel is heavily restricted
    compared to this and still runs in Ring 3 like all other
    userspace code.As root, you still have to run the kernel. As
    Ring 0, you can replace the kernel. Or run your own OS.
rwmj - 6 hours ago
It's secure if and only if there's a formal proof.
  adrianN - 6 hours ago
  "Secure" sounds like a binary attribute but it's actually not. A
  formal proof doesn't save you from errors in the specification.
  At some point you need trust, the amount of trust needed is
  inversely proportional to the security.
    dreamdu5t - 6 hours ago
    Without a formal proof there is no measure of correctness at
      adrianN - 4 hours ago
      Lots of passing tests mean nothing to you?
        monocasa - 2 hours ago
        When an exploit only needs one edge case not handled right?
        No, lots of unit tests means nothing.  Maybe less than
        nothing due to the false sense of security they seem to
        give you.
  floatboth - 2 hours ago
  Who proves the proof though? :)
  elygre - 6 hours ago
  That's like saying that the world was flat before they could
  prove that it is round.
    Spivak - 6 hours ago
    No, that's like saying that we don't know what shape the world
    is before we could prove that it is round.
      rf15 - 6 hours ago
      No, it's like saying it is round "if and only if" we can
      prove that it is round.
geofft - 6 hours ago
> Unikernels have no shells. Most attacks I?ve seen invoke /bin/sh
to modify the system they are attacking. Without a shell the
attacker doesn?t have this opportunity. This forces the attacker to
use machine code to subvert the system, decreasing the likelihood
of succeeding with the attack.This argument is completely
  antientropic - 5 hours ago
  I assume it's referring to shell injection attacks. No shell
  means no shell injections. Of course, it also means that whatever
  functionality you were calling in a child process now must be in
  the same address space as the rest of your system. (E.g. rather
  than call Imagemagick to convert some incoming images from the
  client, you now must have a library with equivalent functionality
  in your unikernel.) Whether that's a net security improvement is
    geofft - 41 minutes ago
    If the argument is supposed to mean "Unikernel applications
    cannot call system("echo " + user_provided_input)", well, it's
    pretty easy to do that in conventional applications: just don't
    call system. If you want to be sure instead of relying on
    static analysis/code review, rm /bin/sh in your production
    containers, or something.Changing all your code to respect this
    standard is strictly less hard than porting it to a unikernel,
    because it's one step of porting it to a unikernel.
  tptacek - 6 hours ago
  And, while this is a more minor rebuttal, it's still worth
  saying: it's totally incorrect. Modern exploits (for definitions
  of "modern" meaning "written after 1999") do not care if you have
  a shell on your system.The author has presumably confused the
  concept of a POC, which is an exploit reduced and simplified for
  the consumption and understanding of laypeople, with that of a
  real exploit.
notacoward - 5 hours ago
"No system calls"Yeah, they're direct function calls now.  How
exactly is that more secure?  The author's right that many
traditional exploit paths are gone, but only because they've been
replaced by even easier ones.
  wmf - 5 hours ago
  They assume that 99% of libc was stripped out at build time. The
  full network stack is probably there but there might not be much
  filesystem code.
  robotresearcher - 4 hours ago
  Because you don't know how to call the functions, as explained in
  the article. To call a function, you need to know its address
  among other things. And you don't, since the address was decided
  at random at build time (or even boot time in some systems).
mtgx - 6 hours ago
> IncludeOS is a clean-slate unikernel written in C++ with
performance and security in mind.One of those things doesn't belong
there. Guess which?
  willtim - 43 minutes ago
  Yes it reads like satire. MirageOS, having been written in OCaml,
  would have a better claim to being written with security in mind.
  dmitrygr - 4 hours ago
  C++  (who uses that when perfectly good C is available?):)
Cieplak - 6 hours ago
Hypothetically, if there were a buffer overflow in a unikernel
process, wouldn't it potentially give the exploit full-system
access, whereas a normal operating system would detect the out-of-
bounds memory access and kill the process? I'm sorry if this is an
ignorant question.
  nkozyra - 6 hours ago
  I'm not super familiar with this, but it seems like the question
  is what is "full-system" in this case if each application is
  sandboxed with its own embedded kernel?  I mean there's no shell,
  ostensibly all other applications and system functions are
  bundled similarly, right?
    PeterisP - 6 hours ago
    It'd make exploits more difficult, but you'd still be able to
    upload your own code to do whatever you want.The trouble is
    that instead of uploading "/bin/sh" you'd have to upload the
    whole shell which you'd want to run; instead of making a
    syscall for something that a normal kernel would do but this
    one doesn't, you'd have to compile and upload appropriate code
    (including device drivers) to get that done.It'd be a "bring
    your own machine code" party.
  benchaney - 6 hours ago
  > if there were a buffer overflow in a unikernel process,
  wouldn't it potentially give the exploit full-system accessYes>
  whereas a normal operating system would detect the out-of-bounds
  memory access and kill the process?No. A buffer overflow in a
  normal operating system usually results in the the attacker
  gaining control over the process that the buffer overflow
  occurred in. This is not as bad as an attacker gaining full
  system access, but is generally plenty for an attacker to
  accomplish their goals.
  digi_owl - 6 hours ago
  Best i can tell, unikernels are a reaction to the shift from VMs
  to containers in cloud services. This by pairing down the content
  of a VM to the bare minimum.Meaning that if you have a buffer
  overflow or similar, all you could access was what was in the VM
  (unless you also happen to pack a VM escape).That said, i can't
  help think "DOS in a can" whenever i read about unikernels.
    perbu - 3 hours ago
    If it wasn't for the negative connotations people have with DOS
    I'd say it a lot more. Implementing a unikernel chain loader
    and a simple shell would be quite simple. That would be quite
    DOS-like.IncludeOS actually came out of a research need to
    stress-test hypervisors and run 10000 VMs on a single host.
    Since it is a clean slate system it has some different
    characteristics and those can be exploited in certain use cases
    and so people have kept on working on it.
  leggomylibro - 6 hours ago
  I could be wrong, but I think this is what Memory Management
  Units are for, on processor chips. It's one major differentiator
  between application processors and more embedded ones like
  Cortex-M or ATMega MCUs, which typically can't run complex modern
  operating systems. A lot of those chips have a simpler Memory
  Protection Unit that does basic enforcement of permissions like
  read+execute, read+write, etc, but they lack the ability to
  partition memory virtually between a large number of potential
  'owners.'I think - I'm still learning about this embedded stuff.
    vertex-four - 6 hours ago
    The point is that once you're doing that, and implementing
    communication between all your separate owners (which map
    pretty precisely to a reasonable definition of "processes")...
    you've just implemented another operating system, not a
  throwaway91111 - 6 hours ago
  Not necessarily. The kernel can run the code in non ring 0, ie in
  userspace. I can't speak to what is typical, but i imagine you'd
  get most of your gains by stripping most vulnerable code out of
  the system outright.
  PeterisP - 6 hours ago
  First, standard page fault mechanisms would still be in place,
  that's a processor/architecture feature, so out of bounds memory
  access would be detected just as in a normal operating system. Of
  course, a normal operating system does not detect many/most
  buffer overflows.In general, you could have a unikernel where
  it's impossible to get executable buffer overflow because there
  are no memory pages that are both writable and executable - as
  the article describes, that'd need some help from the hypervisor
  for the initialization.Return oriented programming exploits could
  work anyway, though.
benmmurphy - 6 hours ago
don't unikernels run everything in ring0. if you run everything in
ring0 you can't claim not having system calls is a security feature
msla - 5 hours ago
Unikernels are not that new. CMS running on VM has existed since
the 1960s, with CMS being the unikernel (actually, a unitasking OS
about as complex as MS-DOS) and VM being what's now called a
hypervisor: Something which multiplexes hardware, but provides no
APIs, such that VM guests think they're running alone on bare
hardware.(VM can even run VM as a guest, recursively, which is
useful for developing the newer version of VM on a machine other
people are using for other work.)Therefore, we can evaluate these
claims by asking what we know about security breaches on VM/CMS
  PhantomGremlin - 1 hours ago
  Something which multiplexes hardware, but provides no APIs, such
  that VM guests think they're running alone on bare hardware.There
  is what amounts to an "API". The virtualized software thinks it's
  talking directly to hardware, so the API is just an emulation of
  that hardware. Since controlling hardware is almost invariably
  messier than doing system calls, the API is actually more
  complex.Therefore, we can evaluate these claims by asking what we
  know about security breaches on VM/CMS systems.Here's an HN post
  I wrote a few years ago, about VM exploits: of exploits to
  be found, many of which were related to emulation of "I/O channel
  programs", which are, essentially, System/370 I/O "hardware".
    msla - 20 minutes ago
    > There is what amounts to an "API". The virtualized software
    thinks it's talking directly to hardware, so the API is just an
    emulation of that hardware. Since controlling hardware is
    almost invariably messier than doing system calls, the API is
    actually more complex.Nobody said a hypervisor was completely
    trivial, but just to be clear, a pure hypervisor wouldn't
    "emulate" any hardware except what was physically present on
    the system. The line between "virtual machine" and "hypervisor"
    and "emulator" are blurry enough as it is, and I'd like to be
    clear about what the subject of this little thread is.> Here's
    an HN post I wrote a few years ago, about VM exploits:> Plenty of
    exploits to be found, many of which were related to emulation
    of "I/O channel programs", which are, essentially, System/370
    I/O "hardware".Very interesting. Thank you.
nkozyra - 6 hours ago
The intro video is somewhat confusing - it indicates that they're
secure but if that they're "harder to attack" and says if they are
compromised they can be restored.  Also, he said "in the future, I
believe unikernels will be more or less unbreakable"I think you
could describe that as "more secure" or perhaps more generically
"safer" rather than "secure."
jeshwanth - 5 hours ago
Looks to be unikernel is just a RTOS, why the name unikernel then ?
Whats the difference with RTOS?
  numbsafari - 5 hours ago
  A unikernel could be designed as an RTOS, but not all RTOS are
  unikernels (in fact, I'm not aware that any are). Indeed, QNX, a
  RTOS, is not implemented using a single address space, nor is
  your application linked against the kernel and supporting
  libraries into a unikernel. While it's certainly possible that
  you could implement an application/unikernel with real-time
  guarantees, I'm not aware of a specific unikernel implementation
  that targets that space specifically.
  im_down_w_otp - 5 hours ago
  A RTOS means a specific thing regarding timing (and sometimes
  fairness) guarantees. A unikernel isn't that.
futurix - 3 hours ago
Generalisations are generalising.
RRRA - 4 hours ago
And if you run a Linux kernel with a C app as one, for example,
it's probably possible to run a shellcode proxy in memory, even if
you can't modify the app code, you could ROP if a big enough buffer
overflow is possible on the stack, etc.?
m3kw9 - 4 hours ago
Claiming something is secure is more like claiming an over unity
perpetual machine
peterwwillis - 6 hours ago
"Unikernels have no shells. Most attacks I?ve seen invoke /bin/sh
to modify the system they are attacking. Without a shell the
attacker doesn?t have this opportunity. This forces the attacker to
use machine code to subvert the system, decreasing the likelihood
of succeeding with the attack."Timmy the software developer and his
many years of forensic analysis have led him to believe that you
need a shell to root something. Literally the entire page's
takeaway about security is "It's hard to use, so it's secure!"
wglb - 5 hours ago
I would hesitate to call something Secure unless some major pen
test effort were engaged to try to break it.This is a corollary to
"If it isn't tested it is broken". (Another corollary is "Even if
it is tested, it may still be broken.")  This is more so with
security.Just looking at some of the assumptions, e.g., that the
lack of a shell significantly increases the difficulty of an
attack, leaves me with doubts about the claims.
  cwp - 2 hours ago
  Yes, exactly. The article would be much stronger if it also
  covered ways in which unikernels either don't improve security,
  or are actually more vulnerable.
  perbu - 3 hours ago
  Hi author here. I agree wholeheartedly. I wasn't thinking in
  absolutes, but I absolutely can understand how it could read that
  way. I could have titled the post "Unikernels are resonably
  secure", but then nobody would have read it.I was doubtful about
  mentioning the lack of shell. Technically it doesn't really do
  much in terms of security, but it does make a compromise harder.
  And currently, where we stand, a lot of the security comes from
  things being really, really hard to compromise. Guessing
  adresses, not having a shell, potentially no filesystem, etc.
    wglb - 3 hours ago
    With "Unikernels are reasonably secure", but then nobody would
    have read it., you might also take into account whether the
    audience, having read it, are happy that they did. The title
    sounded pretty absolute.So you do have a noble goal.  When I am
    asked to assess software, to gain a first order approximation,
    I often look at the culture of the organization that produced
    it. On the high end, that often translates to some sort of
    formal process involving un-fun letters like 'ISO' and
    'SOC'.For smaller organizations, or OSS software, I try to get
    a feel for how the developers seem to be thinking about
    security. Some of the cultural things I see in your writeup are
    encouraging--Smaller Codebase, Removing hardware emulation,
    Cutting off access to ring 0--all bode well for how you are
    thinking about producing secure software.But there are some
    things that are missing from your description. What is your
    development process? In particular how and when do you attack
    your assumptions about how the code actually works? What flaws
    have you found in your testing? Zero findings could mean 1) it
    wasn't tested 2) it wasn't tested very hard 3) the testers were
    not very good at security testing.And as OpenBSD's history has
    illustrated, some things are totally secure until they aren't.
    dvfjsdhgfv - 1 hours ago
    To be fair, I enjoyed reading the article. My conclusion though
    is that unikernels (an interesting concept in itself) offer
    only a part of the functionality of a standard OS. As such, it
    might actually be easier to limit the functionality of a
    general OS in such a way that it does only what needs to be
    done and nothing more - and there already some relatively
    mature solutions for that.
  dvfjsdhgfv - 5 hours ago
  My thoughts exactly. If they wrote "more secure", this would make
  more sense. In the current form it's just boasting.
api - 5 hours ago
So now the hypervisor is ring0, the cloud provider is the OS, and
the OS is the app. IP is the IPC and the Internet is the IPC bus.I
suppose the hypervisor is more minimal and secure. Tenenbaum, thou
art avenged.
FungalRaincloud - 6 hours ago
I don't really like the argument that something is 'secure' because
it is not vulnerable in the same ways that an alternative is. I
think this is why I like talking about encryption so much. It's
possible to mathematically prove the security of encryption
algorithms, and all that's really left to pick apart is the
implementation, politics and impact.
  y7 - 6 hours ago
  This is not true at all for most forms of cryptography. Hash
  functions and symmetric cryptography are just shown to be
  resistant against all known attacks. For public-key cryptography
  there are sometimes security reductions to computational problems
  that are thought to be hard, but even schemes like RSA do not
  have such a security proof.
  bmc7505 - 6 hours ago
  Unless you're dealing with OTPs, hashing, or lattice-based
  schemes, there are almost no information theoretical guarantees
  in encryption. For a field that uses math so heavily, it's
  surprising how rare traditional proofs are in the cryptology
  literature. Most encryption schemes are specifically designed to
  be hard to analyze.
    swordswinger12 - 5 hours ago
    This isn't for lack of trying on the part of cryptographers -
    unconditional proofs of security for most modern cryptosystems
    would imply that P and NP are separate. For example, a direct
    proof that SHA-256 is collision-resistant would imply that one-
    way functions exist unconditionally.
  vertex-four - 6 hours ago
  Ehh... you can often prove that X algorithm is not susceptible to
  A, B or C attacks, but you cannot usually prove that the
  algorithm is "secure" in a fundamental sense.
    jacksnipe - 6 hours ago can prove
    that it's secure in that the algorithm itself does not leak
      klodolph - 5 hours ago
      With some exceptions, those proofs make assumptions about
      their primitives like having block ciphers be "unpredictable
      permutations" or having hash functions be "random oracles".
      These proofs also make assumptions that information doesn't
      leak in other ways (like BEAST, heartbleed, timing attacks,
      poor entropy sources, etc).In other words, those proofs don't
      have as much real-world significance as you'd like.
      taeric - 6 hours ago
      Yeah, but this is not what most people think of when they
      think secure, is it?  That is, this proves that people have
      to actually break an algorithm to know what it is protecting.
      This does nothing to show that an algorithm is
      unbreakable.(As an example of my understanding, rot13 does
      nothing to randomize distribution of characters, so it
      "leaks" information about what it has modified.  This sort of
      leakage can be proven as absent from your algorithm.
      Anything else is a bit tougher.)
  eutectic - 6 hours ago
  Even crypto algorithms rely on unproven assumptions for their
  security, even ignoring e.g. side-channel attacks.
    warkdarrior - 2 hours ago
    Not true. Look up "resilience to information leakage".
nneonneo - 6 hours ago
So, basically, we're going to run all your code at ring0, so a
single bug is now either a total DoS (kernel shuts down) or an
exploit vector straight to ring0. Although they talk hypothetically
about a defense for that involving the MMU, this is not implemented
in IncludeOS.The build should not be relied on to be secure either;
certain classes of memory disclosure bugs could leak out enough
memory to let you work out e.g. a ROP payload, which wouldn't
require injecting any machine code necessarily. Plus, a long-lived
machine, or a single instance deployed across many machines, would
present insufficient diversity to protect against a determined
attacker. The gist here appears to be the notion that their build
diversity gives them most of their security, while they've
eliminated most of the traditional defense layers (ASLR, DEP/NX,
privilege separation, API isolation, etc.)If the attacker gets her
machine code running in the unikernel environment, it's game over
no matter what. The machine code can just directly implement a
subset of needed functionality without having to call out to
unikernel functions.In short - this post has a hell of a click bait
title but really insufficient evidence to suggest that these are
truly "secure".
  rrdharan - 5 hours ago
  > In short - this post has a hell of a click bait title but
  really insufficient evidence to suggest that these are truly
  "secure".From the original pull request drafting this post:>
  While I agree that making hyperbolical claims isn't typically
  good I'm not sure if it is bad here. There seem to be a tradition
  in unikernel land with outlandish claims in various blogposts
  ("Unikernels will kill containers in five years", "Unikernels are
  unfit for production", etc) so I wrote it with that tone in
  wmf - 5 hours ago
  Keep in mind that it's ring 0 inside a VM that contains almost
  nothing. Really a unikernel is just a process that uses
  hypercalls instead of system calls. So exploiting a unikernel is
  no worse than exploiting a user process, and the article explains
  a few reasons it could be more secure.But they should definitely
  add ASLR.
    language - 3 hours ago
    Just like an operating-system executes processes, a VMM
    executes unikernels. An operating system is responsible for
    randomizing the layout of processes in memory. Shouldn't the
    actual question here be "Does my hypervisor implement some
    mechanism for randomizing the layout of my unikernel?"
      wmf - 2 hours ago
      I don't think it matters whether it's implemented by the
      hypervisor or the unikernel since it's all open source. But
      for compatibility with existing hypervisors/clouds one could
      imagine a boot loader that loads the main unikernel at a
      random address, sets up page tables with NX, and then makes a
      one-way transition to ring 3 so that the page tables cannot
      be modified.
        language - 1 hours ago
        > one could imagine a boot loader that loads the main
        unikernel at a random address, sets up page tables with NX,
        and then makes a one-way transition to ring 3True - I
        suppose I'm trying to hold onto the "kernel:hypervisor ::
        process:unikernel" analogy here for no good reason.
        Following it suggested that it might be the hypervisor's
    perbu - 3 hours ago
    IncludeOS has ASLR. Or as close to ASLR as you can get without
    dynamic linking. We randomize the layout when we link. And
    since we typically re-link the image on each configuration
    change in a network of 1000s VMs each one will have a different
    memory layout.
meson2k - 6 hours ago
>  Good luck guessing that address. Our own unikernel, IncludeOS,
randomizes addresses at each build, so even with access to source
code you still don?t know the memory layout."There is one mortal
sin in computer security (or by the way, in any kind of security)
that is feeling safe. It?s just a variation of pride to be true,
but it?s very deadly. Blindly trusting a protection technology is
an extreme error."Read up on DEP. Randomizing function addresses at
each build is useless when it comes to attack mitigation. You need
to randomize addresses at each execution.
  KirinDave - 3 hours ago
  Pardon me, but this seems pretty different from the use cases of
  DEP. Perhaps you'd like to expound further on this.Imagine a
  standard webapp deployed via CI. Each time any feature is shipped
  the entire layout is randomized and then deployed. While a
  redundant system will have multiple copies with an identical
  layout, that layout will rotate. If required, a CI process could
  rebuild the system into N parallel groups with N different
  layouts (your degree of paranoia is the salt to taste here).Given
  that these systems are frequently rebuilt with each deploy it
  seems nearly identical to me in practice to a relink-on-run.
  agumonkey - 6 hours ago
  is linux randomizing is per exec ?ps: BSD have started to
  randomize at boot time, fun times
    geofft - 6 hours ago
    > is linux randomizing is per exec ?Not entirely sure what
    you're meaning to ask, but yes, Linux does KASLR and tries very
    hard not to leak pointer addresses from the running kernel to
    unprivileged userspace:'s
    been enabled by default since the upstream 4.12 kernel, and
    usually well before that in distros.
      _joel - 6 hours ago
      KALSR's not the same as ASLR (although ideologically
      related). ALSR has been around for a good number of years in
      userspace via randomize_va_space sysctl(edit I presume that's
      what the poster above mentioned re: per exec)
        agumonkey - 5 hours ago
        yes ALSR, sorry, acronym fail on my part. So ALSR does
        randomize bindings on each execution ?
          majewsky - 5 hours ago
          Yes. If I run e.g. `ldd /bin/bash` multiple times, it
          shows different memory addresses each time. That's ASLR.
          agumonkey - 4 hours ago
          I never bothered to check, what a m... I am. Thanks a lot
          language - 4 hours ago
          Also worth mentioning that `ldd` only demonstrates how
          shared libraries are mmap'ed at randomized locations.
          Stack and heap allocations are also randomized at
          execution time.
          strcat - 1 hours ago
          cat /proc/self/maps is a better way to see that. If it's
          built with PIE, the executable base is randomized. Some
          distributions use full ASLR across the board (Alpine,
          Android, ChromeOS, Hardened Gentoo) while others don't
          yet enable PIE globally or have only recently started and
          it isn't all pushed out yet (OpenSUSE, Fedora, Debian).
dreamdu5t - 6 hours ago
Hard to take claims of security seriously for untyped languages
which are not provably correct and lack a denotational semantics.
Let's start by provably not compiling buffer overflows and memory
overreads considering those are the vast majority of RCE and
privilege escalation.
  perbu - 3 hours ago
  C++ is strongly typed. I believe there are frameworks that will
  give you denotational semantics in C++.It shouldn't surprise
  anyone that feature X is available in C++. But I acknowledge
  there are tons of shotguns strewn around everywhere in C++ so you
  can blow your feet off.
    willtim - 37 minutes ago
    C++ is not "strongly typed" when compared to almost any other
    statically-typed language, e.g. Ada, OCaml, Haskell or Rust.
    This is a big part of why it is so insecure.
kmicklas - 4 hours ago
"Secure" and yet they aren't even using a memory safe language such
as Rust.
rdtsc - 3 hours ago
> There are two aspects of unikernel security. There are two
aspects of unikernel security. One is the vector into the VM and
the other is the vector from the VM into the hypervisor.The "vector
into the VM" might not be as obvious. For example, in a network
security contest in college I compromised the source repository of
the  server to give my team an advantage and won. That was before
git it was just a folder on the server. Others argued it wasn't
fair but the instructor sided with me since that's a plausible
scenario in real life.There also tempest-like attacks for
extracting private keys and such, so it's there at also at least
the 3rd vector - from VM to the hardware as well. And forth from VM
to the network (but I guess these can be subsumed in the "to the
hypervisor" case).
skywhopper - 3 hours ago
So to summarize, unikernels stop a couple of attack vectors
(syscalls and running other programs (notably shells) that are
loadable from well-known paths). Address randomization is not
unique to unikernels, and the other benefits are theoretical for
the time being until hypervisors provide more unikernel support
(though the mention of paravirtualization makes me think
performance (particularly network) in this theroetical hyper-
restricted mode will be poor).While I certainly sympathize with the
idea that the typical kitchen-sink deployment of a full suite of
administrative/troubleshooting/build tools on an application server
is a security risk, it seems the actual improvements enumerated
here are relatively small potatoes.Apologies for not knowing a lot
about the state of the art here, but I'm curious about how these
unikernels address VM-internal security (eg, network, filesystem,
inter-process level stuff). Do you farm all of that out to the
hypervisor? Design around the lack of it? _Is_ there even "inter-
process stuff"?
floobyhoob - 40 minutes ago
The real problem for unikernels is that they are effectively
irrelevant until the major clouds provide millisecond boot times
along with appropriate pricing models that charge for execution on
a millisecond level basis.Developers love to write code, but unless
unikernel developers start speaking up instead of writing code, the
major clouds won't get on board and provide the needed fast boot
times plus pricing, which makes all this unikernel code not a lot
more than interesting personal / academic projects.Questions of
unikernel security are certainly academic if the cloud
infrastructure doesn't run them in the most effective manner.
  weberc2 - 35 minutes ago
  Why are millisecond bit times necessary? Linux doesn't boot in a
    floobyhoob - 33 minutes ago
    Because you can then build single function unikernels that do
    one thing very fast then disappear from RAM.The point being
    that docker is actually a really clunky thing that is
    reinventing the virtual server ecosystem within the OS which is
    pointless.Serverless systems are better implemented as
    unikernels than docker images.Unikernels make it possible to
    boot an entire OS in milliseconds, service an inbound web
    request, then disappear.
      corndoge - 8 minutes ago
      What's the use case for booting an entire OS to service a
sethev - 6 hours ago
A unikernel is running a single process in a single address space.
So yes, if you compromise the app you compromise the whole system
but the whole system is the app.
  im_down_w_otp - 5 hours ago
  That's not entirely true in practice. I'm currently playing with
  rump kernels deployed on top of seL4's hypervisor to give my
  platform the security posture of a unikernel inside the security
  posture of seL4 VM isolation.You could potentially compromise the
  rump kernel, but you still wouldn't be able to break out of the
  VM's isolation context.
    tscs37 - 4 hours ago
    The app is still compromised.On top of that, you didn't get to
    reap the benefits of any of the protections you get from a
    proper Kernel like Ring 3 execution, NX bits on pages, guard
    pages on the stack, etc.
dmitrygr - 6 hours ago
The argument that something IS secure is somehow supported by a
whole lot of hypotheticals of the form "we could do $X and that
would be secure if someone also did $Y".So say it how it is:
unikernels COULD be secure if all this work that needs to be done
and we haven't done was done...maybe
  wmf - 5 hours ago
  That's par for the course. Unikernel people talk about VMs that
  use megabytes of RAM while cloud providers only provide
  gigabytes. Unikernel people talk about spawning VMs in tens of
  milliseconds while clouds take tens of seconds.