Serge E. Hallyn wrote: > Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx): >> >> Serge E. Hallyn wrote: >>> Quoting Serge E. Hallyn (serue@xxxxxxxxxx): >>>> [ 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... 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. Oren. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
