public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/59850] Support sparse-style pointer address spaces (type attributes) Date: Fri, 27 Jun 2014 11:24:00 -0000 [thread overview] Message-ID: <bug-59850-4-h5k8ZU2T6p@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-59850-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 Manuel López-Ibáñez <manu at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |manu at gcc dot gnu.org --- Comment #22 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- (In reply to Tom Tromey from comment #21) > In the "pro" column, as a plugin it could be maintained elsewhere. > That might be interesting. > > In the "con" column, it's a pain if multiple projects want to > use these checks. Then it's just one more thing to fetch. * We could add plugins to the GCC repository for things that are considered generally useful but we don't want to bloat standard gcc. I am sure the FSF will be happier if plugins live in the GCC repository and they are assigned to them than if not. * A plugin living in the GCC repository will likely have a lower barrier for acceptance than code added to GCC. >From gcc-bugs-return-455130-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 27 11:29:22 2014 Return-Path: <gcc-bugs-return-455130-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 12532 invoked by alias); 27 Jun 2014 11:29:22 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 12491 invoked by uid 48); 27 Jun 2014 11:29:19 -0000 From: "pageexec at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/59850] Support sparse-style pointer address spaces (type attributes) Date: Fri, 27 Jun 2014 11:29:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: pageexec at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: <bug-59850-4-GNUT3mju7s@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-59850-4@http.gcc.gnu.org/bugzilla/> References: <bug-59850-4@http.gcc.gnu.org/bugzilla/> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-06/txt/msg02212.txt.bz2 Content-length: 2132 https://gcc.gnu.org/bugzilla/show_bug.cgi?idY850 --- 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.
next prev parent reply other threads:[~2014-06-27 11:24 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-01-17 5:05 [Bug c/59850] New: " hpa at zytor dot com 2014-01-17 8:03 ` [Bug c/59850] " josh at joshtriplett dot org 2014-02-01 5:26 ` tromey at gcc dot gnu.org 2014-02-01 18:39 ` josh at joshtriplett dot org 2014-02-03 8:20 ` tromey at gcc dot gnu.org 2014-02-05 14:45 ` tromey at gcc dot gnu.org 2014-02-05 15:55 ` josh at joshtriplett dot org 2014-02-05 16:50 ` hpa at zytor dot com 2014-02-05 17:51 ` tromey at gcc dot gnu.org 2014-02-05 18:11 ` tromey at gcc dot gnu.org 2014-02-05 20:06 ` josh at joshtriplett dot org 2014-02-05 20:07 ` josh at joshtriplett dot org 2014-02-05 20:08 ` josh at joshtriplett dot org 2014-02-05 20:12 ` tromey at gcc dot gnu.org 2014-02-06 0:08 ` josh at joshtriplett dot org 2014-02-06 4:44 ` hpa at zytor dot com 2014-02-21 3:09 ` tromey at gcc dot gnu.org 2014-02-21 3:37 ` tromey at gcc dot gnu.org 2014-02-21 4:19 ` josh at joshtriplett dot org 2014-02-21 14:58 ` tromey at gcc dot gnu.org 2014-06-27 4:33 ` tromey at gcc dot gnu.org 2014-06-27 11:24 ` manu at gcc dot gnu.org [this message] 2014-06-27 14:24 ` manu at gcc dot gnu.org 2014-06-29 2:26 ` tromey at gcc dot gnu.org 2014-07-03 20:36 ` tromey at gcc dot gnu.org 2014-07-03 20:48 ` josh at joshtriplett dot org 2014-07-03 21:03 ` tromey at gcc dot gnu.org 2014-07-09 14:10 ` tromey at gcc dot gnu.org 2014-07-09 14:31 ` tromey at gcc dot gnu.org 2014-07-30 23:24 ` tromey at gcc dot gnu.org 2014-08-08 16:10 ` tromey at gcc dot gnu.org 2022-09-26 22:47 ` dmalcolm at gcc dot gnu.org 2022-10-03 15:02 ` mpolacek at gcc dot gnu.org 2022-10-03 16:16 ` hpa at zytor dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-59850-4-h5k8ZU2T6p@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).