Re: IPC nsswitch implementation
On Fri, 5 Mar 2004, Jordan K Hubbard wrote: Why not use a UNIX domain socket as the transport and then use credential passing to pass the credentials lookupd should use to do the lookup? that was my thought.. the credential information passing must be useful for something :-) On Mar 5, 2004, at 1:27 PM, Michael Bushkov wrote: When you're using current nss-modules they work as part of your program - and geteuid functions work correctly. But when lookupd is used, euid of the process is lookupds' euid. -- Jordan Hubbard Engineering Manager, BSD Technology Group Apple Computer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPC nsswitch implementation
Hello! What do you mean exactly by saying not as functional? Michael Bushkov Software Engineer, Rostov State University On Fri, 5 Mar 2004, Jordan K Hubbard wrote: Sounds similar to, but not as functional as, the lookupd in Mac OS X. :) On Mar 5, 2004, at 12:45 AM, Michael Bushkov wrote: We want you to look at this lookupd. It would be great for us to know if you like or not the way we made it. And we also want to know if this project can be added to FreeBSD project. -- Jordan Hubbard Engineering Manager, BSD Technology Group Apple Computer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 4.8 on Soekris
I'm currently running FreeBSD 4.8 on a Soekris with Geode's CPU. As i told you in the last email, i see in the pciconf -lv that the SC1100 Watchdog (which is embedded on the mobo, not a pci card) is taken from another driver. What i'm asking myself is if it's normal that the pci generic driver gets control of the device this way, but then i don't understand how i can register as the driver to that watchdog, or if it's a problem due to the fact that it's actually not exactly an x86. I mean, i just wrote the driver for the watchdog, but being Geode an x86 clone, it may be possible that i gotta not only write the driver but also something more about the porting in order to solve this problem? Am i wrong? I can't see any way to solve this problem otherwhise as long as my driver's probe() function isn't called for my watchdog device! This is pciconf -lv for the watchdog device: [EMAIL PROTECTED]:18:5: class=0x068000 card=0x0505100b chip=0x0515100b rev=0x00 hdr=0x00 vendor = 'National Semiconductor' class= bridge subclass = PCI-unknown I don't really know what to do about that. Thanks in advance Claudio Martella P.S. = please reply to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Standard sbc and pcm support in GENERIC kernel?
On Fri, 5 Mar 2004 17:58:26 +0100 (MET), Helge Oldach wrote: So yes: some machines require a kernel with PNPBIOS even when sound modules can be kldload'ed. I presume these are typically boxen without knob to disable the PnP BIOS. Still I wonder whether sound on -CURRENT will do on such a box... I have an old toshiba which also needs PNPBIOS in 4-STABLE and when I tried 5-CURRENT sound just worked. Of course that doesn't say anything about your setup... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Standard sbc and pcm support in GENERIC kernel?
Date: Fri, 5 Mar 2004 20:08:35 +0100 From: Tijl Coosemans [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] On Fri, 5 Mar 2004 17:58:26 +0100 (MET), Helge Oldach wrote: So yes: some machines require a kernel with PNPBIOS even when sound modules can be kldload'ed. I presume these are typically boxen without knob to disable the PnP BIOS. Still I wonder whether sound on -CURRENT will do on such a box... I have an old toshiba which also needs PNPBIOS in 4-STABLE and when I tried 5-CURRENT sound just worked. Of course that doesn't say anything about your setup... That is almost certainly because of ACPI. It handles peripheral devices quite differently from the former mode and, if it works at all on a given system, should eliminate this Plug-n-Play mess when 5 goes STABLE! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Standard sbc and pcm support in GENERIC kernel?
On Fri, 5 Mar 2004 14:49:45 -0500 John Baldwin [EMAIL PROTECTED] wrote: On Wednesday 03 March 2004 04:31 pm, Randy Pratt wrote: On Wed, 3 Mar 2004 17:03:40 +0100 (CET) you wrote: I've been on the question list for some time, and I have noticed that many people do not know how to get sound support up and running in FreeBSD 5.X. I know that re-compiling the kernel is easy enough, but there are still people not willing to do so, as I have noticed on the list. Therefor I thought it might be an idea to put sound support in the GENERIC kernel configuration, so that newbies will no longer find themselves stuck with that. I think I've read more than one time about problems fitting the installation on the 1.44M floppies. That's no longer a problem in 5.x. I would like to see pcm(4) added back to GENERIC on 5.x. 4.x has been around long enough that its GENERIC can probably just stay the way it is. That being the case, then there's no reason not to have it in GENERIC in 5.x. Anyone that doesn't want/need it will be recompiling the kernel to remove other unused options. The less new (desktop) users have to do to get up and running is probably a good thing to do. Any concern I had is gone. Best regards, Randy -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPC nsswitch implementation
[We need to pick a list and stop cross-posting. I pick [EMAIL PROTECTED]'.] On Fri, Mar 05, 2004 at 10:41:33PM +0300, Michael Bushkov wrote: The problem of using Darwin's lookupd was discussed some time ago in the freebsd-arch mailing list. It seems to me that the way to port Darwin's lookupd on FreeBSD was not found, was it? Jordan's message was the first I recall mentioning lookupd. I took a quick peek, seems neat. I'd like to take some more time to examine the APIs it presents. I also intend to look at what you have. Our implementation of lookupd is a demonstration of the approach for the FreeBSD-specific IPC implementation of nsswitch. Its architecture is flexible enough to implement all the features you have mentioned. The version that we have sent isn't a finished project. It's in the development stage and caching is currently our main task. We hope to make caching in the nearest future. We'll try to release stable and quite full version (i mean caching, LDAP module and so on) as soon as we can. You're not going to have to write your own modules (like LDAP), are you? That seems like a big drawback. Our questions are: 1) What do you think about our whole approach to the IPC implementation development? 2) Is there an opportunity to use our implementation of lookupd in the FreeBSD project? We'll be glad to hear your opinion. I'll certainly look at what you have and send comments to this list, but I'm afraid it won't be immediate. You may also want to ping NetBSD guys. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A simple question
ISAAC GELADO FERNANDEZ wrote: De: Chungwei Hsiung [EMAIL PROTECTED] Fecha: Viernes, Marzo 5, 2004 7:43 pm I have a simple test program. I compile it, and gdb to disassemble main. I got the following.. 0x80481f8 main: push %ebp 0x80481f9 main+1: mov%esp,%ebp 0x80481fb main+3: sub$0x8,%esp 0x80481fe main+6: and$0xfff0,%esp 0x8048201 main+9: mov$0x0,%eax 0x8048206 main+14:sub%eax,%esp I don't know if at line 5, we move zero to %eax. why do we need to sub %eax, %esp? why do we need to subtract 0 from the stack pointer?? I am no really sure, but it maybe be because you don't have any local variable, so it is no necessary to allocate memory in the stack for them. This seems a pattern from the compiler, it subtract the size of local variables from the stack pointer, so when there is none it subtracts zero. But this is just a supposition Regards, Isaac ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange instructions in compiler output
Greg 'groggy' Lehey wrote:
On Friday, 5 March 2004 at 13:43:04 -0500, Chungwei Hsiung wrote:
Hello..
I am super new to this list, and I have a simple question that I don't
know why it does that. I have a simple test program. I compile it, and
gdb to disassemble main. I got the following..
0x80481f8 main: push %ebp
0x80481f9 main+1: mov%esp,%ebp
0x80481fb main+3: sub$0x8,%esp
0x80481fe main+6: and$0xfff0,%esp
0x8048201 main+9: mov$0x0,%eax
0x8048206 main+14:sub%eax,%esp
0x8048208 main+16:movl $0x804a6ce,0xfff8(%ebp)
0x804820f main+23:movl $0x0,0xfffc(%ebp)
0x8048216 main+30:sub$0x4,%esp
0x8048219 main+33:push $0x0
0x804821b main+35:lea0xfff8(%ebp),%eax
0x804821e main+38:push %eax
0x804821f main+39:pushl 0xfff8(%ebp)
0x8048222 main+42:call 0x804823c execve
0x8048227 main+47:add$0x10,%esp
0x804822a main+50:mov$0x0,%eax
0x804822f main+55:leave
0x8048230 main+56:ret
I don't know if at line 5, we move zero to %eax. why do we need to sub
%eax, %esp? why do we need to substract 0 from the stack pointer??
Any help is really appreciated.
This is probably because you didn't optimize the output. You'd be
surprised how many redundant instructions the compiler puts in under
these circumstances. Try optimizing and see what the code looks like.
If this *was* done with optimization, let's see the source code.
Greg
--
Note: I discard all HTML mail unseen.
Finger [EMAIL PROTECTED] for PGP public key.
See complete headers for address and phone numbers.
Hello.. thank you very much for the reply
I actually don't know how to use the optimization. I just compile it
with gcc 3.2.2, and use gdb to disassemble main to get this assembly. Is
it possible I can get the non-redundent output?
here is the code I compile..
#include stdio.h
int main(void) {
char *name[2];
name[0] = /bin/sh;
name[1] = NULL;
execve(name[0], name, NULL);
return(0);
}
best regards
Chungwei
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange instructions in compiler output
Greg 'groggy' Lehey wrote: On Friday, 5 March 2004 at 18:43:11 -0500, Chungwei Hsiung wrote: Greg 'groggy' Lehey wrote: On Friday, 5 March 2004 at 13:43:04 -0500, Chungwei Hsiung wrote: Hello.. I am super new to this list, and I have a simple question that I don't know why it does that. I have a simple test program. I compile it, and gdb to disassemble main. I got the following.. 0x8048201 main+9: mov$0x0,%eax 0x8048206 main+14:sub%eax,%esp ... I don't know if at line 5, we move zero to %eax. why do we need to sub eax, %esp? why do we need to substract 0 from the stack pointer?? Any help is really appreciated. This is probably because you didn't optimize the output. You'd be surprised how many redundant instructions the compiler puts in under these circumstances. Try optimizing and see what the code looks like. If this *was* done with optimization, let's see the source code. Hello.. thank you very much for the reply I actually don't know how to use the optimization. Use the gcc command line options. See below. I just compile it with gcc 3.2.2, and use gdb to disassemble main to get this assembly. Is it possible I can get the non-redundent output? here is the code I compile.. ... The best way to look at the assembly output is to generate it directly from the compiler. I get: $ cc -O -pipe -mcpu=pentiumpro -S exec.c $ cat exec.s .LC0: .string /bin/sh ... main: pushl %ebp movl%esp, %ebp subl$24, %esp andl$-16, %esp movl$.LC0, -8(%ebp) leal-8(%ebp), %edx movl$0, 4(%edx) movl-8(%ebp), %eax movl%eax, (%esp) movl%edx, 4(%esp) movl$0, 8(%esp) callexecve movl$0, %eax movl%ebp, %esp popl%ebp ret This doesn't look that much like your code. Without the -O (optimize) flag I get: $ cc -pipe -mcpu=pentiumpro -S exec.c $ cat exec.s ... main: pushl %ebp movl%esp, %ebp subl$24, %esp andl$-16, %esp movl$0, %eax subl%eax, %esp movl$.LC0, -8(%ebp) So yes, it looks as if you're not optimizing. Greg -- Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. hello greg.. yes.. it does the difference.. thanks a lot for your help.. Chungwei ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Standard sbc and pcm support in GENERIC kernel?
Dan Langille [EMAIL PROTECTED] writes: On Fri, 5 Mar 2004, Dan Langille wrote: *That* explanation is vast difference to saying they have to read man pcm(4). The difference is sigficicant. In the same breath, someone needs to install a spell checker and verify the grammer. ^^^ Ain't that the truth! DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Standard sbc and pcm support in GENERIC kernel?
Jamie Bowden [EMAIL PROTECTED] writes: It also presumes the end user has net access, which is not a given. The handbook is installed in /usr/share/doc, though it isn't updated when you build world. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Standard sbc and pcm support in GENERIC kernel?
Tijl Coosemans [EMAIL PROTECTED] writes: I have an old toshiba which also needs PNPBIOS in 4-STABLE and when I tried 5-CURRENT sound just worked. Of course that doesn't say anything about your setup... PNPBIOS is on by default (and non-optional) in 5.x. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Standard sbc and pcm support in GENERIC kernel?
On Mar 05, Daniel Lang wrote: Hi, David Raistrick wrote on Fri, Mar 05, 2004 at 08:27:56AM -0800: [..] kldload snd_driver is of course the correct way to do it. FWIW, kldunload snd_driver does /not/ unload all of the modules that kldload snd_driver loads. [..] snd_driver is a module that contains _all_ drivers, thus you have the best chance to get sound working. Unloading it, will of course unload the whole module with all drivers. There is no way to leave one of the drivers in the kernel. I agree, that there is not much documentation which driver module supports which sound device (or I was not successful to dig that up). However, you can determine the correct module, by subsequently loading and unloading each individual driver module. The one which attached to your sound device and actually works (check /dev/sndstat as well) is obviously the correct one. Not a very efficient way, but it works. :) David and Daniel, First let me say that on my 5.x machine, kldunload snd_driver does unload all the modules (and detaches the drivers when applicable). In regards to how hard it is to know which module provides the driver, I've just added to -current the following, [EMAIL PROTECTED] cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: CMedia CMI8738 at io 0xb800 irq 11 kld snd_cmi (1p/1r/0v channels duplex default) pcm1: Creative EMU10K1 at io 0xb400 irq 5 kld snd_emu10k1 (4p/2r/0v channels duplex) So the installation procedure is, as root. kldload snd_driver for each kld xxx in the output echo xxx_load=\YES\ /boot/loader.conf Does this seem reasonable? --Mat -- In general, a standard is very useful, whether it's de facto or du jour. - Microsoft's Greg Sullivan as misquoted by News.Com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange instructions in compiler output (was: A simple question)
Hello everyone
Thanks for fellows' previous helps. I actually have a further question. I read an
article that it says if I compile the following program
#include stdio.h
int main(){
char *name[2];
name[0] = /bin/sh;
name[1] = NULL;
execve(name[0],name,NULL);
return 0;
}
by
gcc -o shellcode -ggdb -static shellcode.c
when i disassemble execve inside gdb, I should be able to see the assembly code for
execve, but I can't see those codes for execve().
Does anyone know how I can get the assembly code and see how the execve() works??
btw, I am using gcc3.2.2
any help is really appreciated
best regards
Chungwei
On Sat, 6 Mar 2004 10:02:09 +1030
Greg 'groggy' Lehey [EMAIL PROTECTED] wrote:
On Friday, 5 March 2004 at 13:43:04 -0500, Chungwei Hsiung wrote:
Hello..
I am super new to this list, and I have a simple question that I don't
know why it does that. I have a simple test program. I compile it, and
gdb to disassemble main. I got the following..
0x80481f8 main: push %ebp
0x80481f9 main+1: mov%esp,%ebp
0x80481fb main+3: sub$0x8,%esp
0x80481fe main+6: and$0xfff0,%esp
0x8048201 main+9: mov$0x0,%eax
0x8048206 main+14:sub%eax,%esp
0x8048208 main+16:movl $0x804a6ce,0xfff8(%ebp)
0x804820f main+23:movl $0x0,0xfffc(%ebp)
0x8048216 main+30:sub$0x4,%esp
0x8048219 main+33:push $0x0
0x804821b main+35:lea0xfff8(%ebp),%eax
0x804821e main+38:push %eax
0x804821f main+39:pushl 0xfff8(%ebp)
0x8048222 main+42:call 0x804823c execve
0x8048227 main+47:add$0x10,%esp
0x804822a main+50:mov$0x0,%eax
0x804822f main+55:leave
0x8048230 main+56:ret
I don't know if at line 5, we move zero to %eax. why do we need to sub
%eax, %esp? why do we need to substract 0 from the stack pointer??
Any help is really appreciated.
This is probably because you didn't optimize the output. You'd be
surprised how many redundant instructions the compiler puts in under
these circumstances. Try optimizing and see what the code looks like.
If this *was* done with optimization, let's see the source code.
Greg
--
Note: I discard all HTML mail unseen.
Finger [EMAIL PROTECTED] for PGP public key.
See complete headers for address and phone numbers.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Standard sbc and pcm support in GENERIC kernel?
[EMAIL PROTECTED]: Tijl Coosemans [EMAIL PROTECTED] writes: I have an old toshiba which also needs PNPBIOS in 4-STABLE and when I tried 5-CURRENT sound just worked. Of course that doesn't say anything about your setup... PNPBIOS is on by default (and non-optional) in 5.x. That's great, so my peculiar Compaq Deskpro EN scenario should be fine as well. I will try a FreeSBIE boot anyway to verify. BTW, why not make PNPBIOS on by default in 4-STABLE? Is this a danger of breaking things, aka POLA violation against prepare for 5.x upgrade case? Helge ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Style(9) and portability
One of the recommendations in style(9) is inherently non-portable. I'm trying to ensure that the new code I'm writing for FreeBSD is portable to other systems, so I've been scratching my head over how to deal with the version ID code that is supposed to apear as the first two lines of any FreeBSD source file: #include sys/cdefs.h __FBSDID($FreeBSD$); Clearly, I cannot reasonably assume that all platforms define a __FBSDID macro in sys/cdefs.h. I'm looking for advice from people with a lot of experience on different Unix (and even non-Unix) systems to decide which of the following alternatives I should be using instead. The first option here will fail to port only if a system does not have a sys/cdefs.h header (or if it exists but provides a conflicting definition of __FBSDID, which seems highly unlikely): 1) #include sys/cdefs.h #ifdef __FBSDID __FBSDID($FreeBSD$); #endif The second option deals with the issue by pushing it onto a header that encapsulates platform-specific definitions. In particular, the local platform.h header can include sys/cdefs.h on FreeBSD and provide an alternative definition of __FBSDID on other platforms. The drawback is, of course, the requirement for a new local header file to wrap platform-specific decisions: 2) #include platform.h /* Platform-specific defines */ __FBSDID($FreeBSD$); My instinct is that #1 is preferable in kernel source files and #2 is preferable in userland files, mostly from the belief that userland sources are more likely to be ported and therefore have more stringent portability concerns. Unless someone can suggest a better alternative, I'm probably going to implement some variation on #2 in libarchive and my other userland work going forward. Any input or advice appreciated, Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange instructions in compiler output (was: A simple question)
try compiling with the -static flag the gcc. then 'disassemble execve'.
-Anthony.
On Sat, Mar 06, 2004 at 02:26:51PM +, chungwei Hsiung wrote:
Hello everyone
Thanks for fellows' previous helps. I actually have a further question. I read an
article that it says if I compile the following program
#include stdio.h
int main(){
char *name[2];
name[0] = /bin/sh;
name[1] = NULL;
execve(name[0],name,NULL);
return 0;
}
by
gcc -o shellcode -ggdb -static shellcode.c
when i disassemble execve inside gdb, I should be able to see the assembly code
for execve, but I can't see those codes for execve().
Does anyone know how I can get the assembly code and see how the execve() works??
btw, I am using gcc3.2.2
any help is really appreciated
best regards
Chungwei
On Sat, 6 Mar 2004 10:02:09 +1030
Greg 'groggy' Lehey [EMAIL PROTECTED] wrote:
On Friday, 5 March 2004 at 13:43:04 -0500, Chungwei Hsiung wrote:
Hello..
I am super new to this list, and I have a simple question that I don't
know why it does that. I have a simple test program. I compile it, and
gdb to disassemble main. I got the following..
0x80481f8 main: push %ebp
0x80481f9 main+1: mov%esp,%ebp
0x80481fb main+3: sub$0x8,%esp
0x80481fe main+6: and$0xfff0,%esp
0x8048201 main+9: mov$0x0,%eax
0x8048206 main+14:sub%eax,%esp
0x8048208 main+16:movl $0x804a6ce,0xfff8(%ebp)
0x804820f main+23:movl $0x0,0xfffc(%ebp)
0x8048216 main+30:sub$0x4,%esp
0x8048219 main+33:push $0x0
0x804821b main+35:lea0xfff8(%ebp),%eax
0x804821e main+38:push %eax
0x804821f main+39:pushl 0xfff8(%ebp)
0x8048222 main+42:call 0x804823c execve
0x8048227 main+47:add$0x10,%esp
0x804822a main+50:mov$0x0,%eax
0x804822f main+55:leave
0x8048230 main+56:ret
I don't know if at line 5, we move zero to %eax. why do we need to sub
%eax, %esp? why do we need to substract 0 from the stack pointer??
Any help is really appreciated.
This is probably because you didn't optimize the output. You'd be
surprised how many redundant instructions the compiler puts in under
these circumstances. Try optimizing and see what the code looks like.
If this *was* done with optimization, let's see the source code.
Greg
--
Note: I discard all HTML mail unseen.
Finger [EMAIL PROTECTED] for PGP public key.
See complete headers for address and phone numbers.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
pgp0.pgp
Description: PGP signature
Re: Style(9) and portability
At 20:18 06/03/2004, Tim Kientzle wrote: I've been scratching my head over how to deal with the version ID code that is supposed to apear as the first two lines of any FreeBSD source file: #include sys/cdefs.h __FBSDID($FreeBSD$); Clearly, I cannot reasonably assume that all platforms define a __FBSDID macro in sys/cdefs.h. Portability doesn't mean the code wiil compile on every platform and C compiler in the world. Most platforms will have their own packaging systems and directory hierarchy, so *some* changes will have to be made every time code is ported; as long as the necessary changes are obvious, I don't see that there is any real problem. Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange instructions in compiler output
Anthony Schneider [EMAIL PROTECTED] writes: On Sat, Mar 06, 2004 at 02:26:51PM +, chungwei Hsiung wrote: gcc -o shellcode -ggdb -static shellcode.c try compiling with the -static flag the gcc. Reading is fast becoming a lost art... Anyway, here's the code for execve(): 08048224 __sys_execve: 8048224: b8 3b 00 00 00 mov$0x3b,%eax 8048229: cd 80 int$0x80 804822b: 72 ef jb 804821c main+0x3c 804822d: c3 ret 804822e: 90 nop 804822f: 90 nop exciting, huh? oh, and the code that calls it: 8048201: 6a 00 push $0x0 8048203: 8d 45 f8lea0xfff8(%ebp),%eax 8048206: 50 push %eax 8048207: ff 75 f8pushl 0xfff8(%ebp) 804820a: e8 15 00 00 00 call 8048224 __sys_execve 804820f: 83 c4 10add$0x10,%esp DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange instructions in compiler output
thanks for the reply compile the code by gcc -o shellcode -ggdb -static shellcode.c actually giving me the code you showed below I still don't understand it because we are supposed to pass in the op code 0xb to %eax, and arguments to %ebx, %ecx, and %edx before calling interupt, but I can't see any of those instruction anywhere. Did I miss anything? best regards, Chungwei On Sat, 06 Mar 2004 21:31:51 +0100 [EMAIL PROTECTED] (Dag-Erling Smørgrav) wrote: Anthony Schneider [EMAIL PROTECTED] writes: On Sat, Mar 06, 2004 at 02:26:51PM +, chungwei Hsiung wrote: gcc -o shellcode -ggdb -static shellcode.c try compiling with the -static flag the gcc. Reading is fast becoming a lost art... Anyway, here's the code for execve(): 08048224 __sys_execve: 8048224: b8 3b 00 00 00 mov$0x3b,%eax 8048229: cd 80 int$0x80 804822b: 72 ef jb 804821c main+0x3c 804822d: c3 ret 804822e: 90 nop 804822f: 90 nop exciting, huh? oh, and the code that calls it: 8048201: 6a 00 push $0x0 8048203: 8d 45 f8lea0xfff8(%ebp),%eax 8048206: 50 push %eax 8048207: ff 75 f8pushl 0xfff8(%ebp) 804820a: e8 15 00 00 00 call 8048224 __sys_execve 804820f: 83 c4 10add$0x10,%esp DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange instructions in compiler output
chungwei Hsiung [EMAIL PROTECTED] writes: I still don't understand it because we are supposed to pass in the op code 0xb to %eax, and arguments to %ebx, %ecx, and %edx before calling interupt, but I can't see any of those instruction anywhere. Did I miss anything? Huh? Arguments are passed on the stack, and execve() is syscall 59 (0x3b as you can see in the disassembly). What gave you the idea that we were passing arguments in registers? This isn't DOS, you know... DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange instructions in compiler output
OH yes... this is FreeBSD not linux, I will try it on the linux box later thank you for the clarification, but how does FreeBSD know where the passed arguments are?? just out of curiosity.. thanks again Chungwei On Sat, 06 Mar 2004 21:47:10 +0100 [EMAIL PROTECTED] (Dag-Erling Smørgrav) wrote: chungwei Hsiung [EMAIL PROTECTED] writes: I still don't understand it because we are supposed to pass in the op code 0xb to %eax, and arguments to %ebx, %ecx, and %edx before calling interupt, but I can't see any of those instruction anywhere. Did I miss anything? Huh? Arguments are passed on the stack, and execve() is syscall 59 (0x3b as you can see in the disassembly). What gave you the idea that we were passing arguments in registers? This isn't DOS, you know... DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange instructions in compiler output
chungwei Hsiung [EMAIL PROTECTED] writes: thank you for the clarification, but how does FreeBSD know where the passed arguments are?? just out of curiosity.. They are on the stack, just like in a regular function call. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Style(9) and portability
At 12:18 PM -0800 3/6/04, Tim Kientzle wrote: ... I've been scratching my head over how to deal with the version ID code that is supposed to apear as the first two lines of any FreeBSD source file: #include sys/cdefs.h __FBSDID($FreeBSD$); Clearly, I cannot reasonably assume that all platforms define a __FBSDID macro in sys/cdefs.h. Really, you can't even assume that all platforms will *have* a sys/cdefs.h The second option deals with the issue by pushing it onto a header that encapsulates platform-specific definitions. In particular, the local platform.h header can include sys/cdefs.h on FreeBSD and provide an alternative definition of __FBSDID on other platforms. The drawback is, of course, the requirement for a new local header file to wrap platform-specific decisions: 2) #include platform.h /* Platform-specific defines */ __FBSDID($FreeBSD$); This is basically the tactic that I went with for everything under lpr. That works reasonably well for lpr, but I don't know if it makes sense for everything: #include lp.cdefs.h /* A cross-platform version of sys/cdefs.h */ I intentionally have the comment about sys/defs.h, in case someone comes along later and scans for that string... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Style(9) and portability
On Sat, Mar 06, 2004 at 12:18:21PM -0800, Tim Kientzle wrote: One of the recommendations in style(9) is inherently non-portable. I'm trying to ensure that the new code I'm writing for FreeBSD is portable to other systems, so I've been scratching my head over how to deal with the version ID code that is supposed to apear as the first two lines of any FreeBSD source file: #include sys/cdefs.h __FBSDID($FreeBSD$); Clearly, I cannot reasonably assume that all platforms define a __FBSDID macro in sys/cdefs.h. Our compiler defines __FreeBSD__. You might be able to do: #ifdef __FreeBSD__ #include sys/cdefs.h __FBSDID($FreeBSD$); #endif The advantage of something like this is that you don't spam the library on non-FreeBSD systems. Just a thought... -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
