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
> RN
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 tel
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 tel
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 defe
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 f
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
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 s
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, ign
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
fall back to byte read ?
> >
> > KB> I would prefer using sizeof(uint64_t) and sizeof(uint32_t) instead of 8
> > KB> and 4 constants in the align checks.
> >
> > KB> Might be, add PROC_ASSERT_HELD() to get_ps_string() ?
> >
> > KB> procfs
in the align checks.
>
> KB> Might be, add PROC_ASSERT_HELD() to get_ps_string() ?
>
> KB> procfs patch looks good.
>
> Thanks. The updated version:
>
> http://people.freebsd.org/~trociny/env.sys.4.patch
>
> Investigating cases when EFAULT was returned an
read_mem should fall back to byte read ?
KB> I would prefer using sizeof(uint64_t) and sizeof(uint32_t) instead of 8
KB> and 4 constants in the align checks.
KB> Might be, add PROC_ASSERT_HELD() to get_ps_string() ?
KB> procfs patch looks good.
Thanks. The updated version:
http:
oc_read_mem(). fubyte reads a byte from the address space of the current
process. The fix is easy, use proc_rwmem for 1 byte.
I do not think that fall back to single byte read is warranted for
proc_read_mem calls e.g. for ps_strings. Add a flag to indicate whether
the proc_read_mem should fall back to byte read ?
I would prefer using sizeof(uint64_t) and sizeof(uint32_t) instead of 8
and 4 constants in the align checks.
Might be, add PROC_ASSERT_HELD() to get_ps_string() ?
procfs patch looks good.
pgp9ZRbUSX5B9.pgp
Description: PGP signature
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
h
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>
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
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 re
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> +
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 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 wo
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 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> f
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
>
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>
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_FREEBSD
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 c
ov 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
&g
)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 linprocfs inside the kernel.
>>
>> Thanks! I
)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 linprocfs inside the kernel.
>>
>> Thanks! I
; 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 linprocfs inside the kernel.
>>
>> Thanks! I am testing a patch (without auxv vector so far)
e
> KB> argv and env vectors. Then, ps(1) and procstat(1) can use it, as well as
> KB> procfs and linprocfs inside the kernel.
>
> Thanks! I am testing a patch (without auxv vector so far) and have some
> questions.
>
> Original ps -e returns environment only for user o
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>
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
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 pr
On Fri, 4 Jan 2008, [EMAIL PROTECTED] wrote:
Also, have you considered procstat ? (as i read here:
http://ivoras.sharanet.org/freebsd/freebsd8.html it is destined to replace
procfs in a way, am I wrong ?)
Depending on how short term your application must be available (and how long
it will
eed.
And I just made a fool of myself by mistaking procfs for linprocfs: ooops,
awfully sorry :-(
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
t.org/freebsd/freebsd8.html
it is destined to replace procfs in a way, am I wrong ?)
Depending on how short term your application must be available (and how long it
will take to MFC procstat), it might do the thing.
___
freebsd-hackers@freebsd.org mail
"Fernando Apesteguía" <[EMAIL PROTECTED]> writes:
> Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes:
> > "Fernando Apesteguía" <[EMAIL PROTECTED]> writes:
> > > I have an application written in C + Gtk + Glib that gathers
> > >
On Jan 3, 2008 9:53 PM, Ivan Voras <[EMAIL PROTECTED]> wrote:
> Fernando Apesteguía wrote:
>
> > Maybe a mix of both could be good: use the linxprocfs when it is
> > almost straightforward (in fact I could run the app, just changing few
> > lines) and sysctl when the linprocfs doesn't provide the i
Fernando Apesteguía wrote:
> Maybe a mix of both could be good: use the linxprocfs when it is
> almost straightforward (in fact I could run the app, just changing few
> lines) and sysctl when the linprocfs doesn't provide the information
> that I need.
Also, linprocfs is never mounted by default
On Jan 3, 2008 8:50 PM, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote:
> "Fernando Apesteguía" <[EMAIL PROTECTED]> writes:
> > I have an application written in C + Gtk + Glib that gathers
> > information from procfs under Linux. Now, I'm trying to port th
"Fernando Apesteguía" <[EMAIL PROTECTED]> writes:
> I have an application written in C + Gtk + Glib that gathers
> information from procfs under Linux. Now, I'm trying to port this
> application to FreeBSD (I'm working with 7.0 RC1).
man linprocfs
DES
--
Dag
On Thu, Jan 03, 2008 at 06:26:21PM +0100, Fernando Apestegu?a wrote:
> Hi all,
>
> I post my question in this list cause Ivan Voras ([EMAIL PROTECTED])
> suggested that here I could find more help.
>
> I have an application written in C + Gtk + Glib that gathers
> informat
Hi all,
I post my question in this list cause Ivan Voras ([EMAIL PROTECTED])
suggested that here I could find more help.
I have an application written in C + Gtk + Glib that gathers
information from procfs under Linux. Now, I'm trying to port this
application to FreeBSD (I'm working wi
On Thu, Jan 03, 2008 at 05:16:42PM +0100, Ivan Voras wrote:
> On 03/01/2008, Fernando Apesteguía <[EMAIL PROTECTED]> wrote:
>
> > Yes, that's my problem. In Linux I can get from /proc/cpuinfo for
> > example: name, model, stepping, cache size, clock speed, supported
> > extensions, etc...
> > But
On 03/01/2008, Fernando Apesteguía <[EMAIL PROTECTED]> wrote:
> Yes, that's my problem. In Linux I can get from /proc/cpuinfo for
> example: name, model, stepping, cache size, clock speed, supported
> extensions, etc...
> But using sysctl in FreeBSD (sysctl -a) I can only see name and vendor
> for
Hi Guys!
We have patch of unionfs that supports procfs/vfs_cache. With this
patch, you can use application that use procfs on unionfs.
unionfs patch for procfs/vfs_cache support:
document
http://people.freebsd.org/~daichi/unionfs/request-for-test.html
For 7-current
http
On Thu, Jun 17, 2004 at 03:28:47PM +0530, ravi wrote:
> Hi,
> How to get a pointer to pfs_info structure which points to the /proc
> directory ?
>
> I mean , I want to create a proc entry under /proc .
> But for this I need to pass an argument struct pfs_info *pi, which
> contains a member p
Hi,
How to get a pointer to pfs_info structure which points to the /proc
directory ?
I mean , I want to create a proc entry under /proc .
But for this I need to pass an argument struct pfs_info *pi, which
contains a member pi_root which inturn points to the /proc's pfs_node
How to get th
fo_proc.
>
> So, outside of kvm and procfs, is there any user<->kernel interface for
> getting to struct proc or just those counters? (getrusage is kinda
> close except one can't lookup info about another process. :|. )
libkvm uses two back-ends to retrieve information from the
Hello, -hackers!
I'm poring over some code that uses the p_[usi]ticks counters inside
of struct proc. This is fine under 4.x where kinfo_proc includes
a copy of proc, but is broken under 5.x since a commit 3 years ago
that reorganized kinfo_proc.
So, outside of kvm and procfs, is there any
Terry Lambert said:
> The problem is that ktrace/kdump rendesvous at a file;
> truss does
> not, so it has some capabilities that ktrace does not.
> In some
> circumstances (e.g. a system crash, where kdump doesn't
> get a
> chance to get at the file, because it's "cleaned up"
> and not
> even ful
John Baldwin wrote:
> Since ktrace logs all syscall entries and exits, it should seem that
> a kdump after the process had exited would show which syscall returned
> EAGAIN quite easily.
This works if the process exits after the EAGAIN; that would only
work for the specific error that people are s
On 18-Jul-2003 Terry Lambert wrote:
> Pawel Jakub Dawidek wrote:
>> +> trussRelies on the event model of procfs; there have been some
>> +> initial patches and discussion of migrating truss to ptrace() but
>> +> I don't
In the last episode (Jul 18), Pawel Jakub Dawidek said:
> On Fri, Jul 18, 2003 at 01:45:34AM -0700, Terry Lambert wrote:
> +> > +> truss Relies on the event model of procfs; there have been
> +> > +>some initial patches and discussion of migrating truss
> +&
On Fri, Jul 18, 2003 at 01:45:34AM -0700, Terry Lambert wrote:
+> > +> trussRelies on the event model of procfs; there have been some
+> > +> initial patches and discussion of migrating truss to ptrace() but
+> > +> I don&#x
Pawel Jakub Dawidek wrote:
> +> trussRelies on the event model of procfs; there have been some
> +> initial patches and discussion of migrating truss to ptrace() but
> +> I don't think we have anything very usable yet. I'd be h
On Thu, Jul 17, 2003 at 01:01:11PM -0400, Robert Watson wrote:
+> Most system functionality that relied on procfs has been rewritten to rely
+> on other mechanisms. In general, I advise against running procfs--it's
+> interesting, but conceptually it's very risky. If you
On Tue, 15 Jul 2003, Josh Brooks wrote:
> I have loaded two 5.1-RELEASE systems, both of them have PROCFS and
> PSEUDOFS in the kernel, and yet neither of them have a procfs mounted.
>
> There is no procfs line in /etc/fstab by default, and no procfs is
> mounted on the sy
On Tue, Jul 15, 2003 at 10:43:19PM -0700, Josh Brooks wrote:
[...]
> One of the systems, the one I am doing all the work on, is an SMP system,
> and it keeps locking up on me - the lockups are always the same - things
> are going fine, and suddenly a process fails to complete - maybe it is
> "pwd"
On Wed, 16 Jul 2003, Bruce M Simpson wrote:
> On Tue, Jul 15, 2003 at 10:43:19PM -0700, Josh Brooks wrote:
> > I have loaded two 5.1-RELEASE systems, both of them have PROCFS and
> > PSEUDOFS in the kernel, and yet neither of them have a procfs mounted.
>
> I think on
On Tue, Jul 15, 2003 at 10:43:19PM -0700, Josh Brooks wrote:
> I have loaded two 5.1-RELEASE systems, both of them have PROCFS and
> PSEUDOFS in the kernel, and yet neither of them have a procfs mounted.
I think one of the first things people are going to ask is:
which scheduler are you
Hello,
I have loaded two 5.1-RELEASE systems, both of them have PROCFS and
PSEUDOFS in the kernel, and yet neither of them have a procfs mounted.
There is no procfs line in /etc/fstab by default, and no procfs is mounted
on the system in any way.
Question 1: Is this intentional ? Is it no
)
devfs on /dev (devfs, local)
/dev/ad0s1g on /home (ufs, local, acls)
/dev/ad0s1f on /tmp (ufs, local, soft-updates)
/dev/ad0s1h on /usr (ufs, local, soft-updates)
/dev/ad0s1e on /var (ufs, local, soft-updates)
big# /sbin/mount -t procfs proc /proc
big# /sbin/mount -t procfs proc /mnt
big# mount
/de
Hi all,
I just checked the code. Umount(8) is fine. Unmount(2)
is buggy.
> Looks like the wrong got unmounted. The mountlist should
> be traversed in reverse order.
umount(8) works as it should:
umount -v procfs
procfs: unmount from /mnt (but it does unmount /proc)
umount(8) hands ov
Hi,
I just checked this:
-su-2.05b# mount -t procfs proc /proc/
-su-2.05b# mount -t procfs proc /mnt
-su-2.05b# mount
[...]
procfs on /proc (procfs, local)
procfs on /mnt (procfs, local)
-su-2.05b# umount procfs
-su-2.05b# mount
[...]
procfs on /mnt (procfs, local)
Looks like the wrong got
On Sun, 26 Jan 2003, Tim Kientzle wrote:
> Experimenting with 'mount' and stumbled across the following oddity:
>
> mount -t procfs proc /mnt
> umount -t /mnt
You're missing the "proc" after -t here, right?
> results in procfs still mounted on /m
Experimenting with 'mount' and
stumbled across the following oddity:
mount -t procfs proc /mnt
umount -t /mnt
results in procfs still mounted on /mnt
but no longer mounted on /proc. It
appears that a umount of procfs is
unmounting the most recently mounted
instance rather than th
On Thu, Jun 20, 2002 at 11:13:02PM +0200, Pawel Jakub Dawidek wrote:
+> What You think about something like that:
+> [17:33:39] [ttyv8] [61] leila:root:/sys/miscfs/procfs# diff procfs_subr.c.orig
+procfs_subr.c
[...]
+> This gives us new sysctl (vfs.procfs.umask) and with this we ca
What You think about something like that:
[17:33:39] [ttyv8] [61] leila:root:/sys/miscfs/procfs# diff procfs_subr.c.orig
procfs_subr.c
42a43
> #include
80a82,119
>
> SYSCTL_NODE(_vfs, OID_AUTO, procfs, CTLFLAG_RW, 0, "vfs-procfs-level");
>
> int procfsuma
On 13-Apr-2002 Alfred Perlstein wrote:
> First off, nice job fixing up sys_process.c it's a lot cleaner now and
> the races seem to be gone, however there may still be a problem.
>
> Please see: kern/29741:
> ptrace(pid);ptrace(ppid) makes pid and ppid unkillable
> http://www.freebsd.org/cgi/q
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> It looks like the following delta (submitted by Tim J. Robbins) may
> fix it:
It looks correct to me, please commit (unless John has any
objections?)
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
wit
First off, nice job fixing up sys_process.c it's a lot cleaner now and
the races seem to be gone, however there may still be a problem.
Please see: kern/29741:
ptrace(pid);ptrace(ppid) makes pid and ppid unkillable
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern%2F29741
It looks like the follo
In message <E1450DFD283DD6118492A5F0032356BD7C@STLABCEXG024>, "Alton, Matth
ew" writes:
>Are there any plans to expand the procfs implementation to provide an
>interface that is more in line with the implementations on Unixware,
>Solaris and AIX? I've been writin
* Alton, Matthew <[EMAIL PROTECTED]> [020402 16:18] wrote:
>
> I managed to glean from that the FreeBSD implementation
> is basically a barebones interface that is only there for gdb to work
> with.
>
> So has there been any talk of making the ctl file take
> command/operands structs as input,
>From colleague:
Hello,
Are there any plans to expand the procfs implementation to provide an
interface that is more in line with the implementations on Unixware,
Solaris and AIX? I've been writing a simple debugger that would be
portable among those three platforms, and others, b
On 03-May-01 Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Kevin Day writes:
>: The PCI target itself isn't doing anything like that, but it's possible that
>: the PCI-PCI bridge we're going through might be. In any case, getting the
>: NMI isn't really all that bad, it's stopping the chips
In message <[EMAIL PROTECTED]> Kevin Day writes:
: The PCI target itself isn't doing anything like that, but it's possible that
: the PCI-PCI bridge we're going through might be. In any case, getting the
: NMI isn't really all that bad, it's stopping the chipset from getting hung
: on a infinite r
>
> In message <[EMAIL PROTECTED]> Kevin Day writes:
> : I tried sending this from my work account, but our new exchange server isn't
> : exactly sending mail correctly... Excuse the duplicate post if you see it.
> : :)
>
> It sounds like the PCI card that you are trying to read from is
> genera
In message <[EMAIL PROTECTED]> Kevin Day writes:
: I tried sending this from my work account, but our new exchange server isn't
: exactly sending mail correctly... Excuse the duplicate post if you see it.
: :)
It sounds like the PCI card that you are trying to read from is
generating the pci faul
to happen,
and I'm happy with that. If we run the exact same code through gdb
(which seems to use procfs somehow) we get:
Fatal trap 19: non-maskable interrupt trap while in kernel mode
instruction pointer = 0x8:0xc0306860
stack pointer = 0x10:0xede2ce28
frame pointer
On Mon, 19 Mar 2001 [EMAIL PROTECTED] wrote:
:> :Is there an easy way (from script ideally) to get the following
:> :stats:
:> :
:> :free physical mem (avail ram)
:>
:> has a reasonable uptime. The VM system will cache things unless
:> there's a demand for memory. vm.stats.vm.v_free_count
> > :total avail mem
> >
> > Do you mean physical memory, in which case the value of hw.physmem will
> > tellyou.
>
> Phys mem + swap, which I think I can calc pretty easily now
> that I have swap. -sc
That's not actually a useful number either. 8)
Bear in mind, for example, that progr
> : Is there an easy way (from script ideally) to get the following
> :stats:
> :
> :free physical mem (avail ram)
>
> This is going to be quite small on any busy machine, or machine that
> has a reasonable uptime. The VM system will cache things unless
> there's a demand for memory. vm.sta
On Mon, 19 Mar 2001 [EMAIL PROTECTED] wrote:
: Is there an easy way (from script ideally) to get the following
:stats:
:
:free physical mem (avail ram)
This is going to be quite small on any busy machine, or machine that has a
reasonable uptime. The VM system will cache things unless ther
On 20-Mar-01 [EMAIL PROTECTED] wrote:
> Is there an easy way (from script ideally) to get the following
> stats:
>
> free physical mem (avail ram)
> free swap
> total avail mem
>
> any two of the three would be great. If such a beast doesn't
> exist, what are the easiest cal
Is there an easy way (from script ideally) to get the following
stats:
free physical mem (avail ram)
free swap
total avail mem
any two of the three would be great. If such a beast doesn't
exist, what are the easiest calls to use to get at them so I could
write some programs that
> partitions (/usr, /var, etc.) and the installation went fine. I then
> proceeded to install a few ports, and those ran fine. But last night I was
> downloading something and then I was getting an error saying /proc was full.
> As much as I've looked, I can't find out e
all a few ports, and those ran fine. But last night I was
downloading something and then I was getting an error saying /proc was full.
As much as I've looked, I can't find out exactly what procfs is... I'm
wondering how I can be out of space when I have 10 gigs free on my drive. Is
On Mon, 3 Apr 2000, visi0n wrote:
> I was thinking how normal programs get info about cpu and memory
> utilization in bsd's systems, (maybe sysctl ?).
In the olden days, you used to have to read kernel data structures through
/dev/mem (or friends(?)). This usually means that you have to
I was thinking how normal programs get info about cpu and memory
utilization in bsd's systems, (maybe sysctl ?).
===
visi0n
AUX Technologies
[www.aux-tech.org]
To Unsubscribe: send mail to [EMAIL PROTECTED]
wi
: Unfortunately, when you take setuid programs into account, it gets
: far less clear: Reasonable cases could be made for having the owner
: either the real or effective UID.
The case for effective seems quite clear to me, but
I can't see the case for real UID. What is it?
To Unsubscribe: se
Sat, 6 Nov 1999 15:54:50 -0500 (EST), Brian Fundakowski Feldman <[EMAIL PROTECTED]>
wrote:
> does it seem as if the pathname of the executable being stored as
>a virtual symlink in procfs as "file" would solve these security
>problems?
I'm not convinced that this solves
On Sat, 6 Nov 1999, Warner Losh wrote:
> There are ways that the user can see the code to execute it, but not
> read it normally. procfs breaches this inability to read the file.
> Also, there are many related problems which make a proper fix for this
> that is more complicated t
On Sun, 7 Nov 1999, Sean Eric Fagan wrote:
> I don't, but what I like doesn't matter, it seems -- Warner knows everything.
> So I'm sure he knows better than I do the overhead this will impose, and the
> impracticality in a general system.
>
> Unix really isn't set up to carry around 'official p
> >You can make hard links to
>
> No, you cannot.
Yes you can - you just need to make sure the target directory is on
the same filesystem as the *original* file.
11:30:gonzo 9% cp /bin/sleep /tmp
11:30:gonzo 10% ls -l /tmp/sleep*
-r-xr-xr-x 1 dwmalone wheel 45224 Nov 7 11:30 /tmp/sleep
11:3
> Err... I don't see the problem. The permissions of the hardlink will
> be different, so the user might be able to see the "code", but won't
> be able to run the suid (because the hardlink won't have the suid
> bit set).
Suid bit is stored in the inode, not the directory entry, so it will
be set
st me,
> >> or does it seem as if the pathname of the executable being stored as
> >> a virtual symlink in procfs as "file" would solve these security
> >> problems?
> >M... I like that...
>
> I don't, but what I like doesn't matter, it
utable being stored as
>> a virtual symlink in procfs as "file" would solve these security
>> problems?
>M... I like that...
I don't, but what I like doesn't matter, it seems -- Warner knows everything.
So I'm sure he knows better than I do the overhead this wi
Brian Fundakowski Feldman wrote:
>
> It sounds to me that what you really want are the semantics of a
> symbolic link and not the semantics of a hard link. Is it just me,
> or does it seem as if the pathname of the executable being stored as
> a virtual symlink in procfs as &qu
1 - 100 of 118 matches
Mail list logo
