nessus and the AMD64
"Gene C." <[email protected]>
| Newsgroups | gmane.comp.security.nessus.devel |
|---|---|
| Message-ID | <[email protected]> |
OK, I have nessus 2.0.9 (all parts) built and running -- they compile clean (no cast warnings) and run OK. Patches have been posted to bugzilla. I have started looking at nessus 2.0.10a and see that some (not all) of the problems addressed by the patches are in 2.0.10a. However, at least one of these updates has not caused a problem for sparc/Solaris -- http://bugs.nessus.org/show_bug.cgi?id=739 -- I am not sure how to address this particular problem in nessus without something in ./configure which specifically says the system is linux-64bit or having a patch which is applied to such systems (the current patch works OK on Fedora Core Linux i386 and x86_64 but I am not sure about other Linux systems let alone *BSD). I am not sure what the right solution is but comments would be appreciated. The AMD Opteron/Athlon64 processors is the first hardware which has significant performance improvement when it is run in 64 bit mode ... double the number of registers which the compiler can use. This means (to me) that a lot of code can and will be ported to be 64 bit applications. Other processors such as the Sparc and the PowerPC which are capable of dual mode do not have this improvement (and may even have less performance besides having larger pointers and code size). So, anyway, this is my incentive to get nessus running on the AMD64 ... I believe that there is a future to it (and so does Microsoft since they have a 64 bit windows in beta). What I am looking for in the following are comments such as ... "this does not make sense because ...", "this does make sense because ...", and/or "oops, that does not work on the xxx systems since we do not have that capability/feature/etc." 1. On the AMD64 pointers are 8 bytes and size_t is also 8 bytes. On the i386 pointers are 4 bytes and size_t is also 4 bytes. On both systems, the size of int is 4 bytes and the size of long int is 8 bytes. Therefore, in functions such as regex.c which do some strange things with pointers, making some of the other variables be size_t rather than unsigned int gets rid of the "cast" warning messages (about assignments between pointers and variables). Questions: . Will this work on other systems such as Solaris? . Will this work on the AMD64 versions of *BSD? 2. I see that some of the printing of pointer values in debug messages have been changed from "%d" to "%ld". I believe that the proper way to handle printing pointers is to use "%p" which will do 8 byte pointers in a 64 bit application and 4 byte pointers in a 32 bit application. Question: . Is "%p" available on all the other systems? 3. At least on Linux with glibc, there is "%zd" which does something similar for size_t variables ... does 8 bytes in 64 bit applications and 4 bytes in 32 bit applications. To me, this should be preferable to using "%ld" everywhere ... it is more correct. Question: . Is "%zd" available on other systems? 4. For the most part, nessus uses prototypes to make sure that parameters are properly passed. There are some cases (e.g., bpf_datalink in libnessus/ids_send.c) where there is no prototype. Proposed: prototypes should be defined/used for all functions. Ask additional ideas/questions occur to me, I will post additional messages. I look forward to comments. -- Gene Czarcinski _______________________________________________ Nessus-devel mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus-devel