[PATCH v7 8/9] ARM: vdso initialization, mapping, and synchronization

[Andy Lutomirski]

On Wed, Jul 2, 2014 at 9:27 AM, Will Deacon <will.deacon at arm.com> wrote:
> On Wed, Jul 02, 2014 at 05:18:59PM +0100, Nathan Lynch wrote:
>> On 07/02/2014 10:54 AM, Andy Lutomirski wrote:
>> > Caveat 2: (major) I'm kind of surprised that this, or the current
>> > code, works reliably.  You're doing something that I tried briefly for
>> > x86_64:
>> >
>> >         _end = .;
>> >         PROVIDE(end = .);
>> >
>> >         . = ALIGN(PAGE_SIZE);
>> >         PROVIDE(_vdso_data = .);
>> >
>> > This sounds great, except that you're assuming that vdso_end -
>> > vdso_start == ALIGN(_end, PAGE_SIZE) - (vdso base address).
>> >
>> > If you *fully* strip the vdso (eu-strip --strip-sections), then this
>> > is true: eu-strip --strip-sections outputs just the PT_LOAD piece of
>> > the vdso.  But any binutils-generated incompletely stripped ELF image
>> > contains a section table and possible non-allocatable sections at the
>> > end.  If these exceed the amount of unused space in the last PT_LOAD
>> > page, then they'll spill into the next page, and _vdso_data in the
>> > vdso will no longer match the address at which vdso.c loads it.  Boom!
>> >
>> > I bet you're getting away with this because the whole arm64 vdso seems
>> > to be written in assembly, so it seems extremely unlikely to exceed
>> > one page minus a few hundred bytes.  But if you start adding
>> > complexity, you might get unlucky.
>>
>> This is why I switched (in v5) the proposed 32-bit ARM VDSO to place the
>> data page before the code -- adding -frecord-gcc-switches to the
>> compiler flags was enough to break it.
>>
>> I meant to call Will's attention to it at the time for arm64's sake, but
>> I guess it slipped my mind... sorry.
>
> Hmm, so I could definitely look at doing the same thing, but I don't know if
> we actually need to for arm64. As Andy points out, we're written entirely in
> assembly and we objcopy -S to create the vdso.so. I've dumped the headers
> below and everything appears to be PT_LOAD.

Your dump doesn't show the location of the section and section string
tables themselves.  Try:

eu-readelf -l -h -S whatever.so

--Andy