Runtime Error with gnat 3.10p

Runtime Error with gnat 3.10p

[Andreas Jungmaier]

Hello all,

does anyone have an idea what the following little message is
about :
Failed Runtime Assertion : GNULLI failure---Set_Priority    

Note that this showed up after executing a compiled Ada program
containing several tasks (instantiated task types)
This is on RedHat-Linux. Could this have to do with the thread
libs coming with gnat ? 
Any help appreciated,

Andreas

-------------------------------------------------------------------------
Andreas Jungmaier  		ajung@teisa.unican.es
-------------------------------------------------------------------------

Re: Runtime Error with gnat 3.10p

[David C. Hoos, Sr.]

Andreas Jungmaier wrote in message ...
>Hello all,
>
>does anyone have an idea what the following little message is
>about :
>Failed Runtime Assertion : GNULLI failure---Set_Priority
>
>Note that this showed up after executing a compiled Ada program
>containing several tasks (instantiated task types)
>This is on RedHat-Linux. Could this have to do with the thread
>libs coming with gnat ?
Yes, it does.
One of the runtimes requires root privileges to do tasking while the
other does not (I forget which is which).

Take a look at the instructions from gnat for installation, and switch
the symbolic link to point to the other runtime, and re-link your
program.  Otherwise, run as root, or with root as the owner of the
executable file, and the setuid/and or setgid permission bits set.

If you chmown the executable file to be owned by root, then
chmod 6755 <executable-filename>, the executable runs with root
privileges.

Be aware, however, that such programs can do all of the things
the superuser can do, so in some contexts this may not be allowed
to be done by an ordinary user.

David C. Hoos, Sr.

Re: Runtime Error with gnat 3.10p

[Simon Wright]

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

> Andreas Jungmaier wrote in message ...
> >Hello all,
> >
> >does anyone have an idea what the following little message is
> >about :
> >Failed Runtime Assertion : GNULLI failure---Set_Priority
> >
> >Note that this showed up after executing a compiled Ada program
> >containing several tasks (instantiated task types)
> >This is on RedHat-Linux. Could this have to do with the thread
> >libs coming with gnat ?
> Yes, it does.
> One of the runtimes requires root privileges to do tasking while the
> other does not (I forget which is which).

Actually, the native threads requires root privileges to do *Annex D
tasking* (as noted by Markus Kuhn).

The relevant code in s-taprop.adb (3.11a1) is

   procedure Set_Priority (T : Task_ID; Prio : System.Any_Priority) is
      Result : Interfaces.C.int;
      Param  : aliased struct_sched_param;

   begin
      T.LL.Current_Priority := Interfaces.C.int (Prio);
      Param.sched_priority := Interfaces.C.int (Prio);

      Result := pthread_setschedparam (T.LL.Thread, SCHED_FIFO, Param'Access);
      pragma Assert (Result = 0
        or else Shutdown ("GNULLI failure---Set_Priority"));

   end Set_Priority;

You would have thought this would result in an error for non-root
users, cos (libpthread-0.71) pthread_setschedparam() calls
__sched_setscheduler(), which is a system call not defined in libc5,
but is in (linux/kernel/sched.c 2.0.33) which says

	if ((policy == SCHED_FIFO || policy == SCHED_RR) && !suser())
		return -EPERM;

but here it seems to work just fine. Hmm. Perhaps when I get round to
upgrading to glibc ...

Re: Runtime Error with gnat 3.10p

[Markus Kuhn]

David C. Hoos, Sr. wrote:
> >does anyone have an idea what the following little message is about :
> >Failed Runtime Assertion : GNULLI failure---Set_Priority
> >
> >Note that this showed up after executing a compiled Ada program
> >containing several tasks (instantiated task types)
> >This is on RedHat-Linux.

> One of the runtimes requires root privileges to do tasking while the
> other does not (I forget which is which).

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).

Make sure you use the rts-fsu and not the rts-native run-time
library system, i.e. set the links in the gcc-lib/i386-linux/2.7.2.1/
subdirectory accordingly as described in the gnat install
documentation, unless you work on a special time-critical
application.

See also "man 2 sched_setscheduler" for the underlying C system call
and its restrictions.

Markus
(who wrote sched_setscheduler() back in the Linux 1.3 kernel :)

ftp://ftp.informatik.uni-erlangen.de/local/cip/mskuhn/misc/linux-posix.1b

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

Re: Runtime Error with gnat 3.10p

[Robert Dewar]

<<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 runningf
on the same operating system.

Re: Runtime Error with gnat 3.10p

[Larry Kilgallen]

In article <dewar.896294071@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> <<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 runningf
> on the same operating system.

The phrase "Under Linux" would seem to have exonerated Annex D by
implying there existed one or more other operating systems where
reasonable implementation on top of POSIX.1c threads was possible.

Larry Kilgallen

Re: Runtime Error with gnat 3.10p

[Andi Kleen]

kilgallen@eisner.decus.org (Larry Kilgallen) writes:

> > 
> > 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 runningf
> > on the same operating system.
> 
> The phrase "Under Linux" would seem to have exonerated Annex D by
> implying there existed one or more other operating systems where
> reasonable implementation on top of POSIX.1c threads was possible.

Of course it is possible to implement it under Linux without requiring
privileges too, just not with the standard, unmodified LinuxThreads
package. There are several userspace threads packages available (I
think the GNAT runtime has its own too) that work in a single process
context and don't need root for anything. Of course they all don't
scale to multiple CPUs on SMP machines.

-Andi

Re: Runtime Error with gnat 3.10p

[Markus Kuhn]

Andi Kleen wrote:
> Of course it is possible to implement it under Linux without requiring
> privileges too, just not with the standard, unmodified LinuxThreads
> package. There are several userspace threads packages available (I
> think the GNAT runtime has its own too) that work in a single process
> context and don't need root for anything. Of course they all don't
> scale to multiple CPUs on SMP machines.

This keeps me thinking: Can we extend the Linux kernel
such that SCHED_FIFO and SCHED_RR are also available to non-root
processes at static priority 0 such that SCHED_OTHER processes
can still preempt SCHED_FIFO and system lockup is prevented?

At the moment, Linux has a static priority system with priority
levels from 0 to 99. All normal (non-realtime) Linux processes
run with the SCHED_OTHER scheduler policy under the lowest possible
priority level 0. The SCHED_RR and SCHED_FIFO (using the POSIX.1c
terminology here) run under static priorities 1 to 99. This
means that with SCHED_RR and SCHED_FIFO, you have guaranteed
deterministic scheduling behavior, all normal processes will
always have a lower priority and never interfer. The classic
Unix dynamic priorities, nice levels, etc. only organize
scheduling within this static priority 0 of the SCHED_OTHER
policy.

The original purpose of the real-time scheduler under Linux was
to provide for time-critical hardware control software to have a
guaranteed way of not being interfered by normal system processes
such as the X and mail server.

May be, we can extend the Linux scheduler easily to allow SCHED_RR
and SCHED_FIFO policies also to be used at a static priority 0.
The semantic would then be that with static priority 0, a
SCHED_FIFO process will never be preempted by another SCHED_FIFO
or SCHED_RR process, but it can very well still be preempted by a
SCHED_OTHER (i.e., normal) process. This way, we preserve the
execution order of threads that have only SCHED_FIFO and
SCHED_RR policies within this thread community, but the execution
of other SCHED_OTHER threads and processes will not be affected.
Therefore, SCHED_RR and SCHED_FIFO can be made available at
static priority 0 also to non-root users.

Is this the missing bit that is necessary to give the GNAT native
RTS the ability to fully implement Annex D as a non-root process
under Linux?

Is there any real application need for such a feature (beyond the
ability to cheat around the Annex D formal requirements in
conformance test suites)? If yes, then I'll have another look
at the Linux scheduler whether there is an efficient extention
possible.

The nice thing about the Linux kernel is that problems can easily
be fixed within a few days. You do not have to wait 4 years for
the next release like with Microsoft systems. Use the source, Luke!

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/>

Re: Runtime Error with gnat 3.10p

[Andi Kleen]

Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> writes:

> Andi Kleen wrote:
> > Of course it is possible to implement it under Linux without requiring
> > privileges too, just not with the standard, unmodified LinuxThreads
> > package. There are several userspace threads packages available (I
> > think the GNAT runtime has its own too) that work in a single process
> > context and don't need root for anything. Of course they all don't
> > scale to multiple CPUs on SMP machines.
> 
> This keeps me thinking: Can we extend the Linux kernel
> such that SCHED_FIFO and SCHED_RR are also available to non-root
> processes at static priority 0 such that SCHED_OTHER processes
> can still preempt SCHED_FIFO and system lockup is prevented?

Yes, with "process groups" (or something like the "gang scheduler"
used in several commercial Unixes) which allows to assign priorities
relative to a process group. For example the tree scheduling algorithm
used in Andy Valencia's VSTA OS would allow that [has anyone ported
Gnat to Vsta BTW?]. 

The problem is that it all adds overhead, one of the virtues of Linux 
is that it has very fast context switches and a low overhead scheduler.
 
> May be, we can extend the Linux scheduler easily to allow SCHED_RR
> and SCHED_FIFO policies also to be used at a static priority 0.
> The semantic would then be that with static priority 0, a
> SCHED_FIFO process will never be preempted by another SCHED_FIFO
> or SCHED_RR process, but it can very well still be preempted by a
> SCHED_OTHER (i.e., normal) process. This way, we preserve the
> execution order of threads that have only SCHED_FIFO and
> SCHED_RR policies within this thread community, but the execution
> of other SCHED_OTHER threads and processes will not be affected.
> Therefore, SCHED_RR and SCHED_FIFO can be made available at
> static priority 0 also to non-root users.

There is a patch floating around to implement the QNX scheduling
algorithm on Linux [see http://www.linuxhq.com/patch/20-p0768.html,
there is a equivalent patch for 2.1 somewhere too]. I think what you
propose would be rather easy to implement with that code.

> Is there any real application need for such a feature (beyond the
> ability to cheat around the Annex D formal requirements in
> conformance test suites)? If yes, then I'll have another look
> at the Linux scheduler whether there is an efficient extention
> possible.

I assume that other thread applications could benefit from it too. On the other
hand it'll be difficult to get it through Torvalds - the current scheduler
seems to have a very nice combination of low overhead and scalability, it
might be difficult to add features without destroying that balance.

-Andi

Re: Runtime Error with gnat 3.10p

[Markus Kuhn]

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/>

Re: Runtime Error with gnat 3.10p

[CHARLET Arnaud]

Markus Kuhn (Markus.Kuhn@cl.cam.ac.uk) wrote:
: 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.

Two things are missing with Linuxthreads to get full annex D compliance.
The first one is ceiling locking (e.g pthread_mutexattr_setprotocol),
but this is not a blocking issue since the required effect can be
achieved in the GNAT run time (but still, I'd feel more comfortable
if LinuxThreads could perform ceiling locking). Note that the current
version of GNAT for Linux has this priority ceiling emulation.

The second one is that the linux scheduler doesn't put a process at the
*head* of the ready queue when it lowers its priority.

The following patch against sched.c is required (I didn't have the time
to send an e-mail to Linus yet, but feel free to forward this message
if you want, this is what GPL is about after all):

*** sched.c.old	Fri Jan 23 19:36:39 1998
--- sched.c	Fri Jan 23 20:51:07 1998
***************
*** 194,199 ****
--- 194,213 ----
  	prev->next_run = p;
  }
  
+ static inline void move_first_runqueue(struct task_struct * p)
+ {
+ 	struct task_struct *next = p->next_run;
+ 	struct task_struct *prev = p->prev_run;
+ 
+ 	/* remove from list */
+ 	next->prev_run = prev;
+ 	prev->next_run = next;
+ 	/* add to the head of the list */
+ 	p->prev_run = &init_task;
+ 	(p->next_run = init_task.next_run)->prev_run = p;
+ 	init_task.next_run = p;
+ }
+ 
  /*
   * Wake up a process. Put it on the run-queue if it's not
   * already there.  The "current" process is always on the
***************
*** 1451,1456 ****
--- 1465,1471 ----
  	int error;
  	struct sched_param lp;
  	struct task_struct *p;
+ 	int prev_prio;
  
  	if (!param || pid < 0)
  		return -EINVAL;
***************
*** 1485,1495 ****
  	    !suser())
  		return -EPERM;
  
  	p->policy = policy;
  	p->rt_priority = lp.sched_priority;
  	cli();
! 	if (p->next_run)
! 		move_last_runqueue(p);
  	sti();
  	need_resched = 1;
  	return 0;
--- 1500,1516 ----
  	    !suser())
  		return -EPERM;
  
+         prev_prio = p->rt_priority;
  	p->policy = policy;
  	p->rt_priority = lp.sched_priority;
  	cli();
! 	if (p->next_run) {
! 		if ((policy == SCHED_FIFO || policy == SCHED_RR) &&
! 		    lp.sched_priority < prev_prio)
! 			move_first_runqueue(p);
! 		else
! 			move_last_runqueue(p);
! 	}
  	sti();
  	need_resched = 1;
  	return 0;

Arno

--
Arnaud Charlet   <charlet@gnat.com>