From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A80F448165C for ; Thu, 13 Aug 2026 14:28:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786631312; cv=none; b=l+fzTzt3jL0gnVkR0oLUBjOic+IAzZDfIH518jLBygmRY15o+PfUL//Lg3hdIT3BbtKDDJOxB2yrjMl+9UAJhbeg70qq4EHq/+nVFpvYef/tmiQh6lhCloVQyuicjeevGpDLh+9vBf1gWj4Ocl06N+9nO/9A9Ix8X82NHORWzpg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786631312; c=relaxed/simple; bh=GByYkkpcV2ZdO7hPyRU6d/F72ypJhPvaKsTmYi7cVps=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=daNo+zXBqY7yKBRLTlBmkR/rfQIv5p/a+OJYmTp3Y2Ifm7JssT5r1hjFET+dSfekYVZXbiOypSpaUeGOzVM+kTNGgR7iUWpFvUAworjpeFpYMl32k4BQLqWQNpwkC+kcOnVp4LTbq6j6icMFE3LXy3VK6XbPz5bDBTslagoRGB4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=ddhTcALJ; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=i/b/f4Hz; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ddhTcALJ"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="i/b/f4Hz" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786631309; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sY8qFrl386G/mvZ0te0PNK+IZtHDWNFEq6zt8D8f1IU=; b=ddhTcALJzTM732edWV9lrk8rG6H9+ldVoA8ATxQXt8pjDusJZRGUa6X1R/NHLuUBRRPOI7 dPCe1qp6SC3UzPQL4G3cgqEUcNvRDtEUQDj3RIruBnXYLAaIcphK3xE2uFHMn1KemrBReX nFr30gcIFVDuVry9U6BNFD6kGwBmYjM= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-258-KfOhVk6NOr2Giz8FDDKDCw-1; Thu, 13 Aug 2026 10:28:27 -0400 X-MC-Unique: KfOhVk6NOr2Giz8FDDKDCw-1 X-Mimecast-MFC-AGG-ID: KfOhVk6NOr2Giz8FDDKDCw_1786631305 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-47f2de3ba47so1494270f8f.1 for ; Thu, 13 Aug 2026 07:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1786631305; x=1787236105; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=sY8qFrl386G/mvZ0te0PNK+IZtHDWNFEq6zt8D8f1IU=; b=i/b/f4HzmYp/KN0m21CSuoX7NDXoKwomC9cldpXE4eUVBRNR52g+g9Z3zwWB2NPEwh G/OCCiu/JXYrkkQnIWyF+q7AUx75HMj0Yxh77+nNCMV+pZQHeEEeYyTAaYOuixzYaPsw 3GsWc87DD6ZBaQdlVa7bQRi6UBk6WaBw1B67nLcxVUVeIMiCMQb3nhV9AkZui0MyMJsM ifRwGGCuGFJF50F25Sca4Og4LV8sgOW45yo4pxJAPR332yOOnD3RXePhCHzMCQJ1mVs9 CnG1ymRqUPSx1GclhZGkD1FyYS/kZwkNEGCrQmtyrRU+OXolDdIefP1J5CK5EmipuDLT jEsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786631305; x=1787236105; h=content-transfer-encoding:content-type:mime-version:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=sY8qFrl386G/mvZ0te0PNK+IZtHDWNFEq6zt8D8f1IU=; b=j5+U/9OGiZq2DIUVEUAULxBOce1FAHOAno2IspMEnz/eFRRJ3+Ac5Gu3K6NAyI2jaa /qRU6qJI6/Me2GWm0Vx0ZeMcLzIFToEFKIbpWedfu8dud3GQLvxqGxPQwrfgYrNaHgDg rvlAQRj3D5wHT06c9oSTUbDUGnY/cIomAytr2cWu2bJFlpsULwsQKwiekL7xEWRjBW95 xa1YmvaQA1rDJvPQjhUzn66JU2nOzbUc7RaWmRjUJCVtIpDOym6kypLYyhUDKkK1O2IR 7tZMFdyZIhiOenAfNHXi3FPIE3boS5KM3hO6ImvFBfy9Hq8KP7WAkSC0DD5m2AfqtF62 CxZw== X-Forwarded-Encrypted: i=1; AHgh+Rp57sHf+XyX6xoMvi7sQp89QPUyyTXvd0E0fn/VxtqFYskLHTIoQ3xZ1U0zSiaEo//+sb7WfCJMLsNyZxY=@vger.kernel.org X-Gm-Message-State: AOJu0Yyif6KaF3TL+NSq9Dbert3ZQbvdGgRWHOAeMlXq+6Aw71/vb7kw dRC1T5v3y/XoZPqOYWeniiIaunKKgyH+mf2GPARkNzb92FNnIf9fTPQ3MHglNLl0VKr6JQWMTFO HFlatl70OgpCOvBfvCS6m0GCirwwgHc8dEZ99XXVMDPc6pMyH++mv8VCX4Mbq1mqV7AkyB+OynA == X-Gm-Gg: AR+sD13u6NgvFtK25qh0TbPCOtDyWxY712KO+3J2fL9ETOfM0z/KSXST4WzaXmYMM7m vK92cfyQTU0z3Mbk/hP4UFUmakoHY2TJCF4iod69QD50yolc7M+RFkatJimvxA9TePr9Wt4P18t FIRa0IQEsS+0PEM3gQSmAFmTn2YhZmdpB2aihyyB+dOeL7Uq7tGgspo0I45QFfCIXgpfTXQFYTM cooYwVZX/QeZRKxYxHif+yl6VtCCRyoV3PWLEzp8Ei++wE0lFvDTiLD48AwJFovmL9OjwB3nEmO ch3kWO7AYqBE323ciiWpreYVFUfVaOX/opoggLMCZZpmv1AIZG1FK3BQx96JqpwsIEJPOxU8FQM zyai6a6tPaBhnYqKF0IA= X-Received: by 2002:a05:6000:2304:b0:47f:81c4:36a5 with SMTP id ffacd0b85a97d-48159fe3877mr8570327f8f.15.1786631305209; Thu, 13 Aug 2026 07:28:25 -0700 (PDT) X-Received: by 2002:a05:6000:2304:b0:47f:81c4:36a5 with SMTP id ffacd0b85a97d-48159fe3877mr8570207f8f.15.1786631304465; Thu, 13 Aug 2026 07:28:24 -0700 (PDT) Received: from localhost (67.72.115.87.dyn.plus.net. [87.115.72.67]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4815a5612b8sm5804219f8f.1.2026.08.13.07.28.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Aug 2026 07:28:23 -0700 (PDT) From: Andrew Burgess To: Alexandra =?utf-8?B?SMOhamtvdsOh?= , linux-kernel@vger.kernel.org Cc: ahajkova@redhat.com Subject: Re: [PATCH RESEND] elf: add AT_ARGV and AT_ENVV auxiliary vector entries In-Reply-To: <20260727082710.22446-1-ahajkova@redhat.com> References: <20260727082710.22446-1-ahajkova@redhat.com> Date: Thu, 13 Aug 2026 15:28:22 +0100 Message-ID: <874igy14e1.fsf@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alexandra H=C3=A1jkov=C3=A1 writes: > Add AT_ARGV (52), which contains the address of the argv pointer > array on the initial process stack, and AT_ENVV (53), which contains > the address of the envp pointer array. > > The motivation is to allow GDB to find argv and envp in core dumps > cleanly. Currently GDB locates them by scanning backwards through > stack memory from AT_EXECFN, which is fragile. With AT_ARGV and > AT_ENVV it can read the addresses directly from the core dump's > auxv note. Background: I'm a GDB maintainer, not a kernel maintainer. Alexandra created this patch after I mentioned that Linux lacks this feature that FreeBSD has, and as a result GDB has to search for the ARGV and ENVV on the stack[1][2]. Despite not being a kernel maintainer, I took a look through this patch and had some thoughts, see inline below. [1] https://sourceware.org/git/?p=3Dbinutils-gdb.git;a=3Dblob;f=3Dgdb/linux= -tdep.c;h=3D23e43ba5c5f952d695a41efccab87cf7dc27b1fa;hb=3DHEAD#l1981 [2] https://sourceware.org/git/?p=3Dbinutils-gdb.git;a=3Dblob;f=3Dgdb/fbsd-= tdep.c;h=3D419f935ea72fb5e6a5db65917af2d147aba65676;hb=3DHEAD#l2373 > > Signed-off-by: Alexandra H=C3=A1jkov=C3=A1 > --- > Resending after no response for 4 weeks. > > fs/binfmt_elf.c | 9 ++++++++- > include/linux/auxvec.h | 2 +- > include/uapi/linux/auxvec.h | 2 ++ > 3 files changed, 11 insertions(+), 2 deletions(-) > > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c > index 8e89cc5b2820..c2b3032adccb 100644 > --- a/fs/binfmt_elf.c > +++ b/fs/binfmt_elf.c > @@ -182,6 +182,8 @@ create_elf_tables(struct linux_binprm *bprm, const st= ruct elfhdr *exec, > int ei_index; > const struct cred *cred =3D current_cred(); > struct vm_area_struct *vma; > + elf_addr_t *at_argv_val; > + elf_addr_t *at_envv_val; >=20=20 > /* > * In some cases (e.g. Hyper-Threading), we want to avoid L1 > @@ -288,6 +290,10 @@ create_elf_tables(struct linux_binprm *bprm, const s= truct elfhdr *exec, > NEW_AUX_ENT(AT_RSEQ_FEATURE_SIZE, offsetof(struct rseq, end)); > NEW_AUX_ENT(AT_RSEQ_ALIGN, __alignof__(struct rseq)); > #endif > + at_argv_val =3D elf_info + 1; > + NEW_AUX_ENT(AT_ARGV, 0); > + at_envv_val =3D elf_info + 1; > + NEW_AUX_ENT(AT_ENVV, 0); > #undef NEW_AUX_ENT > /* AT_NULL is zero; clear the rest too */ > memset(elf_info, 0, (char *)mm->saved_auxv + > @@ -309,7 +315,8 @@ create_elf_tables(struct linux_binprm *bprm, const st= ruct elfhdr *exec, > #else > sp =3D (elf_addr_t __user *)bprm->p; > #endif > - > + *at_argv_val =3D (unsigned long)(sp + sizeof(elf_addr_t)); > + *at_envv_val =3D (unsigned long)(sp + (argc + 2)); Is this correct? SP is of type `elf_addr_t __user *sp;`, as such additions to it are in units of `elf_addr_t`, right? So for the `*at_envv_val` line you are increasing SP by: (argc + 2) * sizeof(elf_addr_t) But for the `*at_argv_val` line you are increasing SP by: sizeof(elf_addr_t) * sizeof(elf_addr_t) Which I don't think is what you want. I think the line should be: *at_argv_val =3D (unsigned long)(sp + 1); Also, I wonder about the cast to (unsigned long) here. In the NEW_AUX_ENT macro calls above, when casting is needed, the pattern is to cast to '(elf_addr_t)(unsigned long)' which would make more sense given: elf_addr_t *at_argv_val; elf_addr_t *at_envv_val; Also, I noticed the file fs/binfmt_elf_fdpic.c, which contains the function create_elf_fdpic_tables which is similar to create_elf_tables that you are patching. Some research indicating that the fdpic file is used for some targets without an MMU, but they might also benefit from the same feature, so maybe that file should be patched too? It doesn't look like the exact same fix will work there as things are done in a slightly different order, but I'm sure it should be possible. If that file isn't patched then the commit message should at least mention it, and justify why that's being left undone. Thanks, Andrew >=20=20 > /* > * Grow the stack manually; some architectures have a limit on how > diff --git a/include/linux/auxvec.h b/include/linux/auxvec.h > index 8bcb9b726262..7184de95b89d 100644 > --- a/include/linux/auxvec.h > +++ b/include/linux/auxvec.h > @@ -4,6 +4,6 @@ >=20=20 > #include >=20=20 > -#define AT_VECTOR_SIZE_BASE 24 /* NEW_AUX_ENT entries in auxiliary table= */ > +#define AT_VECTOR_SIZE_BASE 26 /* NEW_AUX_ENT entries in auxiliary table= */ > /* number of "#define AT_.*" above, minus {AT_NULL, AT_IGNORE, AT_NOTE= LF} */ > #endif /* _LINUX_AUXVEC_H */ > diff --git a/include/uapi/linux/auxvec.h b/include/uapi/linux/auxvec.h > index cc61cb9b3e9a..e7af32709aba 100644 > --- a/include/uapi/linux/auxvec.h > +++ b/include/uapi/linux/auxvec.h > @@ -40,5 +40,7 @@ > #ifndef AT_MINSIGSTKSZ > #define AT_MINSIGSTKSZ 51 /* minimal stack size for signal delivery */ > #endif > +#define AT_ARGV 52 /* address of argv[] */ > +#define AT_ENVV 53 /* address of envp[] */ >=20=20 > #endif /* _UAPI_LINUX_AUXVEC_H */ > --=20 > 2.52.0