Hacker News Reader

Comment by externalreality | Hacker News Reader

I think there on the right track from a usability standpoint in making tools that will help build a minimal kernel by determining what system-calls need to be included based on the application. Pulling in the correct dynamic libraries is also important.

I envision a system that can use static analysis to chose system calls, find libraries (ldd), and perhaps even choose between appropriate algorithms (thread schedulers) all based on the particular program it is going to run. In other words Kernels that optimize themselves based on the program much like compilers optimize programs based on the various things like architecture. I think uni-kernels have great potential.

Also for system calls that are not security concerns or performance concerns why not continue to proxy them to the host kernel as Hermit core does?

View on HN

Unfortunately a system like this can't work for every binary: system calls and dynamic libraries can't be statically inferred in all cases.

Could you please explain why they can't be?

It seems counter intuitive to me. It seems you're saying that static analysis cannot reach every branch of the program (and thus its underlying system libraries).

I'm surely missing something and would be grateful to anyone helping me out!

It is easy to write a function, that makes a syscall directly and not via well known paths in the libc or similar. And then the syscall number can be a variable instead of constant and determining that value statically means solving the halting problem. Q.e.d.

Since conservative approximation is still useful, halting problem doesn't matter.

That is, let's say syscall 1 is definitely used, syscall 2 is definitely not used, whether syscall 3 is used depends on halting problem. Including only 1 and 3 to unikernel is safe and better than including all of 1, 2, 3.

This works in trivial problems. Any moderately sized program I can imagine right now will result in an analysis that is equivalent to "this uses everything"

You can read Chiba's thesis which explains exactly how they are able to detect the systems calls made by the ELF using static analysis and code flow execution analysis (the techniques all seems very simple and ingenious - you can even try to write a little program yourself that uses their algorithm if you don't believe them). The thesis explains that there are edge cases and how they work around them. Remember they have to handle all of the system calls or the program would suffer from run-time errors.

Dlopen allows for dynamic linking of symbols e.g. based on user input or local circumstances (cpu capabilities, type of db being connected to opens a different set of libs for different versions etc.).

You could provide hints for these circumstances, or change a program to work differently to avoid the practice, but having library resolution delayed until runtime and until after the program has started is a real thing.

Reply on news.ycombinator.com