Re: [kernel-hardening] It looks like there will be no more public versions of PaX and Grsec.

[Daniel Micay <danielmicay@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

> Maintainers integrate code one patch series at a
> time. That is not a constraint you can work around,
> because code does need to be reviewed.

By not requiring fixes for issues like undefined function pointer usage
or other undefined behavior to be split up in hundreds of patches to go
through many different maintainers / many different trees. The same goes
for things like basic constification  (i.e. const and __ro_after_init)
that are clear cut and don't involve a performance compromise (so an
equivalent to pax_{open_close}_kernel would be different).

It's extremely unrealistic to get type-based Control Flow Integrity like
RAP for the mainline kernel if the fixes cannot be queued up in a single
tree. It also deters people from working on any of these small,
incremental improvements since they need to split it all up and try to
deal with dozens of maintainers, with most of the patches being lost.
See what happened to past attempts at this stuff.

Of course it needs to be reviewed and hopefully tested, but for fixing
clear cases of undefined behavior (i.e. those caught by UBSan or other
sanitizers and not covered by flags like -fno-strict-overflow -fno-
strict-aliasing) or uncontroversial things like missing const (without
other code changes beyond making pointers const), it should be possible
to land fixes via one tree. It isn't an issue that's specific to
security patches.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 866 bytes --]