[RFC PATCH] Make AT_VECTOR_SIZE_ARCH 2 for x86-32

[Serge E. Hallyn]

Quoting Oren Laadan (orenl at cs.columbia.edu):
> 
> 
> Serge E. Hallyn wrote:
> >Quoting Serge E. Hallyn (serue at us.ibm.com):
> >>[ RFC:  Am I on crack? ]
> >>
> >>Both x86-32 and x86-64 with 32-bit compat use ARCH_DLINFO_IA32,
> >>which defines two saved_auxv entries.  But system.h only defines
> >>AT_VECTOR_SIZE_ARCH as 2 for CONFIG_IA32_EMULATION, not for
> >>CONFIG_X86_32.  Fix that.
> >
> >To be clear, this patch if right would be for pushing upstream
> >immediately.  It still leaves open the question of what we want
> >to do about saved_auxv.  We currently just write it out as a
> >buffer, but since it is actually an array of longs, and therefore
> >differently sized on x86-32 and x86-64-compat, we would need to
> >write them out entry-by-entry (and validate no overflows for
> >TIF_IA32 tasks).  Does that seem warranted?
> 
> Yes: iterate over entries and copy them.
> 
> From a brief look at the code, I don't think the contents of the
> saved_auxv is used anywhere inside the kernel (it's exported via
> /proc), except for the reliance on a trailing AT_NULL record
> which is easy to test for.
> 
> Would it be wrong or insecure to export whatever garbage the user
> may have put in that array (assuming it is null terminated) ?

I don't know which tools use the /proc/$$/auxv output, but I don't
see why it would be unsafe so long as we (as I do) only copy
AT_VECTOR_SIZE unsigned longs.

I suppose we could try and be more knowledgable about the internals
and restore them to values that make sense, using code we'd share
with fs/binfmt_elf.c...  

-serge