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... -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
