On Sat, Oct 29, 2011 at 01:32:39PM +0300, Mikolaj Golub wrote:
[KERN_PROC_AUXV requires just p_cansee()]
If we are ever going to do ASLR, the AUXV information tells an attacker
where the stack, executable and RTLD are located, which defeats much of
the point of randomizing the addresses in the
On 4 Dec 2011, at 14:31, Jilles Tjoelker wrote:
On Sat, Oct 29, 2011 at 01:32:39PM +0300, Mikolaj Golub wrote:
[KERN_PROC_AUXV requires just p_cansee()]
If we are ever going to do ASLR, the AUXV information tells an attacker
where the stack, executable and RTLD are located, which defeats
On Sun, 4 Dec 2011 15:57:06 + Robert N. M. Watson wrote:
RNMW On 4 Dec 2011, at 14:31, Jilles Tjoelker wrote:
On Sat, Oct 29, 2011 at 01:32:39PM +0300, Mikolaj Golub wrote:
[KERN_PROC_AUXV requires just p_cansee()]
If we are ever going to do ASLR, the AUXV information tells an
On Sun, 4 Dec 2011 15:57:06 + Robert N. M. Watson wrote:
RNMW On 4 Dec 2011, at 14:31, Jilles Tjoelker wrote:
On Sat, Oct 29, 2011 at 01:32:39PM +0300, Mikolaj Golub wrote:
[KERN_PROC_AUXV requires just p_cansee()]
If we are ever going to do ASLR, the AUXV information tells an
On Sun, Dec 04, 2011 at 10:58:10PM +0200, Mikolaj Golub wrote:
RNMW Agreed. In general, my view is that p_cansee() should be used for very
RNMW few of our process inspection APIs. I like your example of ASLR
RNMW especially, as it illustrates how debugging information can aid even
RNMW
On Wed, 9 Nov 2011 14:53:29 +0200 Kostik Belousov wrote:
http://people.freebsd.org/~trociny/env.sys.4.patch
Investigating cases when EFAULT was returned and if the fallback was
successful I noticed that most of the cases were when p-p_comm changed
during
the read, so the
On Wed, 09 Nov 2011 15:31:26 +0200 Mikolaj Golub wrote:
MG On Wed, 9 Nov 2011 14:53:29 +0200 Kostik Belousov wrote:
And now you return success and nothing gets copied out for the process
in P_INEXEC state. Either you should return an error like EAGAIN, or
consider the P_INEXEC state as
On Tue, Nov 08, 2011 at 11:47:54PM +0200, Mikolaj Golub wrote:
On Sun, 6 Nov 2011 20:10:41 +0200 Kostik Belousov wrote:
KB On Sat, Nov 05, 2011 at 10:37:46PM +0200, Mikolaj Golub wrote:
http://people.freebsd.org/~trociny/env.sys.3.patch
KB Oops, I missed this in the previous
On Wed, Nov 09, 2011 at 02:44:55PM +0200, Kostik Belousov wrote:
On Tue, Nov 08, 2011 at 11:47:54PM +0200, Mikolaj Golub wrote:
On Sun, 6 Nov 2011 20:10:41 +0200 Kostik Belousov wrote:
KB On Sat, Nov 05, 2011 at 10:37:46PM +0200, Mikolaj Golub wrote:
On Wed, 9 Nov 2011 14:44:55 +0200 Kostik Belousov wrote:
KB On Tue, Nov 08, 2011 at 11:47:54PM +0200, Mikolaj Golub wrote:
http://people.freebsd.org/~trociny/env.sys.4.patch
Investigating cases when EFAULT was returned and if the fallback was
successful I noticed that most of the
On Wed, 9 Nov 2011 14:53:29 +0200 Kostik Belousov wrote:
And now you return success and nothing gets copied out for the process
in P_INEXEC state. Either you should return an error like EAGAIN, or
consider the P_INEXEC state as transitional and wait till process
leaves it. Or, ignore the
On Sun, 6 Nov 2011 20:10:41 +0200 Kostik Belousov wrote:
KB On Sat, Nov 05, 2011 at 10:37:46PM +0200, Mikolaj Golub wrote:
http://people.freebsd.org/~trociny/env.sys.3.patch
KB Oops, I missed this in the previous review. You cannot use fubyte in
KB proc_read_mem(). fubyte reads a byte
On Sat, 5 Nov 2011 15:58:01 +0200 Kostik Belousov wrote:
KB procfs_doproccmdline() can benefit from your work.
Patch for procfs:
http://people.freebsd.org/~trociny/procfs.patch
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
On Sat, Nov 05, 2011 at 10:37:46PM +0200, Mikolaj Golub wrote:
On Sat, 5 Nov 2011 21:45:53 +0200 Kostik Belousov wrote:
KB On Sat, Nov 05, 2011 at 08:59:21PM +0200, Mikolaj Golub wrote:
On Sat, 5 Nov 2011 17:44:43 +0200 Kostik Belousov wrote:
KB I think that the aux vector
On Mon, 31 Oct 2011 11:49:48 +0200 Kostik Belousov wrote:
KB I suspect this is my bug: Reading the GET_PS_STRINGS_CHUNK_SZ may validly
KB return EFAULT if the string is shorter than the chunk and aligned at
KB the end of the page, assuming the next page is not mapped. There should
KB be a
On Wed, Nov 02, 2011 at 11:27:37PM +0200, Mikolaj Golub wrote:
On Mon, 31 Oct 2011 11:49:48 +0200 Kostik Belousov wrote:
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
KB auxv size. Also, it worth adding
On Sat, 5 Nov 2011 15:58:01 +0200 Kostik Belousov wrote:
KB +if (error == EFAULT) {
KB +for (i = 0; i len; i++) {
KB +c = fubyte(sptr + i);
KB +if (c 0)
KB As a purely stylistical issue, compare with -1.
KB +
On Sat, Nov 05, 2011 at 05:40:22PM +0200, Mikolaj Golub wrote:
On Sat, 5 Nov 2011 15:58:01 +0200 Kostik Belousov wrote:
KB +if (error == EFAULT) {
KB +for (i = 0; i len; i++) {
KB +c = fubyte(sptr + i);
KB +if (c
On Sat, 5 Nov 2011 17:44:43 +0200 Kostik Belousov wrote:
KB I think that the aux vector must be naturally aligned. You can return
KB ENOEXEC early if vptr is not aligned.
Not sure I see what you mean. vptr for auxv is calculated just couple lines
above, and I check the result here,
On Sat, Nov 05, 2011 at 08:59:21PM +0200, Mikolaj Golub wrote:
On Sat, 5 Nov 2011 17:44:43 +0200 Kostik Belousov wrote:
KB I think that the aux vector must be naturally aligned. You can return
KB ENOEXEC early if vptr is not aligned.
Not sure I see what you mean. vptr for auxv
On Sat, 5 Nov 2011 21:45:53 +0200 Kostik Belousov wrote:
KB On Sat, Nov 05, 2011 at 08:59:21PM +0200, Mikolaj Golub wrote:
On Sat, 5 Nov 2011 17:44:43 +0200 Kostik Belousov wrote:
KB I think that the aux vector must be naturally aligned. You can
return
KB ENOEXEC early if
On Mon, 31 Oct 2011 11:49:48 +0200 Kostik Belousov wrote:
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
On Mon, 31 Oct 2011 11:49:48 +0200 Kostik Belousov wrote:
KB For PROC_ARG and PROC_ENV, you blindly trust the read values of the arg and
KB env vector sizes. This can easily cause kernel panics due to unability to
KB malloc the requested memory. I recommend to put some clump, and twice
KB of
On Tue, Nov 01, 2011 at 09:07:11AM +0200, Mikolaj Golub wrote:
On Mon, 31 Oct 2011 11:49:48 +0200 Kostik Belousov wrote:
KB For PROC_ARG and PROC_ENV, you blindly trust the read values of the arg
and
KB env vector sizes. This can easily cause kernel panics due to unability to
KB
On Sat, Oct 29, 2011 at 01:32:39PM +0300, Mikolaj Golub wrote:
On Tue, 25 Oct 2011 11:24:51 +0300 Kostik Belousov wrote:
KB On Tue, Oct 25, 2011 at 12:13:10AM +0300, Mikolaj Golub wrote:
On Sun, 16 Oct 2011 20:10:05 +0300 Kostik Belousov wrote:
KB In my opinion, the way to
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):
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
On Tue, 25 Oct 2011 11:24:51 +0300 Kostik Belousov wrote:
KB On Tue, Oct 25, 2011 at 12:13:10AM +0300, Mikolaj Golub wrote:
On Sun, 16 Oct 2011 20:10:05 +0300 Kostik Belousov wrote:
KB In my opinion, the way to implement the feature is to (re)use
KB linprocfs_doargv() and provide
On Tue, Oct 25, 2011 at 12:13:10AM +0300, Mikolaj Golub wrote:
On Sun, 16 Oct 2011 20:10:05 +0300 Kostik Belousov wrote:
KB In my opinion, the way to implement the feature is to (re)use
KB linprocfs_doargv() and provide another kern.proc sysctl to retrieve the
KB argv and env vectors.
On 25 Oct 2011, at 09:24, Kostik Belousov wrote:
On Tue, Oct 25, 2011 at 12:13:10AM +0300, Mikolaj Golub wrote:
On Sun, 16 Oct 2011 20:10:05 +0300 Kostik Belousov wrote:
KB In my opinion, the way to implement the feature is to (re)use
KB linprocfs_doargv() and provide another kern.proc
On Tue, 25 Oct 2011 11:24:51 +0300 Kostik Belousov wrote:
KB On Tue, Oct 25, 2011 at 12:13:10AM +0300, Mikolaj Golub wrote:
On Sun, 16 Oct 2011 20:10:05 +0300 Kostik Belousov wrote:
KB In my opinion, the way to implement the feature is to (re)use
KB linprocfs_doargv() and provide
On Sun, 16 Oct 2011 20:10:05 +0300 Kostik Belousov wrote:
KB In my opinion, the way to implement the feature is to (re)use
KB linprocfs_doargv() and provide another kern.proc sysctl to retrieve the
KB argv and env vectors. Then, ps(1) and procstat(1) can use it, as well as
KB procfs and
On Sun, Oct 16, 2011 at 07:57:57PM +0300, Mikolaj Golub wrote:
Hi,
I have a patch that makes kvm_uread() read from user space using ptrace(2).
http://people.freebsd.org/~trociny/kvm_uread.ptrace.patch
With this change 'ps -e' does not requires procfs(5).
Do you like it or there might
Hi,
I have a patch that makes kvm_uread() read from user space using ptrace(2).
http://people.freebsd.org/~trociny/kvm_uread.ptrace.patch
With this change 'ps -e' does not requires procfs(5).
Do you like it or there might be some reasons why it is a bad idea?
Grepping sources it looks like
34 matches
Mail list logo
