Re: Runtime Error with gnat 3.10p

[Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk>]

Robert Dewar wrote:
> 
> <<Under Linux, the RM Annex D real-time task priorities can only be fully
> implemented on top of POSIX.1c threads if the process is running with
> root privileges. Otherwise, a malicious non-root process could lock-up
> the entire system by requesting FIFO_Queuing and going into an
> endless loop (in other words, you do not want full Annex D
> compliance for normal untrusted users on a multi-user system).
> >>
> 
> Annex D cannot  be blamed here. it is perfectly possible to implement
> full compliance with annex D without giving a proogram to seize the
> system in this manner. Annex D talks about relationship of tasks
> in your Ada program, not about their relation to other programs
> running on the same operating system.

Note the restriction "Under Linux," at the start of my statement.
Under Linux, with the "native" GNAT run-time system, every
Ada task is handeled by the kernel just like every other thread
and process running in the system. Therefore, Annex D is under
Linux (when GNAT's native RTS is used) interpreted as if the entire
Linux system were one single Ada system. If one Ada thread gets
a FIFO_Queuing scheduling policy assigned, then this means that the
rest of the system is at the mercy of one thread willing to release
the CPU after a reasonable time and not to go into an endless
loop. Therefore, when I wrote sched_setscheduler() in Linux 1.3,
I decided to let only root processes get the SCHED_FIFO and SCHED_RR
policies.

Question: The GNAT documentation says that only the FSU run-time
system passes all Annex D requirements, not the native run-time
system. The native GNAT run-time system seems to use Xavier Leroy's
LinuxThreads package, which implements POSIX.1c threads using the
Linux clone() system call that generates new processes with shared
address space, file descriptors, etc. What exactly is the reason
that the native RTS does not pass Annex D when the tests are executed?
I don't see why this should not go as long as the Ada program
was started as a root processes.

What would have to be fixed in the Linux kernel to make it an ideal
Ada runtime environment? Adding new system calls or extending the
semantics of existing ones is not a big problem. Linus Torvalds
usually integrates well-written kernel patches into the current
Linux 2.1.xxx developer version within 24 hours or so. It is very
easy under Linux to get a new feature that one requires implemented
in the kernel within a few days (which usually takes years on other
systems). Join the Linux kernel developer mailing list and let's
see to it that Linux 2.2 fullfils all the needs of an excellent
Ada environment.

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>