https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
--- Comment #23 from PaX Team <pageexec at gmail dot com> --- some data points based on my experience with the 'checker' gcc plugin in PaX: 1. the C address space infrastructure available since gcc 4.6 can be sort of coerced into implementing the __user/__kernel/etc address spaces and it works reasonably well (i'd say even better than sparse as it produces no false positives in my experience and caught real bugs such as CVE-2014-0038). 2. __force itself presents a problem as its semantics isn't well defined and only sparse knows how to model it. in gcc it cannot be an attribute as attributes apply to the outermost variable/etc, e.g., you can't use them on a pointee in a pointer context. what i did instead is that i introduced new address spaces (__force_user/__force_kernel so far, __rcu/__iomem/etc will need more of these) that replace the '__force something' combination with __force_something (yes, this needs patching on the kernel side, and i haven't done a thorough job of it but it works on my smaller configs at least). this way the hijacked targetm.addr_space.legitimate_address_p callback can be taught to allow/disallow the intended conversions. 3. designated_init is a tricky problem because by the time a plugin can examine variable initializers, gcc will have lost the information. however with a trick such unwanted initializers can instead be turned into a compile error (that existing gcc infrastructure can detect). you can find it in spender's randomize_layout plugin that's distributed in grsecurity. 4. as for maintaining a plugin for kernel and/or other use: inside the kernel it'll need some kbuild infrastructure (there's one in PaX already, though it's probably not 100% complete) and it's worked fine for our users for the past 3+ years now. for more general use distros can package up plugins as they'd do with any library (as plugins are really nothing more than that). note also that keeping a plugin in the kernel tree will raise license problems (gplv2 vs gplv3) but i guess the kernel list is the better forum for discussing that.
