From mboxrd@z Thu Jan 1 00:00:00 1970 From: luto@amacapital.net (Andy Lutomirski) Date: Wed, 2 Jul 2014 09:47:08 -0700 Subject: [PATCH v7 8/9] ARM: vdso initialization, mapping, and synchronization In-Reply-To: <20140702162726.GG24879@arm.com> References: <1403493118-7597-1-git-send-email-nathan_lynch@mentor.com> <1403493118-7597-9-git-send-email-nathan_lynch@mentor.com> <53B1D8AC.7060104@mit.edu> <20140701090309.GC28164@arm.com> <53B2C178.30607@mentor.com> <20140701141541.GP28164@arm.com> <20140702144050.GD24879@arm.com> <53B430F3.9070804@mentor.com> <20140702162726.GG24879@arm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Jul 2, 2014 at 9:27 AM, Will Deacon 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