Posted Nov 5, 2010 9:00 UTC (Fri) by mingo
In reply to: KS2010: Security
Parent article: KS2010: Security
I'd apply your academic analysis to your own exec-shield work.
Actually, FYI, a fair portion of exec-shield is upstream so your comparison fails right there.
Secondly, the few bits that are not upstream are the ones that were rejected explicitly by the VM maintainers. I have submitted them multiple times and early on. There was even a fine LWN article about it.
Look and see for yourself what happened in the most recent attempt:
Erm, have you
read the fine lkml discussion you have linked to?
I did, and it showed me a lot of acks from maintainers and some bugreports even.
In fact a fair amount of constification patches went upstream after the time you submitted similar work:
756e64a0b106: net: constify some ppp/pptp structs
2e7a091833f0: kconfig: constify file name
52dfb8ac0ef4: ceph: constify dentry_operations
54e5bc020ce1: x86, olpc: Constify an olpc_ofw() arg
f6db25a87643: squashfs: constify xattr handlers
b7bb0a12913a: gfs: constify xattr_handler
537d81ca7c53: ocfs: constify xattr_handler
365f0cb9d2d5: jffs2: constify xattr_handler
46e58764f0c5: xfs: constify xattr_handler
94d09a98cdb1: reiserfs: constify xattr_handler
11e27528076e: ext4: constify xattr_handler
d1f21049f918: ext3: constify xattr handlers
749c72efa4bd: ext2: constify xattr_handler
f01cbd3f8148: btrfs: constify xattr_handler
5bac942db3d2: SH: constify multiple DMA related objects and references to them
52cf25d0ab7f: Driver core: Constify struct sysfs_ops in struct kobj_type
9cd43611ccfb: kobject: Constify struct kset_uevent_ops
42747d712de5: [WATCHDOG] watchdog_info constify
8838d2560a8c: Staging: rt2870sta: constify RTUSBMultiWrite(), RTUSBFirmwareWrite()
a4c1a148a0c4: OMAP: DSS2: OMAPFB: Constify some function parameters
af930d646251: Input: gamecon - constify some of the setup structures
e87a344d0eef: Input: wacom - constify product features data
739674fb7feb: netfilter: xtables: constify args in compat copying functions
3b9cfc0a99f8: x86, mtrr: Constify struct mtrr_ops
5833929cc2ad: net: constify MIB name tables
45d5d805988f: iwlwifi: Constify struct iwl_ops
7d4e9d0962cd: drbd: Constify struct file_operations
f65380c07b64: resource: constify arg to resource_size() and resource_type()
28dfef8febe4: const: constify remaining pipe_buf_operations
9905a43b2d56: backlight: Constify struct backlight_ops
7707e61c7099: ctype: constify read-only _ctype string
471452104b85: const: constify remaining dev_pm_ops
3428838d8e88: page-types: constify read only arrays
1cceefd3a28e: tty: const: constify remaining tty_operations
b62d99b5028b: PCMCIA: soc_common: constify soc_pcmcia_socket ops member
a9966b580a3e: ieee802154: constify struct net_device in some operations
So this looks like good stuff, and it's being done - you got the acks - so why didn't you push your bits upstream? Have you asked akpm to include it in -mm, or have you prepared a tree yourself and sent a pull request to Linus? It's been a year since you submitted those patches - what are you waiting for?
Really, are you interested in keeping grsecurity forked? In your long reply i have not seen a single offer from you to make a serious push to merge grsecurity upstream. Instead you complain about the upstream process:
What happened after that is quite typical of upstream's handling of security; it's treated more as a nuisance, something to brush out of the way by means of token gifts of minor improvements.
The thing is, i have the exact opposite experience - security work is handled seriously and bugs are handled swiftly. The upstream kernel is aflush with security work. Patches are being welcome - check the very link you provided!
Instead of working with us you are hurling such insults at Linus:
So don't regurgitate this inapplicable 'security circus' crap from Linus and act as if it's profound; it's not.
Have you considered the theoretical possibility that Linus honestly
believes that the 'security circus' stock full of parasitic poseurs exists?
to post comments)