5 ms·

My understanding is that it breaks things.

JoshTriplett 10y ago
Quite a lot of things. The problem with grsecurity's claim that Linux doesn't care about security is that grsecurity doesn't appear to care about anything but security. They include changes with significant performance impact, changes that break existing userspace programs, and changes that significantly impact the maintainability of the kernel. Security that people can't or won't use doesn't actually make people more secure; usability, performance, compatibility, and other such concerns are all part of building a secure system. grsecurity has done a huge amount of innovation in kernel security, and they deserve quite a bit of credit for that. But grsecurity made a very public and vocal decision to no longer attempt to get any of that work into the upstream kernel, because they don't enjoy having to deal with the process involved in collaborative development. Instead, they went off and built a company around their out-of-tree work, and try to advocate that people use it. Meanwhile, some of the ideas that grsecurity pioneered (and a lot of other security innovations from other sources too) have started to make their way into the kernel, championed by people who are willing to do the work and participate in a collaborative development process. And the repeated response from grsecurity involves public whining, bashing of people doing the work they refuse to do, and, of course, advertisement. Whining that Linux doesn't have the security technology that they do seems rather hollow coming from people who very vocally gave up on doing the work to actually make Linux better. Out-of-tree, out-of-sight, out-of-mind.
- viraptor 10y ago
  > Quite a lot of things. I don't think that's fair to say. grsec provides many things. Some are completely transparent once implemented, (readonly variables) some have performance impact, (uderef on 32bit) some (purposely) break existing behaviour. (forbidden MSR writes prevent energy management) You can pick and choose what you want. In practice on new hardware, I don't see any big drop in desktop environment.
  - geofft 10y ago
    But it also provides bugs, as demonstrated. (As another anecdote, at least as of many years ago, grsec + OpenAFS led to frequent deadlocks that never happened with a stock kernel.) Now of course Linux has tons of bugs too as does every nontrivial patchset being merged into Linux. But grsec has a preference for risking bugs that compromise functionality / uptime but not integrity. Linux upstream has exactly the opposite preference. On a desktop machine, a slightly increased risk to system availability is totally okay. On a server machine, it's a harder call, especially if the security benefit is only a defense-in-depth measure. For most servers out there, if they're running arbitrary code as an unprivileged user, something has already gone horribly wrong.
    - viraptor 10y ago
      > But it also provides bugs, as demonstrated. I agree with it in general, but wouldn't go with the same conclusions. Upstream linux also sometimes results in random deadlocks and issues that people try to debug for weeks. That's what the rc cycle (6+ of them usually) is for. The unstabilities of grsec are kind of a side-effect of not many people looking at it. If this change happened on lkml, I'd bet someone would pick up the OpenAFS issue earlier. I don't think anyone from grsec team would be actively opposed to more users testing the releases.

Quite a lot of things. The problem with grsecurity's claim that Linux doesn't care about security is that grsecurity doesn't appear to care about anything but security. They include changes with significant performance impact, changes that break existing userspace programs, and changes that significantly impact the maintainability of the kernel. Security that people can't or won't use doesn't actually make people more secure; usability, performance, compatibility, and other such concerns are all part of building a secure system. grsecurity has done a huge amount of innovation in kernel security, and they deserve quite a bit of credit for that. But grsecurity made a very public and vocal decision to no longer attempt to get any of that work into the upstream kernel, because they don't enjoy having to deal with the process involved in collaborative development. Instead, they went off and built a company around their out-of-tree work, and try to advocate that people use it. Meanwhile, some of the ideas that grsecurity pioneered (and a lot of other security innovations from other sources too) have started to make their way into the kernel, championed by people who are willing to do the work and participate in a collaborative development process. And the repeated response from grsecurity involves public whining, bashing of people doing the work they refuse to do, and, of course, advertisement. Whining that Linux doesn't have the security technology that they do seems rather hollow coming from people who very vocally gave up on doing the work to actually make Linux better. Out-of-tree, out-of-sight, out-of-mind.

viraptor 10y ago
> Quite a lot of things. I don't think that's fair to say. grsec provides many things. Some are completely transparent once implemented, (readonly variables) some have performance impact, (uderef on 32bit) some (purposely) break existing behaviour. (forbidden MSR writes prevent energy management) You can pick and choose what you want. In practice on new hardware, I don't see any big drop in desktop environment.
- geofft 10y ago
  But it also provides bugs, as demonstrated. (As another anecdote, at least as of many years ago, grsec + OpenAFS led to frequent deadlocks that never happened with a stock kernel.) Now of course Linux has tons of bugs too as does every nontrivial patchset being merged into Linux. But grsec has a preference for risking bugs that compromise functionality / uptime but not integrity. Linux upstream has exactly the opposite preference. On a desktop machine, a slightly increased risk to system availability is totally okay. On a server machine, it's a harder call, especially if the security benefit is only a defense-in-depth measure. For most servers out there, if they're running arbitrary code as an unprivileged user, something has already gone horribly wrong.
  - viraptor 10y ago
    > But it also provides bugs, as demonstrated. I agree with it in general, but wouldn't go with the same conclusions. Upstream linux also sometimes results in random deadlocks and issues that people try to debug for weeks. That's what the rc cycle (6+ of them usually) is for. The unstabilities of grsec are kind of a side-effect of not many people looking at it. If this change happened on lkml, I'd bet someone would pick up the OpenAFS issue earlier. I don't think anyone from grsec team would be actively opposed to more users testing the releases.