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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.