"ps -e" without procfs(5)

[Kostik Belousov]

On Mon, Oct 31, 2011 at 12:54:42PM +0200, Mikolaj Golub wrote:
> 
> On Mon, 31 Oct 2011 11:49:48 +0200 Kostik Belousov wrote:
> 
>  KB> On Sat, Oct 29, 2011 at 01:32:39PM +0300, Mikolaj Golub wrote:
>  >> 
>  >> What do you think about the attached patch? This is a kernel
>  >> part. COMPAT_FREEBSD32 has not been tested after the last update (just checked
>  >> that it compiles): it looks I will not have access to amd64 box for testing
>  >> during the weekend. I will test it after the weekend.
>  >> 
>  >> Both kernel and userland parts are available here:
>  >> 
>  >> http://people.freebsd.org/~trociny/env.sys.patch
>  >> http://people.freebsd.org/~trociny/env.user.patch
>  >> 
>  >> Currently there is an issue with procstat -x: if one tried to run it on 64 bit
>  >> for a 32 bit process it would not detect this so would output a garbage. Could
>  >> somebody recommend a way how to get this info about a process from userlend?
> 
>  KB> I think it is better to use sys/elf.h over the machine/elf.h.
> 
>  KB> Please change the comment for PROC_AUXV_MAX to "Safety limit on auxv size".
>  KB> Also, it worth adding a comment saying that we are reading aux vectors twice,
>  KB> first to get a size, second time to fetch a content, for simplicity.
> 
>  KB> When reading aux vector, if the PROC_AUXV_MAX entries are iterated over,
>  KB> and we still not reached AT_NULL, the return error is 0. Was it intended ?
> 
> According to kern_exec.c it is possible that a process doesn't have auxv at
> all. I don't know a way how to detect this. So because PROC_AUXV_MAX is much
> larger than expected amount of aux entries and we have not reached AT_NULL it
> is most likely the process doesn't have auxv and 0 length array (without
> error) is returned. 
> 
> If you think I should return a error in this situation, I can add this. Please
> tell me the error code I should return :-).
> 
> Also, may be there is a sane way to check on auxv existence?

Hm. Even if the process ABI mandates the existence of auxv (i.e. the
executing binary is ELF), the process could still cleared or mangled the
corresponding stack page.

I propose to designate some specific error code for the case of unparseable
auxv region, ENOEXEC is not worse then any other. Also, please add the
explanation you provided as a comment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20111031/648bc742/attachment.pgp