3 ms·

+1 on single-copy frequently being faster than zero-copy. See https://lwn.net/Articles/580194/ https://lwn.net/Articles/580194/ for a real-world example from th

by gue5t 9y ago

+1 on single-copy frequently being faster than zero-copy. See https://lwn.net/Articles/580194/ https://lwn.net/Articles/580194/ for a real-world example from the Linux kernel. On the topic at large, I think microkernel vs monolithic is not actually the important distinction in kernel design; robustness could improved vastly if the business logic of a kernel were implemented in a memory-safe language instead of C or C++. Register bashing and system setup won't ever be effectively captured by a typesystem (knowing what the semantics of hardware are is the hard problem, and GIGO applies to typesystems as much as anything), but most vulnerabilities are in code that doesn't directly interact with hardware (even if they're in a driver for some obscure hardware, it's generally the syscall-facing side that gets exploited). I'd like to see more OS development look at non-UNIX designs, rather than trying a million different ways to implementa UNIX-like interface.

aidenn0 9y ago
Also, as a note, high-reliability microkernels disallow direct access to DMA registers (as, absent an I/O MMU, being able to write to a DMA register is the same as being able to write to any physical memory), and instead provide an API for programming them that can be verified on its own. This is often just dozens of lines of code, so can be as correct as the hardware. So the separation of register-bashing vs. the rest of the software already exists, but it solves the memory safety problem by just moving the unsafe code out of the kernel. I agree that memory-safe languages need to come into low-level systems programming, but garbage-collection is a non-starter for many many reasons, and the various academic languages (e.g. cyclone) have not made any inroads to industry that I'm aware of. Rust is very interesting to me in this field because the simple fact that it originated outside of academia may make it more palatable to many people; time will tell. [edit] I still think a microkernel is a good idea even with a memory-safe language just for defense in depth if nothing else (memory-safe runtimes tend to be complicated, and complicated code tends to have bugs).
- pjmlp 9y ago
  > I agree that memory-safe languages need to come into low-level systems programming, but garbage-collection is a non-starter for many many reasons, and the various academic languages (e.g. cyclone) have not made any inroads to industry that I'm aware of. Yet it was proven to work with: - Mesa/Cedar at Xerox PARC - Oberon, Oberon-2, Active Oberon at ETHZ - Modula-2+, Modula-3 at DEC/Olivetti - Sing# and System C# at MSR Apparently we can only get it properly done if a big company bullies the developers to adopt such an approach. Which is why I see as positive Apple, Google, Microsoft bullying devs to use mostly Swift, Java/Kotlin/Dart and .NET on their platforms, with C and C++'s role reduced to a few use cases. It really annoys me when I need to use the NDK on Google's case, but somehow it makes sense from security point of view.
  - wolfgke 9y ago
    > Which is why I see as positive Apple, Google, Microsoft bullying devs to use mostly Swift, Java/Kotlin/Dart and .NET on their platforms, with C and C++'s role reduced to a few use cases. Microsoft is actively encouraging developers to use C++ for development on Windows. The phase when Microsoft was trying to push (or as you call it "bully") developers into ".net for everything" is long gone.
    - pjmlp 9y ago
      Try to find C++ talks for Windows development on BUILD 2016 and 2017 archives. Check how many C++ samples exist on the Windows 10 SDK samples. See the blog about the new Windows UI Composition engine and which languages are being used on the demos. Then let us know where is this active encouragement you are speaking about. C++ is being driven down the stack as the implementation language for the UWP COM layer, kernel programming, graphics and audio. Everything else is .NET Native.
      - wolfgke 9y ago
        > Try to find C++ talks for Windows development on BUILD 2016 and 2017 archives. See the talks at CppCon 2016: > https://channel9.msdn.com/Events/CPP/CppCon-2016 https://channel9.msdn.com/Events/CPP/CppCon-2016
        pjmlp 9y ago
        I watched those talks live. Since October 2016 there is radio silence on the actual state of C++/WinRT, including the status of feature parity with C++/CX for XAML, Blend and creation of UWP components. VS 2017 already had two releases since those presentations. The only Microsoft talk at CppCon 2017 are about VS Code support for C++ and ANSI C++ compliance, nothing relevant to actual Windows 10 application development. Any long time Windows developer is recognising the signs that UWP is turning into what Longhorn aspired to be, just remains to be seen how willing Microsoft is to keep pushing it. [0] https://cppcon2017.sched.com/ https://cppcon2017.sched.com/
  - 9y ago

by gue5t 9y ago

aidenn0 9y ago

Also, as a note, high-reliability microkernels disallow direct access to DMA registers (as, absent an I/O MMU, being able to write to a DMA register is the same as being able to write to any physical memory), and instead provide an API for programming them that can be verified on its own. This is often just dozens of lines of code, so can be as correct as the hardware. So the separation of register-bashing vs. the rest of the software already exists, but it solves the memory safety problem by just moving the unsafe code out of the kernel. I agree that memory-safe languages need to come into low-level systems programming, but garbage-collection is a non-starter for many many reasons, and the various academic languages (e.g. cyclone) have not made any inroads to industry that I'm aware of. Rust is very interesting to me in this field because the simple fact that it originated outside of academia may make it more palatable to many people; time will tell. [edit] I still think a microkernel is a good idea even with a memory-safe language just for defense in depth if nothing else (memory-safe runtimes tend to be complicated, and complicated code tends to have bugs).

pjmlp 9y ago
> I agree that memory-safe languages need to come into low-level systems programming, but garbage-collection is a non-starter for many many reasons, and the various academic languages (e.g. cyclone) have not made any inroads to industry that I'm aware of. Yet it was proven to work with: - Mesa/Cedar at Xerox PARC - Oberon, Oberon-2, Active Oberon at ETHZ - Modula-2+, Modula-3 at DEC/Olivetti - Sing# and System C# at MSR Apparently we can only get it properly done if a big company bullies the developers to adopt such an approach. Which is why I see as positive Apple, Google, Microsoft bullying devs to use mostly Swift, Java/Kotlin/Dart and .NET on their platforms, with C and C++'s role reduced to a few use cases. It really annoys me when I need to use the NDK on Google's case, but somehow it makes sense from security point of view.
- wolfgke 9y ago
  > Which is why I see as positive Apple, Google, Microsoft bullying devs to use mostly Swift, Java/Kotlin/Dart and .NET on their platforms, with C and C++'s role reduced to a few use cases. Microsoft is actively encouraging developers to use C++ for development on Windows. The phase when Microsoft was trying to push (or as you call it "bully") developers into ".net for everything" is long gone.
  - pjmlp 9y ago
    Try to find C++ talks for Windows development on BUILD 2016 and 2017 archives. Check how many C++ samples exist on the Windows 10 SDK samples. See the blog about the new Windows UI Composition engine and which languages are being used on the demos. Then let us know where is this active encouragement you are speaking about. C++ is being driven down the stack as the implementation language for the UWP COM layer, kernel programming, graphics and audio. Everything else is .NET Native.
    - wolfgke 9y ago
      > Try to find C++ talks for Windows development on BUILD 2016 and 2017 archives. See the talks at CppCon 2016: > https://channel9.msdn.com/Events/CPP/CppCon-2016 https://channel9.msdn.com/Events/CPP/CppCon-2016
      - pjmlp 9y ago
        I watched those talks live. Since October 2016 there is radio silence on the actual state of C++/WinRT, including the status of feature parity with C++/CX for XAML, Blend and creation of UWP components. VS 2017 already had two releases since those presentations. The only Microsoft talk at CppCon 2017 are about VS Code support for C++ and ANSI C++ compliance, nothing relevant to actual Windows 10 application development. Any long time Windows developer is recognising the signs that UWP is turning into what Longhorn aspired to be, just remains to be seen how willing Microsoft is to keep pushing it. [0] https://cppcon2017.sched.com/ https://cppcon2017.sched.com/
- 9y ago