From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,93db2bcd4637d4fc X-Google-Attributes: gid103376,public From: Markus Kuhn Subject: Re: Runtime Error with gnat 3.10p Date: 1998/05/28 Message-ID: <356D2E21.3FBF7BBE@cl.cam.ac.uk>#1/1 X-Deja-AN: 357245636 Content-Transfer-Encoding: 7bit References: <6kel87$ic7$1@polo.advicom.net> <356AF4B7.5EBF8617@cl.cam.ac.uk> Content-Type: text/plain; charset=us-ascii Organization: Cambridge University, Computer Laboratory Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-05-28T00:00:00+00:00 List-Id: Robert Dewar wrote: > > < 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: