4 ms·

Not quite. The end goal of the GNU project on the macro level is to replace all proprietary operating systems (not just proprietary Unixes) with GNU. But then a

Not quite. The end goal of the GNU project on the macro level is to replace all proprietary operating systems (not just proprietary Unixes) with GNU. But then an explicit goal of the Hurd specifically was freedom from tyrannical sysadmin policy, which necessarily included freedom to host one's own private namespace in a multi-user system that doesn't affect the global namespace. Currently, the goal is indeed exploration. RMS and GNU have given up on it and morale is low. Can you blame them? In fact, RMS' decision to go with Unix was a pragmatic one. He himself was always more a fan of ITS and Lisp Machines (see his October 1986 speech at KTH), but rightfully sensed no one would end up using such a solution, and thus decided a clone of Unix with non-breaking semantic improvements where possible and a Lisp-y userspace was the best way to bridge adoption with wanting to push forward. Hurd satisfied the first, the second unfortunately stagnated as Guile never broke the chasm until very recently now with GuixSD. QNX was proprietary and didn't have its architectural unveiling until work on Hurd was started. It again did not have the translator concept, but like MINIX 3 had static servers. KeyKOS' main selling point was the single store and the orthogonal persistence, which nominally could be done on Hurd e.g. by integrating Mach VMM policy into a libdiskfs. It was not a priority then. L4 was too spartan for the experiments on object-capability systems that the Hurd devs embarked: https://www.cs.cmu.edu/~412-s05/projects/HurdL4/hurd-on-l4.pdf https://www.cs.cmu.edu/~412-s05/projects/HurdL4/hurd-on-l4.p... It's true that security was never a primary orientation of the Hurd, but its security is still better than monolithic Unixes. And do keep in mind QNX and MINIX 3 are not nominally security-oriented, either. It's the communication boundary structure (and in Hurd's case, port rights and auth server) that intrinsically create superior cases. Walfield and Brinkmann's 2007 critique was done from the perspective of developers themselves. It wasn't a general criticism of the Hurd, but one of specific problems related to resource accounting that other u-kernel and most monolithic kernel designs suffer from. Relative to the state of the industry, it is still a leap forward. Relative to the state of the art, it is not, but then so do QNX and MINIX 3 make sacrifices. Implementing the POSIX API has nothing to do with the Hurd's problems. And, indeed, Hurd does break the POSIX model in several aspects (e.g. allowing multiple uids per process). But then we must disqualify QNX and MINIX 3 by this token, too. The fundamental issues with the Hurd then have little to do with the 2007 critique. More pressing is its incompleteness, which hopefully rump integration will finally break its samsara. If all else fails, using rump drivers on a heavily stripped Linux with Mach module emulation to create a true hybrid kernel, coupled with functional package management and system state management via Guix with added on orthogonal persistence and network transparency could be another future direction for the Hurd I might end up exploring. Perhaps tripling both as a multi-user OS, a unikernel and a container OS via subhurds. The Mach improvements have mostly been surface, but again, I would not see it as a huge bottleneck (only an inelegance) and in the hybrid case it becomes irrelevant beyond as a programming API, which it isn't that bad of one.

nickpsecurity 11y ago
"Currently, the goal is indeed exploration. RMS and GNU have given up on it and morale is low. Can you blame them?" I said it was a failure and they should give up on it outside research. So, no, I support their decision. ;) " But then an explicit goal of the Hurd specifically was freedom from tyrannical sysadmin policy, which necessarily included freedom to host one's own private namespace in a multi-user system that doesn't affect the global namespace." That makes sense, esp given the time it was made. Clouds, etc are still experimenting with models on that due to demand. "QNX was proprietary and didn't have its architectural unveiling until work on Hurd was started." And then they had the details they needed for the next 10-20 years. So, my memes about applying proven methods or not learning from the past may apply here. "KeyKOS' main selling point was the single store and the orthogonal persistence," KeyKOS's main benefits they touted were security/reliability w/ fine-grained POLA, high performance, and flexibility. One could even extend and share things in such a way that untrusted code couldn't swamp CPU or memory. KeyKOS did in many use cases what Mach projects failed to do thanks to its design decisions and complexity. That's despite experienced, brilliant kernel programmers working full-time on it. KeyKOS also had the two benefits you mention. So, building a KeyKOS-style kernel had huge benefits over a Mach kernel. That's why Shapiro cloned it with EROS. I expect porting such attributes to this Mach project will also be (or were) hard. "It's the communication boundary structure (and in Hurd's case, port rights and auth server) that intrinsically create superior cases." It's isolation, resource management, and communication. They're necessary for reliability and security as both involve components behaving badly. Also, for reliability, add in self-healing capabilities with at least monitoring and restarting of drivers. The last is a feature but the first three are baked into underlying architecture. The paper noted it lacked one for sure. Further investigation might find problems with the others. "Walfield and Brinkmann's 2007 critique was done from the perspective of developers themselves. It wasn't a general criticism of the Hurd, but one of specific problems related to resource accounting that other u-kernel and most monolithic kernel designs suffer from." "Implementing the POSIX API has nothing to do with the Hurd's problems." We might be reading different papers as there were several. Here's the one I'm referring to: http://walfield.org/papers/200707-walfield-critique-of-the-GNU-Hurd.pdf http://walfield.org/papers/200707-walfield-critique-of-the-G... It's entirely about Hurd except when it's critiquing Mach. It first describes the architecture and mechanisms. Then, it goes with the critiques. I'm ignoring those that show up anywhere and just require a tweak. The biggest, for reliability and security, is that it's trust model is discretionary on app/process level: program inherits user's privileges with no further limits and any reductions are at program's discretion. Capability, MAC models, and even Windows Vista techniques counter threats in that space that Hurd wouldn't challenge. The next come from UNIX/POSIX compatibility & integration style. The filesystem shows how vanilla UNIX apps might break or require significant debugging due to UNIX assumptions that don't apply. The server allocation problem with open is another but might be fixed if INTEGRITY RTOS's brilliant defence is used: calling process donates its own CPU/memory for external functions. Would that break POSIX/UNIX behavior? Idk. Author follows up, though, by pointing out most things in Hurd have lots of ambient authority and would take modifications. These are usually due to UNIX compatibility. Note that ambient authority, along with its resulting downtime and hacks, we're one of reasons UNIX was ditched for capability architectures by projects that built them. They then look at Mach. One problem, optimization w/ predictable patterns, is indeed a general problem for microkernels this flexible and dynamic. This flexibility also makes for unpredictable delays. That's why most microkernels are static and/or optimized on critical parts. Mach also lacked secure management of global resources in such a dynamic system. Authors mention KeyKOS/EROS which didn't have that problem. There's others but those were best at this IIRC. So, the paper and it's problems were mostly specific to Hurd and its usage of Mach. In each case, it's an open problem about how to fix that in Hurd while each are a done deal in one or more competing technologies. Mach and UNIX compatibility either prevent the fix or make it quite difficult. So, these should count as Hurd/Mach problems caused by their specific design(s). "Relative to the state of the art, it is not, but then so do QNX and MINIX 3 make sacrifices." They do. Not calling them perfection, either. However, they intentionally make choices that make their job easier at kernel, architecture, and API levels. Good engineering involves making right tradeoffs rather than setting oneself up to fail. That's my problem with Hurd if judging against its goals but in exploration mode they just need to make progress. Or make changes. Note: I do disqualify the two from the secure attribute due to their compatibilities and QNX's UNIX code got it smashed first time an online presence was publicized. Reliability, performance, resource management, and UNIX/POSIX integration? Among best in class. "The fundamental issues with the Hurd then have little to do with the 2007 critique. More pressing is its incompleteness" That's another issue on top of the fundamentals I referenced earlier. We're probably going to learn about some more side effects of them when they add Rump kernels assuming monolithic UNIX to the mix. It's still a good move on their part, though, and would bring lineage full circle. "f all else fails, using rump drivers on a heavily stripped Linux with Mach module emulation to create a true hybrid kernel, coupled with functional package management and system state management via Guix with added on orthogonal persistence and network transparency could be another future direction for the Hurd I might end up exploring." Now, that sounds like the hacked together, against-all-odds, balls-to-the-wall solution I like to see! Although above issues will affect multi-user part: specific examples were already cited. Might be fine if they're benign users. So, build the monstrosity and make it work! :) "I would not see it as a huge bottleneck (only an inelegance) and in the hybrid case it becomes irrelevant beyond as a programming API, which it isn't that bad of one." In the past, it was a bottleneck but people thought the API was fine. So, it will be interesting to see what happens on containerized, multi-tenant, IPC-heavy workloads. On it vs alternative schemes.

nickpsecurity 11y ago

"Currently, the goal is indeed exploration. RMS and GNU have given up on it and morale is low. Can you blame them?" I said it was a failure and they should give up on it outside research. So, no, I support their decision. ;) " But then an explicit goal of the Hurd specifically was freedom from tyrannical sysadmin policy, which necessarily included freedom to host one's own private namespace in a multi-user system that doesn't affect the global namespace." That makes sense, esp given the time it was made. Clouds, etc are still experimenting with models on that due to demand. "QNX was proprietary and didn't have its architectural unveiling until work on Hurd was started." And then they had the details they needed for the next 10-20 years. So, my memes about applying proven methods or not learning from the past may apply here. "KeyKOS' main selling point was the single store and the orthogonal persistence," KeyKOS's main benefits they touted were security/reliability w/ fine-grained POLA, high performance, and flexibility. One could even extend and share things in such a way that untrusted code couldn't swamp CPU or memory. KeyKOS did in many use cases what Mach projects failed to do thanks to its design decisions and complexity. That's despite experienced, brilliant kernel programmers working full-time on it. KeyKOS also had the two benefits you mention. So, building a KeyKOS-style kernel had huge benefits over a Mach kernel. That's why Shapiro cloned it with EROS. I expect porting such attributes to this Mach project will also be (or were) hard. "It's the communication boundary structure (and in Hurd's case, port rights and auth server) that intrinsically create superior cases." It's isolation, resource management, and communication. They're necessary for reliability and security as both involve components behaving badly. Also, for reliability, add in self-healing capabilities with at least monitoring and restarting of drivers. The last is a feature but the first three are baked into underlying architecture. The paper noted it lacked one for sure. Further investigation might find problems with the others. "Walfield and Brinkmann's 2007 critique was done from the perspective of developers themselves. It wasn't a general criticism of the Hurd, but one of specific problems related to resource accounting that other u-kernel and most monolithic kernel designs suffer from." "Implementing the POSIX API has nothing to do with the Hurd's problems." We might be reading different papers as there were several. Here's the one I'm referring to: http://walfield.org/papers/200707-walfield-critique-of-the-GNU-Hurd.pdf http://walfield.org/papers/200707-walfield-critique-of-the-G... It's entirely about Hurd except when it's critiquing Mach. It first describes the architecture and mechanisms. Then, it goes with the critiques. I'm ignoring those that show up anywhere and just require a tweak. The biggest, for reliability and security, is that it's trust model is discretionary on app/process level: program inherits user's privileges with no further limits and any reductions are at program's discretion. Capability, MAC models, and even Windows Vista techniques counter threats in that space that Hurd wouldn't challenge. The next come from UNIX/POSIX compatibility & integration style. The filesystem shows how vanilla UNIX apps might break or require significant debugging due to UNIX assumptions that don't apply. The server allocation problem with open is another but might be fixed if INTEGRITY RTOS's brilliant defence is used: calling process donates its own CPU/memory for external functions. Would that break POSIX/UNIX behavior? Idk. Author follows up, though, by pointing out most things in Hurd have lots of ambient authority and would take modifications. These are usually due to UNIX compatibility. Note that ambient authority, along with its resulting downtime and hacks, we're one of reasons UNIX was ditched for capability architectures by projects that built them. They then look at Mach. One problem, optimization w/ predictable patterns, is indeed a general problem for microkernels this flexible and dynamic. This flexibility also makes for unpredictable delays. That's why most microkernels are static and/or optimized on critical parts. Mach also lacked secure management of global resources in such a dynamic system. Authors mention KeyKOS/EROS which didn't have that problem. There's others but those were best at this IIRC. So, the paper and it's problems were mostly specific to Hurd and its usage of Mach. In each case, it's an open problem about how to fix that in Hurd while each are a done deal in one or more competing technologies. Mach and UNIX compatibility either prevent the fix or make it quite difficult. So, these should count as Hurd/Mach problems caused by their specific design(s). "Relative to the state of the art, it is not, but then so do QNX and MINIX 3 make sacrifices." They do. Not calling them perfection, either. However, they intentionally make choices that make their job easier at kernel, architecture, and API levels. Good engineering involves making right tradeoffs rather than setting oneself up to fail. That's my problem with Hurd if judging against its goals but in exploration mode they just need to make progress. Or make changes. Note: I do disqualify the two from the secure attribute due to their compatibilities and QNX's UNIX code got it smashed first time an online presence was publicized. Reliability, performance, resource management, and UNIX/POSIX integration? Among best in class. "The fundamental issues with the Hurd then have little to do with the 2007 critique. More pressing is its incompleteness" That's another issue on top of the fundamentals I referenced earlier. We're probably going to learn about some more side effects of them when they add Rump kernels assuming monolithic UNIX to the mix. It's still a good move on their part, though, and would bring lineage full circle. "f all else fails, using rump drivers on a heavily stripped Linux with Mach module emulation to create a true hybrid kernel, coupled with functional package management and system state management via Guix with added on orthogonal persistence and network transparency could be another future direction for the Hurd I might end up exploring." Now, that sounds like the hacked together, against-all-odds, balls-to-the-wall solution I like to see! Although above issues will affect multi-user part: specific examples were already cited. Might be fine if they're benign users. So, build the monstrosity and make it work! :) "I would not see it as a huge bottleneck (only an inelegance) and in the hybrid case it becomes irrelevant beyond as a programming API, which it isn't that bad of one." In the past, it was a bottleneck but people thought the API was fine. So, it will be interesting to see what happens on containerized, multi-tenant, IPC-heavy workloads. On it vs alternative schemes.