On Tue, Dec 4, 2018 at 11:28 AM Sean Christopherson <[email protected]> wrote: > > On Tue, Dec 04, 2018 at 10:58:51AM -0800, Andy Lutomirski wrote: > > On Tue, Dec 4, 2018 at 10:29 AM Sean Christopherson > > <[email protected]> wrote: > > > > > > On Tue, Dec 04, 2018 at 10:22:39AM -0800, Sean Christopherson wrote: > > > > On Tue, Dec 04, 2018 at 08:17:40AM -0800, Sean Christopherson wrote: > > > > > At one point the vDSO image was manually stripped down by vdso2c in an > > > > > attempt to minimize the size of the image mapped into userspace. Part > > > > > of that stripping process involved building a fake section table so as > > > > > not to break userspace processes that parse the section table. Memory > > > > > for the fake section table was reserved in the .rodata section so that > > > > > vdso2c could simply copy the entire PT_LOAD segment into the userspace > > > > > image after building the fake table. > > > > > > > > > > Eventually, the entire fake section table approach was dropped in > > > > > favor > > > > > of stripping the vdso "the old fashioned way", i.e. via objdump -S. > > > > > But, the reservation in .rodata for the fake table was left behind. > > > > > Remove the reserveration along with a few other related defines and > > > > > section entries. > > > > > > > > > > Removing the fake section table placeholder zaps a whopping 0x340 > > > > > bytes > > > > > from the 64-bit vDSO image, which drops the current image's size to > > > > > under 4k, i.e. reduces the effective size of the userspace vDSO > > > > > mapping > > > > > by a full page. > > > > > > > > > > Fixes: da861e18eccc ("x86, vdso: Get rid of the fake section > > > > > mechanism") > > > > > Cc: Andy Lutomirski <[email protected]> > > > > > Signed-off-by: Sean Christopherson <[email protected]> > > > > > --- > > > > > diff --git a/arch/x86/entry/vdso/vdso2c.c > > > > > b/arch/x86/entry/vdso/vdso2c.c > > > > > index 4674f58581a1..2479a454b15c 100644 > > > > > --- a/arch/x86/entry/vdso/vdso2c.c > > > > > +++ b/arch/x86/entry/vdso/vdso2c.c > > > > > @@ -98,12 +98,6 @@ struct vdso_sym required_syms[] = { > > > > > [sym_hpet_page] = {"hpet_page", true}, > > > > > [sym_pvclock_page] = {"pvclock_page", true}, > > > > > [sym_hvclock_page] = {"hvclock_page", true}, > > > > > - [sym_VDSO_FAKE_SECTION_TABLE_START] = { > > > > > - "VDSO_FAKE_SECTION_TABLE_START", false > > > > > - }, > > > > > - [sym_VDSO_FAKE_SECTION_TABLE_END] = { > > > > > - "VDSO_FAKE_SECTION_TABLE_END", false > > > > > - }, > > > > > > > > Doh, I missed removing the definitions for > > > > sym_VDSO_FAKE_SECTION_TABLE_*. > > > > > > And with sym_VDSO_FAKE_SECTION_TABLE_* gone all symbols are exported, > > > meaning required_syms can be a char* array and struct vdso_sym can be > > > removed. > > > > I bet that we'll want that field to parse out the extable entries once > > all the dust settles, though. > > Hmm, the extable stuff will be sections, a la .altinstructions, I don't > think we'll need separate symbols.
In my mind, the easiest nice implementation is to have a section that gets thrown away by objcopy --remove-section, and to have the actual table in that section be bracketed by a pair of symbols, since vdso2c already parses that. But vdso2c could certainly also just find the section direclty. Then vdso2c could expose an list of extable entries in the vdso_image, and that would be that. Does that seem reasonable? > > What if I send out a RFC for the extable stuff in parallel to this series > and to the SGX series? It'd also be nice to iterate on that code without > having to spin a full SGX series. Sounds great!
