Some questions on QNX

Sebastian_Doeweling · December 1, 2002, 5:18pm

Hi.

I’m currently working on a seminar talk on QNX/Neutrino and got most
of the information I needed from the system architecture docs. Yet
there a some questions left, maybe there’s someone who could help
me:

Is there any authentication done when attaching to channels or can
threads do a kind of DOS attack by sending pulses over and over?
Are there any figures about Neutrino, i.e. kernel footprint, lines
of code, number of interface functions, percentage of assembler
code?
Is there a standard value for timeout when doing blocking IPC?

Thanx in advance,
Sebastian

Rennie_Allen2 · December 1, 2002, 7:54pm

Sebastian Doeweling wrote:

Is there a standard value for timeout when doing blocking IPC?

Don’t know the answers to the previous two questions, but the answer to
this is yes; there is a standard timeout, and it is infinity

Rennie

Chris_McKillop1 · December 1, 2002, 9:14pm

Rennie Allen <rgallen@attbi.com> wrote:

Sebastian Doeweling wrote:

Is there a standard value for timeout when doing blocking IPC?

Don’t know the answers to the previous two questions, but the answer to
this is yes; there is a standard timeout, and it is infinity >

However, you can use TimerTimeout() to unblock after a period of time.

chris

–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Igor_Kovalenko2 · December 2, 2002, 5:39am

“Sebastian Doeweling” <sebastiand@gmx.de> wrote in message
news:asdfqa$35o$1@inn.qnx.com…

Hi.

I’m currently working on a seminar talk on QNX/Neutrino and got most
of the information I needed from the system architecture docs. Yet
there a some questions left, maybe there’s someone who could help
me:

Is there any authentication done when attaching to channels or can

No.

threads do a kind of DOS attack by sending pulses over and over?

Anyone can send anything to anyone, so yes it is vulnerable to DOS attacks.

Are there any figures about Neutrino, i.e. kernel footprint, lines
of code, number of interface functions, percentage of assembler
code?

No official figures. The ukernel is said to be about 40K. It has about 40
kernel calls, everything else are library calls, usually translated to a
messages to the respective servers.

The ukernel is not available separately though, it is buried in the process
manager so the footprint will be more like 250 (depending on the
architecture). I don’t think there’s a sizeable portion of assembler code,
it would be tough to maintain over 5 platforms.

Is there a standard value for timeout when doing blocking IPC?

They can block indefinitely. Even signals won’t always unblock, depending on
the state of IPC transactions. There are kernel timeouts (TimerTimeout
function) but they are not armed atomically with the kernel call entrance,
so they can’t be considered reliable in the general case.

– igor

David_Gibbs1 · December 2, 2002, 5:15pm

Igor Kovalenko <kovalenko@attbi.com> wrote:

“Sebastian Doeweling” <> sebastiand@gmx.de> > wrote in message
news:asdfqa$35o$> 1@inn.qnx.com> …
Hi.

Is there any authentication done when attaching to channels or can

No.

threads do a kind of DOS attack by sending pulses over and over?

Anyone can send anything to anyone, so yes it is vulnerable to DOS attacks.

Not quite. The same verification is done for sending a pulse as would
be for sending a signal – so if you’re sending to a server that is
running as root, you must be root to send those pulses.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Igor_Kovalenko2 · December 3, 2002, 5:08am

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:asg4en$ei5$1@nntp.qnx.com…

Igor Kovalenko <> kovalenko@attbi.com> > wrote:
“Sebastian Doeweling” <> sebastiand@gmx.de> > wrote in message
news:asdfqa$35o$> 1@inn.qnx.com> …
Hi.

Is there any authentication done when attaching to channels or can

No.

threads do a kind of DOS attack by sending pulses over and over?

Anyone can send anything to anyone, so yes it is vulnerable to DOS
attacks.

Not quite. The same verification is done for sending a pulse as would
be for sending a signal – so if you’re sending to a server that is
running as root, you must be root to send those pulses.

True, but that does not apply to messages. As long as you know pid and
channel id, you can send anything to anyone. And the channel id is not hard
to guess by brute force, it is just a small integer usually…

One can use short kernel timeouts to avoid blocking for extended periods and
easily flood the whole system with messages that way.

If I was to do a DOS attack on QNX, there are simpler ways. Try this for
starter - it will bring the system on its knees, root or not.

#include <malloc.h>
int main(void)
{
while(1) malloc(4096);
}

Then of course replacing malloc() with fork() will be just as effective

– igor

David_Gibbs1 · December 3, 2002, 7:17pm

Igor Kovalenko <kovalenko@attbi.com> wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:asg4en$ei5$> 1@nntp.qnx.com> …
Hi.

Is there any authentication done when attaching to channels or can

No.

threads do a kind of DOS attack by sending pulses over and over?

Anyone can send anything to anyone, so yes it is vulnerable to DOS
attacks.

Not quite. The same verification is done for sending a pulse as would
be for sending a signal – so if you’re sending to a server that is
running as root, you must be root to send those pulses.

True, but that does not apply to messages. As long as you know pid and
channel id, you can send anything to anyone. And the channel id is not hard
to guess by brute force, it is just a small integer usually…

Yes, but the server can easily prevent a MsgSend() based DOS attack
by not replying to the messages. You call MsgReceive(), you don’t call
MsgReply/MsgError, and you’ve just held-off that attacker.

One can use short kernel timeouts to avoid blocking for extended periods and
easily flood the whole system with messages that way.

If the servers have requested unblock notification (which is default for
resource managers, and name_attach() channels), then this timeout is under
the control of the server, which can hold you off.

If I was to do a DOS attack on QNX, there are simpler ways. Try this for
starter - it will bring the system on its knees, root or not.

There are lots of ways.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Igor_Kovalenko2 · December 4, 2002, 5:49am

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:asj00c$98m$1@nntp.qnx.com…

Igor Kovalenko <> kovalenko@attbi.com> > wrote:
“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:asg4en$ei5$> 1@nntp.qnx.com> …
Hi.

True, but that does not apply to messages. As long as you know pid and
channel id, you can send anything to anyone. And the channel id is not
hard
to guess by brute force, it is just a small integer usually…

Yes, but the server can easily prevent a MsgSend() based DOS attack
by not replying to the messages. You call MsgReceive(), you don’t call
MsgReply/MsgError, and you’ve just held-off that attacker.

One can use short kernel timeouts to avoid blocking for extended periods
and
easily flood the whole system with messages that way.

If the servers have requested unblock notification (which is default for
resource managers, and name_attach() channels), then this timeout is under
the control of the server, which can hold you off.

Are you suggesting that all shipped QNX resource managers do hold off DOS
attackers? That is the whole point of this discussion. Of course there are
ways to implement security at the application level, but that is not good
enough. First you get code duplication between all clients and servers,
second you never know if that or this serves actually implements it at all.

If I was to do a DOS attack on QNX, there are simpler ways. Try this for
starter - it will bring the system on its knees, root or not.

There are lots of ways.

No there aren’t, if proper thought is given to the design. The malloc() bomb
can be easily prevented by runtime limits on memory (if they worked, of
course). The fork() bomb is harder, but also can be dealt with if there was
a runtime limit effective for chilren too…

– igor

Armin_Steinhoff1 · December 4, 2002, 11:29am

Igor Kovalenko wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:asj00c$98m$> 1@nntp.qnx.com> …

Igor Kovalenko <> kovalenko@attbi.com> > wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:asg4en$ei5$> 1@nntp.qnx.com> …

Hi.

True, but that does not apply to messages. As long as you know pid and
channel id, you can send anything to anyone. And the channel id is not

hard

to guess by brute force, it is just a small integer usually…

Yes, but the server can easily prevent a MsgSend() based DOS attack
by not replying to the messages. You call MsgReceive(), you don’t call
MsgReply/MsgError, and you’ve just held-off that attacker.

One can use short kernel timeouts to avoid blocking for extended periods

and

easily flood the whole system with messages that way.

If the servers have requested unblock notification (which is default for
resource managers, and name_attach() channels), then this timeout is under
the control of the server, which can hold you off.

Are you suggesting that all shipped QNX resource managers do hold off DOS
attackers? That is the whole point of this discussion. Of course there are
ways to implement security at the application level, but that is not good
enough. First you get code duplication between all clients and servers,
second you never know if that or this serves actually implements it at all.

If I was to do a DOS attack on QNX, there are simpler ways. Try this for
starter - it will bring the system on its knees, root or not.

There are lots of ways.

No there aren’t, if proper thought is given to the design. The malloc() bomb
can be easily prevented by runtime limits on memory (if they worked, of
course). The fork() bomb is harder, but also can be dealt with if there was
a runtime limit effective for chilren too…

An other ‘bomb’ is running a process at a high FIFO prioriy in a simple

‘while(1);’ loop

Armin

– igor

Armin_Steinhoff1 · December 4, 2002, 11:37am

Igor Kovalenko wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:asj00c$98m$> 1@nntp.qnx.com> …

Igor Kovalenko <> kovalenko@attbi.com> > wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:asg4en$ei5$> 1@nntp.qnx.com> …

Hi.

True, but that does not apply to messages. As long as you know pid and
channel id, you can send anything to anyone. And the channel id is not

hard

to guess by brute force, it is just a small integer usually…

Yes, but the server can easily prevent a MsgSend() based DOS attack
by not replying to the messages. You call MsgReceive(), you don’t call
MsgReply/MsgError, and you’ve just held-off that attacker.

One can use short kernel timeouts to avoid blocking for extended periods

and

easily flood the whole system with messages that way.

If the servers have requested unblock notification (which is default for
resource managers, and name_attach() channels), then this timeout is under
the control of the server, which can hold you off.

Are you suggesting that all shipped QNX resource managers do hold off DOS
attackers? That is the whole point of this discussion. Of course there are
ways to implement security at the application level, but that is not good
enough. First you get code duplication between all clients and servers,
second you never know if that or this serves actually implements it at all.

If I was to do a DOS attack on QNX, there are simpler ways. Try this for
starter - it will bring the system on its knees, root or not.

There are lots of ways.

No there aren’t, if proper thought is given to the design. The malloc() bomb
can be easily prevented by runtime limits on memory (if they worked, of
course).

Not proper handling of memory constrains is really bad … because this
can happen if a bunch of applications are running at the same time.

So how can we name QNX a reliable system if these simple aspects are not
handled in a secure way ??

Armin

The fork() bomb is harder, but also can be dealt with if there was
a runtime limit effective for chilren too…

– igor

Ian_Zagorskih1 · December 4, 2002, 12:21pm

“Armin Steinhoff” <a-steinhoff@web.de> wrote in message
news:asko92$a4n$1@inn.qnx.com…

Igor Kovalenko wrote:
“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:asj00c$98m$> 1@nntp.qnx.com> …

Igor Kovalenko <> kovalenko@attbi.com> > wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:asg4en$ei5$> 1@nntp.qnx.com> …

Hi.

True, but that does not apply to messages. As long as you know pid and
channel id, you can send anything to anyone. And the channel id is not

hard

to guess by brute force, it is just a small integer usually…

Yes, but the server can easily prevent a MsgSend() based DOS attack
by not replying to the messages. You call MsgReceive(), you don’t call
MsgReply/MsgError, and you’ve just held-off that attacker.

One can use short kernel timeouts to avoid blocking for extended
periods

and

easily flood the whole system with messages that way.

If the servers have requested unblock notification (which is default for
resource managers, and name_attach() channels), then this timeout is
under
the control of the server, which can hold you off.

Are you suggesting that all shipped QNX resource managers do hold off
DOS
attackers? That is the whole point of this discussion. Of course there
are
ways to implement security at the application level, but that is not
good
enough. First you get code duplication between all clients and servers,
second you never know if that or this serves actually implements it at
all.

If I was to do a DOS attack on QNX, there are simpler ways. Try this
for
starter - it will bring the system on its knees, root or not.

There are lots of ways.

No there aren’t, if proper thought is given to the design. The malloc()
bomb
can be easily prevented by runtime limits on memory (if they worked, of
course). The fork() bomb is harder, but also can be dealt with if there
was
a runtime limit effective for chilren too…

An other ‘bomb’ is running a process at a high FIFO prioriy in a simple

‘while(1);’ loop >

Hmm… AFAIU it’s not allowed to raise process priority above some default
user level for non-root applications. So this dosn’t work. At least [even]
in QNX4.

An another perfect bomb is just to destroy GDT. But who will allow you this
as far as you’r not a root ?

When you’r a root all bombs are perfect, even which are very trivial.

// wbr

Armin_Steinhoff1 · December 4, 2002, 2:01pm

Ian Zagorskih wrote:

“Armin Steinhoff” <> a-steinhoff@web.de> > wrote in message
[ clip …]

An other ‘bomb’ is running a process at a high FIFO prioriy in a simple

‘while(1);’ loop >

Hmm… AFAIU it’s not allowed to raise process priority above some default
user level for non-root applications.

Not allowed ? Tell this to the hackers

So this dosn’t work. At least [even] in QNX4.

It works with QNX4 and QNX6 … even if the highest priority has a limit
in non-root applications [ QNX6 → max prio=32 ].

A lot of system threads are running at a prio of less than 30
(why??) … so its easy to exclude them from the CPU by a normal user
application =:-/ (only the main thread of procnto works at 63 … )

Armin

An another perfect bomb is just to destroy GDT. But who will allow you this
as far as you’r not a root ?

When you’r a root all bombs are perfect, even which are very trivial.

// wbr

David_Gibbs1 · December 4, 2002, 11:09pm

Igor Kovalenko <kovalenko@attbi.com> wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:asj00c$98m$> 1@nntp.qnx.com> …
Igor Kovalenko <> kovalenko@attbi.com> > wrote:
“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:asg4en$ei5$> 1@nntp.qnx.com> …
Hi.

True, but that does not apply to messages. As long as you know pid and
channel id, you can send anything to anyone. And the channel id is not
hard
to guess by brute force, it is just a small integer usually…

Yes, but the server can easily prevent a MsgSend() based DOS attack
by not replying to the messages. You call MsgReceive(), you don’t call
MsgReply/MsgError, and you’ve just held-off that attacker.

One can use short kernel timeouts to avoid blocking for extended periods
and
easily flood the whole system with messages that way.

If the servers have requested unblock notification (which is default for
resource managers, and name_attach() channels), then this timeout is under
the control of the server, which can hold you off.

Are you suggesting that all shipped QNX resource managers do hold off DOS
attackers? That is the whole point of this discussion.

I am making no such generic point.

Somebody said anybody could flood a server with pulses. I said no, given
that the servers are resource managers they’re probably running as root,
therefor, you must be root to flood them with pulses, therefor not just
“anybody” can do it.

Then somebody said you could flood them with MsgSend() calls by quickly
timeing them out before the server could respond.

I said that, no, the S/R/R architecture with UNBLOCK handling on the
server side inherently throttled this type of attack. Now, it doesn’t
remove this type of attack, you could hit the server with a message,
then unblock (which is a new pulse), then a new request…but the
inherent throttling is in that you can not send that new request
until the previous unblock is processed. From my understanding of
DOS attacks, this inherent throttling would make that particular
attack not be a DOS attack.

If I was to do a DOS attack on QNX, there are simpler ways. Try this for
starter - it will bring the system on its knees, root or not.

In fact, I said:

There are lots of ways.

Meaning, there are lots of ways to bring a QNX system to its knees.

So, I wasn’t generically denying that there are DOS attacks against
QNX. Just that those particular avenues aren’t.

A root process could spew pulses at a server, no problem. In fact,
I think it could send “UNBLOCK” pulses for random rcvids. (I don’t
think MsgSendPulse() makes sure the pulses with negative codes
aren’t sent.)

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

David_Gibbs1 · December 4, 2002, 11:12pm

Armin Steinhoff <a-steinhoff@web.de> wrote:

A lot of system threads are running at a prio of less than 30
(why??) … so its easy to exclude them from the CPU by a normal user
application =:-/ (only the main thread of procnto works at 63 … )

Why?
They float to the priority of the thread that sent to them, or who’s
request they are servicing.

So, if you run something READY at priority 30, then someone at priority
32 makes a request, the proc thread that services that request will run
at priority 32, and you won’t be pre-empted.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Igor_Kovalenko2 · December 5, 2002, 8:38am

FYI Armin, runtime limit on CPU usage does work already (you get hit by
SIGXCPU). And so does limit on opened file descriptors. The memory limits do
not work (and don’t return an error either).

– igor

“Armin Steinhoff” <a-steinhoff@web.de> wrote in message
news:asl177$jor$1@inn.qnx.com…

Ian Zagorskih wrote:
“Armin Steinhoff” <> a-steinhoff@web.de> > wrote in message
[ clip …]

An other ‘bomb’ is running a process at a high FIFO prioriy in a simple

‘while(1);’ loop >

Hmm… AFAIU it’s not allowed to raise process priority above some
default
user level for non-root applications.

Not allowed ? Tell this to the hackers >

So this dosn’t work. At least [even] in QNX4.

It works with QNX4 and QNX6 … even if the highest priority has a limit
in non-root applications [ QNX6 → max prio=32 ].

A lot of system threads are running at a prio of less than 30
(why??) … so its easy to exclude them from the CPU by a normal user
application =:-/ (only the main thread of procnto works at 63 … )

Armin

An another perfect bomb is just to destroy GDT. But who will allow you
this
as far as you’r not a root ?

When you’r a root all bombs are perfect, even which are very trivial.

// wbr
\

Armin_Steinhoff1 · December 5, 2002, 10:32am

Igor Kovalenko wrote:

FYI Armin, runtime limit on CPU usage does work already

Interesting … where is it documented?

(you get hit by SIGXCPU).

As a hacker I would use SIG_IGN … as a normal user I would use it
to take some more positive actions.

In general the assigned priorities of all system tasks seems very
similar to the scheme used for QNX4.

Is this assignment static as for QNX4?

And so does limit on opened file descriptors.

That’s trivial … what about SGXFSZ ?

The memory limits do not work (and don’t return an error either).

Yes … and this is realy critical.

Regards

Armin

– igor

“Armin Steinhoff” <> a-steinhoff@web.de> > wrote in message
news:asl177$jor$> 1@inn.qnx.com> …

Ian Zagorskih wrote:

“Armin Steinhoff” <> a-steinhoff@web.de> > wrote in message

[ clip …]

An other ‘bomb’ is running a process at a high FIFO prioriy in a simple

‘while(1);’ loop >

Hmm… AFAIU it’s not allowed to raise process priority above some

default

user level for non-root applications.

Not allowed ? Tell this to the hackers >

So this dosn’t work. At least [even] in QNX4.

It works with QNX4 and QNX6 … even if the highest priority has a limit
in non-root applications [ QNX6 → max prio=32 ].

A lot of system threads are running at a prio of less than 30
(why??) … so its easy to exclude them from the CPU by a normal user
application =:-/ (only the main thread of procnto works at 63 … )

Armin

An another perfect bomb is just to destroy GDT. But who will allow you

this

as far as you’r not a root ?

When you’r a root all bombs are perfect, even which are very trivial.

// wbr

\

Armin_Steinhoff1 · December 5, 2002, 10:59am

David Gibbs wrote:

Armin Steinhoff <> a-steinhoff@web.de> > wrote:

A lot of system threads are running at a prio of less than 30
(why??) … so its easy to exclude them from the CPU by a normal user
application =:-/ (only the main thread of procnto works at 63 … )

Why?
They float to the priority of the thread that sent to them, or who’s
request they are servicing.

OK … I tried to check it out, but the print out of process flags
returned by pidin aren’t documented.

So, if you run something READY at priority 30, then someone at priority
32 makes a request, the proc thread that services that request will run
at priority 32, and you won’t be pre-empted.

OK … this works only if the other process talks to the same service
task or thread. But with a multi threaded resource manager your task
( that means your active resource manager thread) will be pre-empted.

If a resource manager has to handle critical time contrains at hardware
level it wouldn’t be a good idea to run it with a floating priority.

So just a big question mark behind that usage of floating priorities in
that context …

Regards

Armin

Xiaodan_Tang1 · December 5, 2002, 3:41pm

Armin Steinhoff <a-steinhoff@web.de> wrote in message
news:asnath$98t$1@inn.qnx.com…

David Gibbs wrote:
Armin Steinhoff <> a-steinhoff@web.de> > wrote:

A lot of system threads are running at a prio of less than 30
(why??) … so its easy to exclude them from the CPU by a normal user
application =:-/ (only the main thread of procnto works at 63 … )

Why?
They float to the priority of the thread that sent to them, or who’s
request they are servicing.

OK … I tried to check it out, but the print out of process flags
returned by pidin aren’t documented.

So, if you run something READY at priority 30, then someone at priority
32 makes a request, the proc thread that services that request will run
at priority 32, and you won’t be pre-empted.

OK … this works only if the other process talks to the same service
task or thread. But with a multi threaded resource manager your task
( that means your active resource manager thread) will be pre-empted.

If a resource manager has to handle critical time contrains at hardware
level it wouldn’t be a good idea to run it with a floating priority.

So just a big question mark behind that usage of floating priorities in
that context …

I have a felling that you have no clue what is a “priority inversion” and
why/how floating priorities is important. There is plenty of discussiones
on the network for this topic. Among those the “Mars Pathfinder” story
probably is the famous one.

http://research.microsoft.com/~mbj/Mars_Pathfinder/Priority_Inversion.html
http://research.microsoft.com/~mbj/Mars_Pathfinder/Mars_Pathfinder.html

Don’t get me wrong, I am not saying “resource manager HAS to
use floating priority”. It exist as a flag (that the resource manager
programmer
could control) for a reason.

-xtang

Armin_Steinhoff1 · December 5, 2002, 4:56pm

Xiaodan Tang wrote:

Armin Steinhoff <> a-steinhoff@web.de> > wrote in message
news:asnath$98t$> 1@inn.qnx.com> …

David Gibbs wrote:
Armin Steinhoff <> a-steinhoff@web.de> > wrote:
A lot of system threads are running at a prio of less than 30
(why??) … so its easy to exclude them from the CPU by a normal user
application =:-/ (only the main thread of procnto works at 63 … )
Why?
They float to the priority of the thread that sent to them, or who’s
request they are servicing.

OK … I tried to check it out, but the print out of process flags
returned by pidin aren’t documented.

So, if you run something READY at priority 30, then someone at priority
32 makes a request, the proc thread that services that request will run
at priority 32, and you won’t be pre-empted.

OK … this works only if the other process talks to the same service
task or thread. But with a multi threaded resource manager your task
( that means your active resource manager thread) will be pre-empted.

If a resource manager has to handle critical time contrains at hardware
level it wouldn’t be a good idea to run it with a floating priority.

So just a big question mark behind that usage of floating priorities in
that context …
^^^^^^^^^^^^^

I have a felling that you have no clue what is a “priority inversion” and
why/how floating priorities is important.

Sorry … you have simply a wrong feeling

There is plenty of discussiones
on the network for this topic. Among those the “Mars Pathfinder” story
probably is the famous one.

http://research.microsoft.com/~mbj/Mars_Pathfinder/Priority_Inversion.html
http://research.microsoft.com/~mbj/Mars_Pathfinder/Mars_Pathfinder.html

Don’t get me wrong, I am not saying “resource manager HAS to
use floating priority”.

Yes, I know … you have some kind of feeling

I said:

If a resource manager has to handle critical time contrains at
hardware level it wouldn’t be a good idea to run it with a floating
priority.

… end this is mostly the case when we deal with resource managers of
the (core) system.

It exist as a flag (that the resource manager
programmer could control) for a reason.

Is there a documentation of the process flags? (QNX4 has it …)

Armin

-xtang

David_Gibbs1 · December 5, 2002, 6:35pm

Armin Steinhoff <a-steinhoff@web.de> wrote:

David Gibbs wrote:
Armin Steinhoff <> a-steinhoff@web.de> > wrote:

A lot of system threads are running at a prio of less than 30
(why??) … so its easy to exclude them from the CPU by a normal user
application =:-/ (only the main thread of procnto works at 63 … )

Why?
They float to the priority of the thread that sent to them, or who’s
request they are servicing.

OK … I tried to check it out, but the print out of process flags
returned by pidin aren’t documented.

It isn’t a process flag, as in QNX4, it is a channel flag.

Check docs for ChannelCreate() and _NTO_CHF_PRIORITY_FIXED is, I think,
the flag to disable this behaviour.

So, if you run something READY at priority 30, then someone at priority
32 makes a request, the proc thread that services that request will run
at priority 32, and you won’t be pre-empted.

OK … this works only if the other process talks to the same service
task or thread. But with a multi threaded resource manager your task
( that means your active resource manager thread) will be pre-empted.

Whatever thread in the resource manager is chosen to “receive” that
request will run at the priority of the requesting process.

If you make all your real-time important task run above priority 30,
then they, and all servers they make requests to, will run at that
priority to service the request.

Note: most embedded and realtime systems do not have an environment
where people can compile or run arbitrary programs.

If a resource manager has to handle critical time contrains at hardware
level it wouldn’t be a good idea to run it with a floating priority.

Depends on how you structure things… usually hardware constraints mean
you’re dealing with interrupts. Two main choices here:
– hw thread uses InterruptWait(), runs at high priority, doesn’t receive
messages, so never floats in priority
– isr/event delivered is a pulse, with a high priority (pulses also carry
priority information) then the thread receiving the hardware pulse will
float to the (high) priority specified in the pulse

So just a big question mark behind that usage of floating priorities in
that context …

– can be (and often is) avoided in that situation

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.