Re: Q: System call interception
On Sun, 3 Sep 2000, Pavlin Ivanov Radoslavov wrote: Intercepting syscalls is very easy. In my mind, what you should do is write a KLD that creates a syscall that mimicks the actions of what Thanks for the detailed info and the pointers. However, I forgot to mention that the solution I need should not require modifications to the system, and should not require root privilege. A number of spiffy replacement/wrapper libc libraries exist. In FreeBSD, applications generally invoke a syscall wrapper compiled into libc automatically using the syscall table (/usr/src/sys/kern/syscalls.master). By interposing a replacement library ahead of libc (must be dynamically linked), you can intercept invocations of these and other functions in libc, replacing them with your own calls. This is done to support socks, for example, wherein socket calls are replaced with socks versions of the same calls. The userland network stack, (Alpine?) was recently posted about on freebsd-net, and does much the same, replacing network calls in the application with invocations of the userland network stack. It's easy to imagine other types of syscall replacement, including catch invocations of syscall(2) directly by the application. Won't help you with assembly code, but whether or not this is an issue depends on whether the syscall interception is intended for functionality additions (SOCKS) or security. If security, the ptrace()/procfs scheme should be able to do that, but I'm not so familiar with that -- take a look at the FreeBSD-specific components of gdb to get an idea here. As mentioned already, our kernel is designed to support replaceable syscall handlers, and TIS has actually released a "wrapper toolkit" to allow the writing of security wrappers to impose new policies. This is implemented on FreeBSD, Solaris, and I believe work is underway for Windows NT and Linux. Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel problem...
The old procedure doesn't work after I run make I receive empty string, and then when I try to run make install I received First start to built the kernel and then install it. Also I tried to change smth in Makefile but nothing help, please if somebody can answer how I can boot my FreeBSD-3.5 if his root filesystem is on /dev/idad0s1a. I tried to enter everything when FreeBSD boot, but every time I receiving Can't mount root on wd0 Can't mount root on wda0 and after this my system rebooting Even if I enter boot: 0:da(0,a) Excuse for my English. On Mon, 4 Sep 2000, void wrote: On Sun, Sep 03, 2000 at 11:24:43PM +0300, petro wrote: How can I set KERNEL in /etc/make.conf -??? please write me more, because I am not so power user Thank you KERNEL= KERNEL_NAME just the same way all the other variables in make.conf are set ... but if you're using 3.x, then I think the old build procedure is what you want: cd /sys/i386/conf config KERNEL_NAME cd ../../compile/KERNEL_NAME make depend make make install -- Ben 220 go.ahead.make.my.day ESMTP Postfix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
looking for microuptime went backwards victims...
I'm looking for the remaining victims of the dreaded "microuptime
went backwards" message.
If you can reliably reproduce the problem, please contact me, so
we can arrange for some very detailed tracing to try to find out
what exactly is going on. I have not been able to trigger the
problem in my lab in a long time.
If you see the message only occationally, please try the attached
patch and let me know if this changes the picture. The patch is
not meant as a fix, but it might reduce the impact of this condition
considerably when it happens. Basically by reducing the width of
the timecounter the magnitude of the hit we take if the timecounter
goes backwards is reduced from about an hour to approx 110msec.
Reducing the width to less than 17 bits starts to run the risk of
ambiguity due to clock rollover.
This patch may not be safe with PCAUDIO.
Poul-Henning
Index: clock.c
===
RCS file: /home/ncvs/src/sys/i386/isa/clock.c,v
retrieving revision 1.155
diff -u -r1.155 clock.c
--- clock.c 2000/07/30 21:05:22 1.155
+++ clock.c 2000/09/04 16:34:16
@@ -194,7 +194,7 @@
static struct timecounter i8254_timecounter = {
i8254_get_timecount,/* get_timecount */
0, /* no poll_pps */
- ~0u,/* counter_mask */
+ 0x1,/* counter_mask */
0, /* frequency */
"i8254" /* name */
};
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
dlopen()
I am trying an example I got from a magazine originally written for Linux which dynamically loads shared libraries and instantiates C++ classes within them. Being a recent FreeBSD convert, I intended to run this example on it. However, I am having a problem. I did read the man page for dlopen(), and searched the mailing lists for similar problems. Consequently, I learned to use -Wl,export-dynamic, but still have not seemed to resolve the problem: when the program calls dlopen to load the library, it returns ./libcircle.so: Undefined symbol "__pure_virtual" Now if I remove all pure virtual functions, it naturally just leads to some other symbol not being found, so I assume it's not a C++ related matter. Am I just not linking correctly? My makefile is as follows: - .cc.o: g++ -ggdb -c -fpic -fPIC $ default: make testdcl testdcl: testdcl.o g++ -Wl,-export-dynamic -o testdcl testdcl.o libcircle.so:circle.o g++ -shared -Wl,-export-dynamic -o libcircle.so circle.o libsquare.so:square.o g++ -shared -Wl,-export-dynamic -o libsquare.so square.o all: testdcl libcircle.so libsquare.so clean: rm -f *.so *.o testdcl Any help would be greatly appreciated. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
