Oren Laadan orenl at cs.columbia.edu
Tue Feb 9 09:05:31 PST 2010

Serge E. Hallyn wrote:
> 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
>>>> 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...  

I'm quite certain that restart much validate at least that
the array ends with an AT_NULL. See for example fill_auxv_note()
in binmft_elf.c.


More information about the Containers mailing list