On Thu, 2011-06-23 at 09:54 +0100, Richard W.M. Jones wrote: > On Wed, Jun 22, 2011 at 03:57:58PM -0400, Adam Jackson wrote: > > * #563 suggested policy: all daemons must set RELRO and PIE flags > > (ajax, 17:53:41) > > * LINK: https://fedorahosted.org/fpc/ticket/93 (nirik, 17:54:34) > > * ACTION: nirik to come up with guidelines for next week (ajax, > > 18:07:03) > > * ACTION: ajax to add relro to redhat-rpm-config (ajax, 18:07:16) > > The discussion in the ticket seems like it would only apply to > programs written in C/C++, but it doesn't say this. > > Since other languages are usually much safer than C/C++ and the aim of > this is security, it seems like we should explicitly exclude other > languages from the requirement. It's a little more complicated than that. First, we should make clear that this is a feature of compiled languages emitted as ELF binaries. For example, Perl and Python (at least as we ship them) would not count; nor would Mono, which emits PECOFF not ELF. [1] But within that scope, any language _could_ implement these features; the question is how useful they'd be. For languages like Haskell, where you have to try quite hard to get a pointer, it's not directly relevant. For languages like Go, where pointers are so easy they're in the syntax, it's about the same as for C. But in either case, you may be and usually are linking against libraries written in less-safe languages (xmonad links against libgmp, for example), and these features would protect you from wild pointer or buffer overflow bugs in libraries _below_ you. To make this more explicit: suppose some unmanaged code below you manages to overwrite a PLT entry. Haskell symbols are bound in the PLT just like C. Now your method calls don't execute what you expect, and all your compile-time correctness is thrown out the window. Your language is only as safe as the runtime is correct, and practically speaking, all runtimes are derived classes of the C runtime. I played briefly with jamming relro into ghc command line options, and you can kind of do it ("-optl-z -optlrelro -optlc-Wl,z,relro" in ghc-options), but it doesn't change much on its own. You do end up with an executable with a GNU_RELRO segment, but there's nothing in it besides linker details (though admittedly, that's not nothing). In particular you don't end up with a .data.rel.ro section, which implies that the generated C code isn't bothering to mark things as const that it expects will need relocations. [1] - It's probably possible to implement similar features for PECOFF, but I don't believe it's currently done, or that anyone's working on it. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
