Re: x86_64

Oops.  My email filter stuck this message into a folder I do not monitor 
regularly.

On Saturday 17 January 2004 19:12, Renaud Deraison wrote:
> On Sat, Jan 17, 2004 at 06:10:11PM -0500, Gene C. wrote:
> > 1. DO NOT apply the x86_64 patches I sent you to your cvs ... they are
> > not good!  While they eliminate some error messages during compile, they
> > also cause other problems ... it appears that this effort will need to
> > start from the ground up.  With those patches applied I get the same (or
> > very similar) errors on a ia32 (i386) system that I do on the Opteron. 
> > The SUSE patches just do not cut it.
>
> Duly noted. BTW, is Opteron little-endian or big-endian ? I fixed some
> 64bits issues which might pop up on big endian 64 bits system yesterday
> - nothing like a segfault, but nasty little things which would break a
>   minor feature or two.

Little-endian just like other ix86 systems and as far as I know there is no 
option to switch like the IA64/Itanium which can be either depending on the 
OS being run.

[snip]
> > 3.  I see that you use two different versions of regex.c in two different
> > places (nessus and libnasl).  
[snip]
>
> The problem is that some distros (RedHat in particular) "optimized"
> their regex and introduced bugs which are difficult to determine at
> compilation-time (see http://bugs.nessus.org/show_bug.cgi?id=90). The
> easy answer would be to say "well, don't use glibc's regexes on RedHat",
> but the problem is that most distros take the stuff RedHat does and
> silently integrates it. Since regexes are fundamentally used, I can't
> really afford to have someone use Nessus and discover six months after
> that that he did not get any false positive because some smartass distro
> decided to slightly change some of the syntax of the regexes or
> optimized it in a way which breaks some stuff.
[snip]

Understood.

>
>
> Once again, I'd *love* to get a shell in your Opteron and I'd probably
> fix all the bugs in a matter of hours, however I understand it's not
> something you can necessarily give me, so I might end up being an AMD64
> box to get decent 64bits support.

Sorry but it is on a closed network.

If you get the opportunity to get one, I recommend it.  If you stick to the 
low end Opteron processors, they are not too expensive.  Ignoring case, power 
supply, disk, cdrom/dvd, keyboard, mouse, monitor, etc., my Opteron system 
with 1GB ram cost about US$750 (motherboard, ram, processor).  I have been 
impressed with the performance even with this low end model.  There is even 
an Athlon64 laptop in the US which costs around US$1600.  All of the 
Athlon64/Opteron processors support the same architecture ... differences are 
performance.

BTW, if there is anything you would like me to test on the Opteron, just ask.

Back to nessus ..

I have again submitted a whole bunch of patches to bugzilla (758 through 762).

Upon further thought, you may again want to ignore most of these.

A prime exception is the patch to fix nessus-config.  Currently, it forces the 
use of -L/usr/lib which has libtool issuing a lot of dire warnings about 
libraries.  The patch will fix that so -L/usr/lib64 is used on the amd64 and 
-L/usr/lib on the ix86.

As for as the changes for the print format strings, that is probably a good 
idea but not something critical.

function prototypes ... I am a strong believe in these but also realize that 
they may not impact the actual runtime code.

As far as the rlimit "problem" on the amd64, I assume you either have that in 
cvs or in process to handle it as a runtime option.  With the 8 byte pointers 
the malloc space really does grow significantly.

BTW, I checked out the code from cvs but am not sure what your development 
branch is so that I can incorporate your changes into what I am doing.

As far as all the casts go, you may want to ignore them ... and I guess that 
is my recommendation for now.  Since creating those patch files, I have 
learned that a lot of packages (at least on Fedora Core and including things 
such as XFree86) produce cast warning.  In this last review, I looked at the 
underlying code and appears (to me) that it should work as currently written.

Now I believe that nessus is one of the premiere vulnerability assessment 
tools and the fact that it is open source is a plus.  I would like to see 
nessus programmed "the right way".

What is the "right way" ... well, casts are not it ... they as simply covering 
over things so that the compiler does not issue warnings.  At this point I am 
coming around the believe that it may be better to have the warnings and have 
people look at the cause to see if things will really work properly.

What is the "right way" ... do things so that the code (and compiler) do not 
care if the pointers and other variables are 32 bit, 64 bits, 80 bites, 128 
bits, or 256 bits.  The way I see it is to use union (and possible struct) to 
define things being passed around and returned.  This would involve a lot of 
code changes in all parts of nessus (libraries, core, plugins).  However, 
once done it should work on all the *nix and Linux systems as well as MS 
Windows (32 bit or 64 bit).

Without  a commitment from you to support such an effort, it is a waste of 
time.  I believe that is true whether you change the code or I develop 
patches which you then review and incorporate.  Given that I do not know your 
priorities, I do not know what to do or to recommend that you do.

If you would like me to make an attempt at this (unions, etc.), it will be 
your call -- I don't want to put too much effort into something that is of no 
use.  I could look into putting together a patch for nessus libraries (or 
perhaps just one function such as harg_get_valuet), and then have you take a 
look to see if you want to proceed or to just forget it.

On second thought, harg_get_valuet/harg_set_valuet may be a big large for a 
"demonstration".  If you have a suggestion of one or two functions to address 
which will demonstrate what it will take without being a major undertaking, 
that would be appreciated.  I would like to do it but ... over to you.
-- 
Gene Czarcinski

_______________________________________________
Nessus-devel mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus-devel