Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unikernels are secure

unikernel.org

Post reply on HN
Print view View original

91–100 of 142 posts

Re: Unikernels are secure

#91

Post by geofft »

antientropic wrote: post #49
geofft wrote: post #27

> 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 incoherent.

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…

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.

Re: Unikernels are secure

#92

Post by floobyhoob »

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.

Re: Unikernels are secure

#93

Post by willtim »

perbu wrote: post #72
dreamdu5t wrote: post #13

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.

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.

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.

Re: Unikernels are secure

#94

Post by weberc2 »

floobyhoob wrote: post #92

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…

Why are millisecond bit times necessary? Linux doesn't boot in a millisecond...

Re: Unikernels are secure

#95

Post by floobyhoob »

weberc2 wrote: post #94
floobyhoob wrote: post #92

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…

Why are millisecond bit times necessary? Linux doesn't boot in a millisecond...

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.

Re: Unikernels are secure

#96

Post by msla »

PhantomGremlin wrote: post #87
msla wrote: post #48

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 ver…

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…

> 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: https://news.ycombinator.com/item?id=9241807

> 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.

Re: Unikernels are secure

#97

Post by corndoge »

floobyhoob wrote: post #95
weberc2 wrote: post #94

Earlier quoted context omitted.

Why are millisecond bit times necessary? Linux doesn't boot in a millisecond...

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 req…

What's the use case for booting an entire OS to service a request?

Re: Unikernels are secure

#98

Post by hderms »

msla wrote: post #48

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 ver…

In addition one would have to address hardware virtualization features that would increase security, no?

Re: Unikernels are secure

#99

Post by eriknstr »

rrdharan wrote: post #43
nneonneo wrote: post #33

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 ou…

> 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 year…

If the unikernel people keep up with the hyperbole the potential audience will learn to just ignore most posts about unikernels. Please don't use hyperbole.

Re: Unikernels are secure

#100

Post by 45h34jh53k4j »

monocasa wrote: post #81
adrianN wrote: post #62

Earlier quoted context omitted.

Lots of passing tests mean nothing to you?

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.

lets not go too far! tests can provide a security advantage over regressions or bugs introduced in the future. They are necessary but not sufficient to prove a particular security level.
Post reply on HN