3 ms·

If it delivers on its promise, this could be very useful. I'm no kernel hacker, but any tool that makes working with kernel code easier and safer is a real boon

If it delivers on its promise, this could be very useful. I'm no kernel hacker, but any tool that makes working with kernel code easier and safer is a real boon!

AstralStorm 7y ago
There are much better tools. You really shouldn't run user code in kernel space.
- vardump 7y ago
  Except for example when the user needs to either do something only doable in kernel space or to diagnose and analyze kernel behavior. I would have loved an option like this for example when working with a power management issue last time (PCI-e surprise removal and hot-plug can be annoying!)... Sure, I can use remote kernel debuggers etc., but those can be sometimes a hassle to set up, not always the most convenient option. Like when an issue occurs on the other side of the world, and kernel dumps and tracing leads nowhere. Having an extra option for easy injection of code in kernel would be a nice thing to have in the toolbox. In other words, one-off scenarios. It wouldn't be something you'd release for wider use. Knee-jerk reactions have been somewhat off-putting lately. All of us should keep in mind other people might have a completely different mindset, problems and needs than our own. We should celebrate new ideas and novel points of view and not to brainlessly use existing dogma or cheap talking points to immediately slam them. (I've developed (among other things) commercial kernel drivers for Windows. And "for fun" for Linux just to keep my skills updated.)
  - rwmj 7y ago
    That's just a side effect of the way Linux puts everything into a giant trusted binary. The GP is correct that we should separate out services (probably to separate sockets until Spectre-like attacks are fixed), even if it's also true that when dealing with Linux-as-it-is-today the solution to everything being in the kernel is to put more stuff in the kernel.
    - aey 7y ago
      Any sandboxing adds a performance overhead. There is no free lunch in Operating Systems.
      - pjmlp 7y ago
        A tiny performance overhead is worthwhile in name of security. For example, I don't remember the last time I cared about disabling bounds checking, even in C++ code (VC++ allows to keep it on).
        rurban 7y ago
        Tell that the various libc maintainers. They are blocking the C11 Annex K (safe bounds checks) for over a decade now. And talking about performance With good compilers my secure memcpy_s is actually faster than the glibc or BSD libc memcpy, with compile-time constexpr.
        pjmlp 7y ago
        I would blame ISO C, by making Annex K optional, and not caring to improve C's safety in general.
        aey 7y ago
        I am quite happy with rust these days. But it still lacks great ‘no allocation’ libraries.
        rurban 7y ago
        Then you are illusional. None of their safety guarantees are real. Memory, type, concurrency, none. But talking to them fall on deaf ears. Its called hype driven development and very popular amongst HN folks. There exist plenty of real safe languages though.
        7y ago

If it delivers on its promise, this could be very useful. I'm no kernel hacker, but any tool that makes working with kernel code easier and safer is a real boon!

AstralStorm 7y ago

There are much better tools. You really shouldn't run user code in kernel space.

vardump 7y ago
Except for example when the user needs to either do something only doable in kernel space or to diagnose and analyze kernel behavior. I would have loved an option like this for example when working with a power management issue last time (PCI-e surprise removal and hot-plug can be annoying!)... Sure, I can use remote kernel debuggers etc., but those can be sometimes a hassle to set up, not always the most convenient option. Like when an issue occurs on the other side of the world, and kernel dumps and tracing leads nowhere. Having an extra option for easy injection of code in kernel would be a nice thing to have in the toolbox. In other words, one-off scenarios. It wouldn't be something you'd release for wider use. Knee-jerk reactions have been somewhat off-putting lately. All of us should keep in mind other people might have a completely different mindset, problems and needs than our own. We should celebrate new ideas and novel points of view and not to brainlessly use existing dogma or cheap talking points to immediately slam them. (I've developed (among other things) commercial kernel drivers for Windows. And "for fun" for Linux just to keep my skills updated.)
- rwmj 7y ago
  That's just a side effect of the way Linux puts everything into a giant trusted binary. The GP is correct that we should separate out services (probably to separate sockets until Spectre-like attacks are fixed), even if it's also true that when dealing with Linux-as-it-is-today the solution to everything being in the kernel is to put more stuff in the kernel.
  - aey 7y ago
    Any sandboxing adds a performance overhead. There is no free lunch in Operating Systems.
    - pjmlp 7y ago
      A tiny performance overhead is worthwhile in name of security. For example, I don't remember the last time I cared about disabling bounds checking, even in C++ code (VC++ allows to keep it on).
      - rurban 7y ago
        Tell that the various libc maintainers. They are blocking the C11 Annex K (safe bounds checks) for over a decade now. And talking about performance With good compilers my secure memcpy_s is actually faster than the glibc or BSD libc memcpy, with compile-time constexpr.
        pjmlp 7y ago
        I would blame ISO C, by making Annex K optional, and not caring to improve C's safety in general.
        aey 7y ago
        I am quite happy with rust these days. But it still lacks great ‘no allocation’ libraries.
        rurban 7y ago
        Then you are illusional. None of their safety guarantees are real. Memory, type, concurrency, none. But talking to them fall on deaf ears. Its called hype driven development and very popular amongst HN folks. There exist plenty of real safe languages though.
        7y ago