GNAT 3.14p and Red Hat 7.2

GNAT 3.14p and Red Hat 7.2

[Ken Nelson]

GNAT 3.14p was released to run on GNU Linux (Red Hat 6.2).  Has anyone
ported it to Red Hat 7.2?  If not, can someone from ACT comment on how
much work this would be and the best way(s) to perform a port?


Ken

Re: GNAT 3.14p and Red Hat 7.2

[Mark Johnson]

Ken Nelson wrote:
> 
> GNAT 3.14p was released to run on GNU Linux (Red Hat 6.2).  Has anyone
> ported it to Red Hat 7.2?  If not, can someone from ACT comment on how
> much work this would be and the best way(s) to perform a port?
> 
> Ken

I guess I don't understand the question. We have been using 3.14a (as
well as 3.15w, 3.15a,...) for some time on both RH 7.1 and 7.2 systems
(building applications & running them) without any problems at all.
Install it, change your path, and go. I could guess at the problem you
are having but perhaps you could elaborate :-) some more.
  --Mark

Re: GNAT 3.14p and Red Hat 7.2

[Ken Nelson]

Mark Johnson <mark_h_johnson@raytheon.com> wrote in message news:<3C9F40A2.5AF3920D@raytheon.com>...
> Ken Nelson wrote:
> > 
> > GNAT 3.14p was released to run on GNU Linux (Red Hat 6.2).  Has anyone
> > ported it to Red Hat 7.2?  If not, can someone from ACT comment on how
> > much work this would be and the best way(s) to perform a port?
> > 
> > Ken
> 
> I guess I don't understand the question. We have been using 3.14a (as
> well as 3.15w, 3.15a,...) for some time on both RH 7.1 and 7.2 systems
> (building applications & running them) without any problems at all.
> Install it, change your path, and go. I could guess at the problem you
> are having but perhaps you could elaborate :-) some more.
>   --Mark

Well, since your a _paying_ customer, it _should_ work for you.   ;-) 


In the GNAT 3.14p announcement thread...

http://groups.google.com/groups?hl=en&threadm=5ee5b646.0202030611.1df3899a%40posting.google.com&rnum=1&prev=/groups%3Fq%3Dannounce%2Bgnat%2B3.14p%2Bgroup:comp.lang.ada%26hl%3Den%26selm%3D5ee5b646.0202030611.1df3899a%2540posting.google.com%26rnum%3D1


...the following exchange took place between John English and Robert
Dewar:


John English <je@brighton.ac.uk> wrote in message news:<3C63B527.ABA4F1A7@brighton.ac.uk>...


> Wouldn't it make more sense to target a new GNAT version 
> to the current Red Hat version rather than one that's 
> about a year out of date?


The 3.14p sources were frozen some time ago, when Red Hat
version 7 was not in wide use. The current version of GNAT (e.g. the
sources at gnu.org) are indeed targetted for more
up to date versions. It is up to you whether you want to
operate at the bleeding edge with software that has not
been tested in the field extensively (the GNAT 5 version
at gnu.org), or you want to use a version that has been
extensively tested in the field (the 3.14p distribution).
But you can't have it both ways, if you want something that
is absolutely up to date, it will not have been extensively
tested. That's the way things are  :-)



Indicating that if I simply run GNAT 3.14p on Red Hat 7.2, it will
probably "go bump in the night" at a bad time (that never happens at a
good time).  So, having some time and interest, I decided to attempt
building the compiler from its sources.


I have a working copy of GNAT 3.13p and gcc 2.8.1

[ken@linux gcc-2.8.1-gnat-3.14p]$ gnatmake -v

GNATMAKE 3.13p  (20000509) Copyright 1995-2000 Free Software
Foundation, Inc.
Usage: gnatmake  opts  name  {[-cargs opts] [-bargs opts] [-largs
opts]}

[ken@linux gcc-2.8.1-gnat-3.14p]$ gcc -v
Reading specs from /home/free_sw/apps/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/specs
gcc version 2.8.1


I have done the following:

1.  Unpacked gcc-2.8.1 source
2.  Copied the GNAT 3.14p src/ada directory into the gcc 2.8.1
directory
3.  Applied the gcc-281.dif patches
4.  Touched cstamp-h.in
5.  Did not see any specific instructions for this target
6.  Touched treeprs.ads a-[es]info.h nmake.ad[bs] in ada directory
7.  Ran GCC's configure script with no parameters
8.  Successfully ran: make CC=gcc CFLAGS="-O2" LANGUAGES="c ada gcov"
9.  Successfully ran: make CC=gcc CFLAGS="-O2" LANGUAGES="c ada gcov"
bootstrap
10. However, make CC=gcc CFLAGS="-O2" gnattools  produces:

../xgcc -B../  -DIN_GCC   -O2   -o ../gnatmem b_gnatmem.o gnatmem.o
memroot.o a-gmem.o a-adaint.o a-argv.o a-cio.o a-cstrea.o a-exit.o
a-final.o a-init.o a-raise.o a-sysdep.o ada.o a-comlin.o a-except.o
a-filico.o a-finali.o a-flteio.o a-inteio.o a-ioexce.o a-stream.o
a-tags.o a-textio.o a-tiflau.o a-tigeau.o a-tiinau.o a-tiocst.o gnat.o
g-casuti.o g-hesora.o g-htable.o g-os_lib.o gnatvsn.o interfac.o
i-cstrea.o system.o s-assert.o s-except.o s-exctab.o s-exngen.o
s-exnllf.o s-fatllf.o s-ficobl.o s-fileio.o s-finimp.o s-finroo.o
s-imgbiu.o s-imgenu.o s-imgint.o s-imgllb.o s-imglli.o s-imgllu.o
s-imgllw.o s-imgrea.o s-imguns.o s-imgwiu.o a-traceb.o s-traceb.o
s-mastop.o s-parame.o s-powtab.o s-secsta.o s-sopco3.o s-sopco4.o
s-sopco5.o s-stache.o s-stalib.o s-stoele.o s-stratt.o s-strops.o
s-soflin.o s-unstyp.o s-valllu.o s-vallli.o s-valint.o s-valrea.o
s-valuns.o s-valuti.o ../prefix.o \
	-laddr2line -lbfd -liberty 
a-adaint.o: In function `__gnat_tmp_name':
a-adaint.o(.text+0x42c): the use of `tmpnam' is dangerous, better use
`mkstemp'
g-os_lib.o: In function `gnat__os_lib__create_temp_file':
g-os_lib.o(.text+0x2f1): the use of `mktemp' is dangerous, better use
`mkstemp'
a-gmem.o: In function `__gnat_gmem_a2l_initialize':
a-gmem.o(.text+0xc4): undefined reference to `convert_addresses'
a-gmem.o: In function `__gnat_gmem_read_bt_frame':
a-gmem.o(.text+0x20d): undefined reference to `convert_addresses'
make[2]: *** [../gnatmem] Error 1
make[2]: Leaving directory `/home/free_sw/gcc-2.8.1-gnat-3.14p/ada'
make[1]: *** [gnatmem] Error 2
make[1]: Leaving directory `/home/free_sw/gcc-2.8.1-gnat-3.14p'
make: *** [gnattools] Error 2



The function convert_addresses (from RH 6.2) appears to no longer be
apart of the binutils package in Red Hat 7.2.  The previous two errors
can be fairly easily worked-around, but I don't recall exactly what I
did to do that (in a previous build).


Having run into a non-trival issue (probably not the last) which has
been solved by ACT, I decided to appeal to c.l.a. to see if someone
might provide some assistance/guidance - instead of just blindly,
laboriously, slaying dead bugs that I reincarnated.



Ken

Re: GNAT 3.14p and Red Hat 7.2

[Dr. Michael Paus]

Ken Nelson schrieb:
> 
> GNAT 3.14p was released to run on GNU Linux (Red Hat 6.2).  Has anyone
> ported it to Red Hat 7.2?  If not, can someone from ACT comment on how
> much work this would be and the best way(s) to perform a port?

Just give it a try. I am using 3.14p on my Suse 7.3 without any problems
so far.

Michael

Re: GNAT 3.14p and Red Hat 7.2

[Mark Johnson]

Ken Nelson wrote:
> [snip]
Oh. Building gnat from source. I don't generally do that, but may still
be able to help...

> a-adaint.o: In function `__gnat_tmp_name':
> a-adaint.o(.text+0x42c): the use of `tmpnam' is dangerous, better use
> `mkstemp'
> g-os_lib.o: In function `gnat__os_lib__create_temp_file':
> g-os_lib.o(.text+0x2f1): the use of `mktemp' is dangerous, better use
> `mkstemp'
I have reported this particular problem to ACT several months ago - and
it was subsequently fixed.

> a-gmem.o: In function `__gnat_gmem_a2l_initialize':
> a-gmem.o(.text+0xc4): undefined reference to `convert_addresses'
> a-gmem.o: In function `__gnat_gmem_read_bt_frame':
> a-gmem.o(.text+0x20d): undefined reference to `convert_addresses'
convert_addresses is referenced by g-trasym.adb to assist in the
generation of the symbolic stack traceback (lookup file name & line
number from debug data). This should have been brought in by linking
libaddr2line.a  (-laddr2line). The copy on my system was in the binary
tar file from ACT (and not part of the binutils RPM) - for versions
3.14a, 3.15w, etc. Since you are building from source, it might not be
built correctly. I haven't looked at the binary for 3.14p, but it should
have the appropriate library you need. If not, use the stub version in
a-adaint.c as an interim fix.

  --Mark

Re: GNAT 3.14p and Red Hat 7.2

[Stephen Leake]

KennethNelson@attbi.com (Ken Nelson) writes:

><snip> 
> I have a working copy of GNAT 3.13p and gcc 2.8.1
> 
> 10. However, make CC=gcc CFLAGS="-O2" gnattools  produces:
> 
> <snip>> a-adaint.o: In function `__gnat_tmp_name':
> a-adaint.o(.text+0x42c): the use of `tmpnam' is dangerous, better use
> `mkstemp'
> g-os_lib.o: In function `gnat__os_lib__create_temp_file':
> g-os_lib.o(.text+0x2f1): the use of `mktemp' is dangerous, better use
> `mkstemp'

These are just warnings about potential security problems. They should
be ignored.

> a-gmem.o: In function `__gnat_gmem_a2l_initialize':
> a-gmem.o(.text+0xc4): undefined reference to `convert_addresses'
> a-gmem.o: In function `__gnat_gmem_read_bt_frame':
> a-gmem.o(.text+0x20d): undefined reference to `convert_addresses'
> make[2]: *** [../gnatmem] Error 1 make[2]: Leaving directory
> `/home/free_sw/gcc-2.8.1-gnat-3.14p/ada' make[1]: *** [gnatmem]
> Error 2 make[1]: Leaving directory
> `/home/free_sw/gcc-2.8.1-gnat-3.14p' make: *** [gnattools] Error 2

Just comment out 'gnatmem' in the makefile, so it doesn't get built.
You won't need it for anything

> The function convert_addresses (from RH 6.2) appears to no longer be
> apart of the binutils package in Red Hat 7.2. 

It's provided in a patch to binutils in the GNAT source distribution.

> The previous two errors can be fairly easily worked-around, but I
> don't recall exactly what I did to do that (in a previous build).

Just ignore them :).

-- 
-- Stephe

Re: GNAT 3.14p and Red Hat 7.2

[Florian Weimer]

Mark Johnson <mark_h_johnson@raytheon.com> writes:

> I have reported this particular problem to ACT several months ago - and
> it was subsequently fixed.

I can't tell anything about the internal ACT version, but the fix in
GNAT 5.0 introduces another problem (a buffer overflow).

Re: GNAT 3.14p and Red Hat 7.2

[Florian Weimer]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

>> <snip>> a-adaint.o: In function `__gnat_tmp_name':
>> a-adaint.o(.text+0x42c): the use of `tmpnam' is dangerous, better use
>> `mkstemp'
>> g-os_lib.o: In function `gnat__os_lib__create_temp_file':
>> g-os_lib.o(.text+0x2f1): the use of `mktemp' is dangerous, better use
>> `mkstemp'
>
> These are just warnings about potential security problems. They should
> be ignored.

The first warning is issued because the code *does* contain a security
problem (your Ada application will be affected only if it uses
temporary files, though). Ignoring it won't make it go away. ;-)

Re: GNAT 3.14p and Red Hat 7.2

[David C. Hoos, Sr.]

----- Original Message ----- 
From: "Florian Weimer" <fw@deneb.enyo.de>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: March 26, 2002 1:53 PM
Subject: Re: GNAT 3.14p and Red Hat 7.2


> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
> 
> >> <snip>> a-adaint.o: In function `__gnat_tmp_name':
> >> a-adaint.o(.text+0x42c): the use of `tmpnam' is dangerous, better use
> >> `mkstemp'
> >> g-os_lib.o: In function `gnat__os_lib__create_temp_file':
> >> g-os_lib.o(.text+0x2f1): the use of `mktemp' is dangerous, better use
> >> `mkstemp'
> >
> > These are just warnings about potential security problems. They should
> > be ignored.
> 
> The first warning is issued because the code *does* contain a security
> problem (your Ada application will be affected only if it uses
> temporary files, though). Ignoring it won't make it go away. ;-)

More correctly, one should say "your Ada application will be affected
only if it uses GNAT.OS_Lib.Create_Temp_File."

One can certainly safely use temporary files in Ada programs.

> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 
> 

Re: GNAT 3.14p and Red Hat 7.2

[Florian Weimer]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:

>> The first warning is issued because the code *does* contain a security
>> problem (your Ada application will be affected only if it uses
>> temporary files, though). Ignoring it won't make it go away. ;-)
>
> More correctly, one should say "your Ada application will be affected
> only if it uses GNAT.OS_Lib.Create_Temp_File."
>
> One can certainly safely use temporary files in Ada programs.

But not using the mechanism in A.8.2(4). :-/

Re: GNAT 3.14p and Red Hat 7.2

[Georg Bauhaus]

Florian Weimer <fw@deneb.enyo.de> wrote:
: "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:
: 
:>> The first warning is issued because the code *does* contain a security
:>> problem (your Ada application will be affected only if it uses
:>> temporary files, though). Ignoring it won't make it go away. ;-)
:>
:> More correctly, one should say "your Ada application will be affected
:> only if it uses GNAT.OS_Lib.Create_Temp_File."
:>
:> One can certainly safely use temporary files in Ada programs.
: 
: But not using the mechanism in A.8.2(4). :-/

I recall a discussion of OS security in the Minix book
by Tanenbaum, where he points out that you should not believe
in security because your system manual tells you some part
of the system has been secured. On the contrary, the mechanism
should be open to cracking attempts, to be tested.

On the surface, this seems unrelated, and mkstemp() (or whatever
its name is) is open to testing of all kinds.
But the mindset seems related, at least to me. If programmers feel 
they have written a secure program because they are told their
compiler doesn't use insecure OS facilities, I wouldn't, necessarily,
as a user of their program.  Proven security...?

Improved security due to the removal of one possible hole?
Let me argue in favour of documenting possible holes. 
If program writers learn to pay attention to the outcome
of the compilation process, and they must, once they now
even an Ada program doesn't just use RM virtuality,
they will care about what OS facilities operate behind the
scenes.

Who knows what will happen to a running Ada program if the
OS kernel supports modifying the hardware clock...
I don't, right know, but if my program depends on that
device, I will pay attention, and hope to find a note
somewhere near the Clock documentation.

- Georg

Re: GNAT 3.14p and Red Hat 7.2

[Florian Weimer]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> I recall a discussion of OS security in the Minix book
> by Tanenbaum, where he points out that you should not believe
> in security because your system manual tells you some part
> of the system has been secured. On the contrary, the mechanism
> should be open to cracking attempts, to be tested.

Did Tanenbaum really write that?  What strange way to think about
security!

We haven't got just manuals, we have also got source code.  Looking at
the source code is far more efficient than random black box testing
without vendor support.  I'm surprised how many vulnerabilities are
uncovered by more or less systematic black box testing, but such
testing can only show the presence of bugs, not their absence.

> Improved security due to the removal of one possible hole?

Yes, of course, and it's not a "possible hole", it's a typical /tmp
race condition.

> Let me argue in favour of documenting possible holes. 

This particular problem has been documented over and over again. In
fact, it is one of the most well-known security problems in
UNIX-centered code.

> If program writers learn to pay attention to the outcome
> of the compilation process, and they must, once they now
> even an Ada program doesn't just use RM virtuality,
> they will care about what OS facilities operate behind the
> scenes.

Well, I *do* care, that's why I complain about the problem!  But your
advice not to fix such problems and just document them is entirely
incomprehensible to me.

Re: GNAT 3.14p and Red Hat 7.2

[Georg Bauhaus]

Florian Weimer <fw@deneb.enyo.de> wrote:
: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
: 
:> I recall a discussion of OS security in the Minix book
:> by Tanenbaum, where he points out that you should not believe
:> in security because your system manual tells you some part
:> of the system has been secured. On the contrary, the mechanism
:> should be open to cracking attempts, to be tested.
: 
: Did Tanenbaum really write that?  What strange way to think about
: security!

Maybe I should try to state this more clearly. Some quotes:
`First, the system design should be public. Assuming that the intruders
do not know how the system works serves only to delude the designers.'

`Fifth, the protection mechanism should be ... built
into the lowest layers of the system. Trying to retrofit
security to an existing insecure system is nearly impossible.'

: We haven't got just manuals, we have also got source code.
yes, see above.

: Looking at
: the source code is far more efficient than random black box testing
: without vendor support.

Maybe, don't know the efficiency scale here,
but why look at OS source code in order to be free to
care less about null string file names, because the compiler
is smart enough to work around OS's race conditions?

I was trying to argue that while this may be "fixed", it might
support the false idea that Ada programs are safe by RM and
good OS aware compilers. That's a dangerous aproach in my view!

:  but such
: testing can only show the presence of bugs, not their absence.

Neither can the absence be shown to a degree that deserves the name
security. There is none, only protection (OS), trust (human), and
a good setup (both).

:> Improved security due to the removal of one possible hole?
: 
: Yes, of course, and it's not a "possible hole", it's a typical /tmp
: race condition.

So it is a typical hole, that's not a compliment for ___ {, ___}
(fill in here). (Important point. What is the intention
of forcing mkstemp()? Beeing able to say, "See, no GNU Ada program
introduces security problems by using race-condition OS facilities?")

: This particular problem has been documented over and over again. In
: fact, it is one of the most well-known security problems in
: UNIX-centered code.

So change UNIX. Don't change the look of its system calls.
See above, quote 2.

:   But your
: advice not to fix such problems and just document them is entirely
: incomprehensible to me.

I think an OS problem should not be fixed by a compiler,
introducing the possibility of a non-portable fix-me-once-more
problem, should there be another operating system with 
shared scratch space, and someone wants to adapt the compiler to
that system. (Again in an attempt to free programmers from having
to think about possible security holes introduced by their programs?)

And for programs that should run under high protection,
as opposed to an operating system that should be protected
from the vulnerabilities of its inherent race conditions
(mkstemp() is a _workaround_, since the originals are still there),
I would of course try to
make sure every external thing used by the program is in a
well known state, with an appropriate setup and good administration
e.g..

The qoutes can be found in both the Minix book and Modern OSs,
security chapters.

- georg
running Debian GNU/Linux most of the time.

Re: GNAT 3.14p and Red Hat 7.2

[Georg Bauhaus]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
: Maybe I should try to state this more clearly. Some quotes:
And maybe my previous post was a bit strong, ahum. happy holidays.
- georg
(but look at glibc's tmpfile() H)

Re: GNAT 3.14p and Red Hat 7.2

[Florian Weimer]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
> : Maybe I should try to state this more clearly. Some quotes:
> And maybe my previous post was a bit strong, ahum. happy holidays.
> - georg
> (but look at glibc's tmpfile() H)

An Ada temporary file requires a name, and tmpfile() creates an
unnamed file.

Re: GNAT 3.14p and Red Hat 7.2

[David C. Hoos, Sr.]

----- Original Message ----- 
From: "Florian Weimer" <fw@deneb.enyo.de>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: March 30, 2002 1:17 PM
Subject: Re: GNAT 3.14p and Red Hat 7.2


> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
> 
> > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
> > : Maybe I should try to state this more clearly. Some quotes:
> > And maybe my previous post was a bit strong, ahum. happy holidays.
> > - georg
> > (but look at glibc's tmpfile() H)
> 
> An Ada temporary file requires a name, and tmpfile() creates an
> unnamed file.

Where did you get the idea that an Ada temporary file requires a name?

There are only two mentions of temporary files in the LRM, viz.:

A.8.2 (4) A null string for Name specifies an external file that is
not accessible after the completion of the main program (a temporary
file). A null string for Form specifies the use of the default
options of the implementation for the external file.

A.8. (23) The exception Status_Error is propagated if the given file
is not open. The exception Use_Error is propagated if the associated
external file is a temporary file that cannot be opened by any name.

Thus, an Ada temporary file is also unnamed.

Respectfully,

David Hoos
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 
> 

Re: GNAT 3.14p and Red Hat 7.2

[Florian Weimer]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:

> Where did you get the idea that an Ada temporary file requires a
> name?

Oh, someone from ACT told it to me, and I didn't check it.

> A.8. (23) The exception Status_Error is propagated if the given file
> is not open. The exception Use_Error is propagated if the associated
> external file is a temporary file that cannot be opened by any name.

The GNAT standpoint seems to be, "our temporary files can be opened by
a name, that's why we never raise Use_Error".