Re: Proposal: DT_OPENBSD_RANDOMDATA and DT_OPENBSD_RANDOMDATASZ

27 views
Skip to first unread message

Matthew Dempsky

unread,
Aug 3, 2012, 9:03:03 PM8/3/12
to gener...@googlegroups.com
Just thought I'd ping on this again because I'm about to begin earnest
implementation of this functionality for OpenBSD.

Thanks!


On Wed, Jun 13, 2012 at 11:01:49PM -0700, Matthew Dempsky wrote:
> (I applied for membership to this mailing list a few days ago, but haven't been approved yet. If a moderator reads this message, I'd appreciate getting approved. In the mean time, please CC me on replies.)
>
>
> I'd like to propose the following two dynamic section tags:
>
> DT_OPENBSD_RANDOMDATA
>
> This element holds the address of the random data section. If this element is present, the dynamic structure must also have a DT_OPENBSD_RANDOMDATASZ element.
>
> DT_OPENBSD_RANDOMDATASZ
>
> This element holds the total size, in bytes, of the DT_OPENBSD_RANDOMDATA random data section.
>
> The dynamic linker should fill the random data section with random bytes before relocation processing.
>
> I've tentatively chosen the following random OS-specific tag values, but could be convinced to use other values:
>
> #define DT_OPENBSD_RANDOMDATA 0x65a3dbe6
> #define DT_OPENBSD_RANDOMDATASZ 0x65a3dbe7
>
>
> Rationale: In OpenBSD, we use GCC's -fstack-protector feature, which normally uses a single global __stack_chk_guard value that gets initialized by a constructor function. However, this approach has two disadvantages:
>
> 1. Using a global value requires an indirection via the GOT, whereas a separate (hidden) value within each shared object works just as well (because it's only necessary that the same value is accessed by a given function's prologue and epilogue) and is faster by bypassing the GOT.
>
> 2. Initializing the guard value in a constructor function requires leaving it in writable memory, whereas it would be preferable to mark it read-only after initialization so exploits can't simply overwrite the expected value. The constructor function could mprotect() the random data section itself, but it seems preferable to instead include the random data section within the PT_GNU_RELRO segment so it's naturally marked read-only by the dynamic linker.
>
> My plan is to put the (now hidden) __stack_chk_guard value in an .openbsd.randomdata section and modify the link editor to set the DT_OPENBSD_RANDOMDATA and DT_OPENBSD_RANDOMDATASZ tags appropriately. (Theoretically, the .openbsd.randomdata section could be SHT_NOBITS, but I don't expect the sections to be large enough in practice to matter.)
>
>
> I'm open to suggestions of improvements on the above scheme. I've successfully implemented this scheme on OpenBSD with minor patches to GCC and GNU ld, but it's still a work-in-progress.
>
> --
> You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/generic-abi/-/vl559qjZ4_AJ.
> To post to this group, send email to gener...@googlegroups.com.
> To unsubscribe from this group, send email to generic-abi...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/generic-abi?hl=en.
>
Reply all
Reply to author
Forward
0 new messages