On 16/06/15 10:03, Martin Lucina wrote:
1) "marketing" this as a first-class feature will give people the wrong idea about what it is intended for. Someone will bake PHP and nginx into a single unikernel and then get upset when PHP stomps all over their nginx.
There are risks, I can't argue with that. Fools, better fools, and all that stuff. However, I'm almost certain that a different kind of better fool will be invented regardless of what we do or don't do.
2) figuring out your points 2) and 3) sounds suspiciously like implementing a shell. One of the major points I'm emphasising when I speak of unikernels is that there is no such thing as a shell, and thus your run-of-the-mill exploits cannot exec() arbitrary commands. Granted, in this case you still cannot execute *arbitrary* commands, but this feels like a step in that direction.
It's no more a shell than supporting passing a command line to a utility (which we already do). The facility *calls functions*. If you can direct execution to the code that calls the functions, why couldn't you just direct execution to what you actually want to call? Or is there some obfuscated exploit competition angle I'm missing?
When I spoke with Justin in Cambridge, he made the point that the set of command line utilities required to configure unikernels is quite small, and that a better approach would be to (semi-manually?) "librarise" the required utilities.
I guess this is the part where I say "boys, you weren't there back in good ole '09". If you want to have a stab, go ahead. Maintaining our own forks of the tools is not acceptable, so everything has to go into upstream.
