On 24 Jan 2013, at 16:20, John Baldwin wrote:
Hmm, are you going to rewrite ps(1) to use libprocstat? Or rather, is that
a
goal someday? That is one current consumer of kvm_getargv/envv. That might
be fine if we want to make more tools use libprocstat instead of using
libkvm
directly.
On 26 Jun 2012, at 15:42, m...@freebsd.org wrote:
While I understand the problems you allude to, the sysctl(8) binary
can protect itself from them. IMO the biggest problem with sysctls
not being files is that it makes no sense from the core UNIX
philosophy that everything is a file.
On 9 Jun 2012, at 10:46, Mikolaj Golub wrote:
On Sat, 9 Jun 2012 12:07:40 +0300 Konstantin Belousov wrote:
KB Well, if I see a report informing me that some 2M region contains 512
super
KB pages, how should I interpret it ? For me, it is only one superpage
(mapping)
KB that can be
On 9 Jun 2012, at 11:05, Konstantin Belousov wrote:
First, there is nothing which would prevent demotion from happens while
you iterate over the map, so you could get funyy numbers, like 42 superpages
for 2M region with your method.
Second, the superpage size if machine-depended, and even
On 29 May 2012, at 18:06, vasanth rao naik sabavat vasanth.raon...@gmail.com
wrote:
My main concern is about the protocol control block inp, a reference in the
socket structure. the udp_detach() free'es the inp but there is a potential
for other thread running udp_* functions to get hold of
On 29 May 2012, at 21:09, vasanth rao naik sabavat wrote:
I am trying to understand the socket -- protocol layer as part of our
project. I was trying to understand why the sotoinpcb() is called before
taking any locks. Also, I am trying to understand scenario of a
multi-threaded process
On 17 Mar 2012, at 19:30, Mikolaj Golub wrote:
Currently we can check and change binary osreldate of another process via
procfs(5).
Kostik suggested to add a new sysctl for the same purpose and also extend
procstat to show osrel.
Here are patches I am going to commit if there are no
On 12 Jan 2012, at 06:03, Adrian Chadd wrote:
On 11 January 2012 15:26, Gerald McNulty gmn...@gmail.com wrote:
Using IP_BINDANY to facilitate transparent proxying works as specified.
According the ip(4) man page and sys/netinet/ip_output.c, the
PRIV_NETINET_BINDANY privilege is required in
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 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 31 Jul 2011, at 12:22, Jayachandran C. wrote:
In fact, there are some toolchain bugs I'm running into that manifest only
in the SDE toolchain and not the FreeBSD toolchain. (Mind you, Philip has
commented that in building Uboot for MIPS, he's found FreeBSD bugs that
don't appear in the
On 27 Jul 2011, at 16:57, per...@pluto.rain.com wrote:
s s...@samu.pl wrote:
... I am trying to compare the owner of the symlink to the owner
of what the symlink points to ... At first I was trying to check
wheter some user is trying to create such a symlink ...
I've always considered
On 8 Jul 2011, at 05:02, Matt Olander wrote:
What about inetd? Is that possible or does each service it support
need sandboxing, too? How about sendmail and bind?
I'm less concerned about the core connection juggling content of inetd than the
external services it launches -- however, inetd
On 8 Jul 2011, at 19:08, Brian Reichert wrote:
On Fri, Jul 08, 2011 at 07:42:12AM +0400, Ilya Bakulin wrote:
The question is: which applications should also be processed? I think
that the most wanted candidates are SUID programs and/or popular network
daemons.
I propose 'man'; sneaky
On 7 Apr 2011, at 10:13, Ilya Bakulin wrote:
some time ago I've read a paper about Capsicum (it was published at Google
reseach papers page). I think that this is an interesting technology, and
adopting it for use in FreeBSD base system is worth an effort. Also I see
this idea as GSoC
On 2 Apr 2011, at 19:47, Warner Losh wrote:
(2) Working clang/LLVM cross-compile of FreeBSD. This seems like a basic
requirement to adopt clang/LLVM, and as far as I'm aware that's not yet a
resolved issue?
0 work has been done here to my knowledge. The world view for clang and our
On 27 Mar 2011, at 21:04, Kostik Belousov wrote:
The most serious issue with prebind is a consistency.
It is very easy to get prebind data out of date, and this is
esp. easy in the FreeBSD where buildworld and source port upgrades
are everyday activity.
Before this goes much further, yes,
On 8 Feb 2011, at 10:37, Alan Cox wrote:
John and I have occasionally talked about making procstat -v work on the
kernel; conceivably it could also export a wired page count for mappings
where it makes sense. Ideally procstat would drill in a bit and allow you
to see things at least at
On 8 Feb 2011, at 12:47, John Baldwin wrote:
What I have used is a 'kvm' command in my kgdb scripts, but it is not nearly
that granular. It is also a view of the virtual address space (similar to
procstat -v), not a view of the physical address space. I have found it
useful though (sample
On 19 Sep 2010, at 09:21, Andriy Gapon wrote:
I believe the combination of these approaches would significantly solve the
problem and should be relatively little new code. It should also preserve
the
adaptable nature of the system without penalizing resource heavy systems. I
would be
On 19 Sep 2010, at 09:42, Andriy Gapon wrote:
on 19/09/2010 11:27 Jeff Roberson said the following:
I don't like this because even with very large buffers you can still have
high
enough turnover to require per-cpu caching. Kip specifically added UMA
support
to address this issue in zfs.
On 18 Sep 2010, at 12:27, Andriy Gapon wrote:
on 18/09/2010 14:23 Robert Watson said the following:
I've been keeping a vague eye out for this over the last few years, and
haven't
spotted many problems in production machines I've inspected. You can use the
umastat tool in the tools tree
On 18 Sep 2010, at 13:35, Fabian Keil wrote:
Doesn't build for me on amd64:
f...@r500 /usr/src/tools/tools/umastat $make
Warning: Object directory not changed from original
/usr/src/tools/tools/umastat
cc -O2 -pipe -fno-omit-frame-pointer -std=gnu99 -fstack-protector
-Wsystem-headers
On 5 Jul 2010, at 10:25, James Morris wrote:
I'm happy to help contribute to the writing on an Internet Draft and/or
RFC -- the lack of NFS support for EAs (and the EA vs. file fork
confusion) have long caused me frustration, and with systems like
SELinux, our various MAC policies, and
On 2 Jul 2010, at 01:44, James Morris wrote:
I've been working on an implementation of extended attributes for the
Linux NFSv3 code, initially based on the IRIX implementation [1]. This is
being developed as a sideband protocol ('XATTR'), to convey simple
name/value string extended
On 17 Dec 2009, at 18:25, Linda Messerschmidt wrote:
On Wed, Dec 16, 2009 at 6:52 AM, Robert Watson rwat...@freebsd.org wrote:
Could you tell us a bit more about the network configuration -- especially,
are you using any tunneling software (such as ipsec), netgraph, or other
less commonly
On 10 Dec 2009, at 09:59, Ivan Voras wrote:
You have a point there. I was actually thinking more of sysvshm -
which doesn't have anything to do with any of the issues here - but
has some of the same properties (and is also used by databases - e.g.
postgresql, which I'm using daily so it sort
On 19 Nov 2009, at 10:57, Sharad Chandra wrote:
Thanks everyone. mmap(2) worked and program did not crash. Only problem with
it I use only fraction of allocated memory (each request alocate minimum of
one page and my request is in hundreds), rest is waste of it so no one else
will get
On 16 Aug 2009, at 22:09, David Wagner wrote:
Beyond this, and assuming the correct implementation of the above,
we're into the grounds of classic trusted OS covert channel analysis,
against which no COTS UNIX OSes I'm aware of are hardened. This
isn't to
dismiss these attacks as purely
On 13 Jul 2009, at 19:17, John Baldwin wrote:
Callouts are marked as MPSAFE or non-MPSAFE when registered. If
non-MPSAFE,
we will acquire Giant automatically for the callout, but I believe
we'll also
try and sort non-MPSAFE callouts behind MPSAFE ones in execution
order to
minimize
30 matches
Mail list logo
