This chapter includes:
By default, anyone on the system can add partitions and modify their attributes. We recommend that you use the
command to SchedCtl(), or the
command to specify the level of security that suits your system.
This following list shows the main security options, in increasing order of security (the aps command and the corresponding
- none or the SCHED_APS_SEC_OFF flag
- Anyone on the system can add partitions and modify their attributes.
- basic or the SCHED_APS_SEC_BASIC flag
- Only the root in the System partition can change the overall
scheduling parameters and set critical budgets.
- flexible or the SCHED_APS_SEC_FLEXIBLE flag
- Only the root in the System partition can change scheduling
parameters or change critical budgets.
However, the root running in any partition can create subpartitions,
join threads into its own subpartitions and modify subpartitions.
This lets applications create their own local subpartitions out of
their own budgets. The percentage for budgets must not be zero.
- recommended or the SCHED_APS_SEC_RECOMMENDED flag
- Only the root from the System partition can create partitions
or change parameters. This arranges a 2-level hierarchy of partitions: the System partition
and its children. Only the root, running in the System partition, can join its
own thread to partitions. The percentage for budgets must not be zero.
||Unless you're testing the partitioning aspects and want to change all of the parameters
without restarting, you should set at least basic security.|
After setting up the scheduler partitions, you can use
to prevent further unauthorized changes.
APS_INIT_DATA( &p );
p.sec_flags = SCHED_APS_SEC_LOCK_PARTITIONS;
SchedCtl( SCHED_APS_ADD_SECURITY, &p, sizeof(p));
||Before you call SchedCtl(), ensure that you initialize
all the members of the data structure associated with the
command. You can use the APS_INIT_DATA() macro to do this.
The security options listed above are composed of the following options
(but it's more convenient to use the compound options):
- root0_overall or the SCHED_APS_SEC_ROOT0_OVERALL flag
- You must be the root running in the System partition in order
to change the overall scheduling parameters, such as the averaging
- root_makes_partitions or the SCHED_APS_SEC_ROOT_MAKES_PARTITIONS flag
- You must be the root in order to create or modify partitions.
- sys_makes_partitions or the SCHED_APS_SEC_SYS_MAKES_PARTITIONS flag
- You must be running in the System partition in order to create or
- parent_modifies or the SCHED_APS_SEC_PARENT_MODIFIES flag
- Allows partitions to be modified
(SCHED_APS_MODIFY_PARTITION), but you must be running in
the parent partition of the partition being modified.
“Modify” means to change a partition's percentage or
critical budget, or attach events with the
- nonzero_budgets or the SCHED_APS_SEC_NONZERO_BUDGETS flag
- A partition may not be created with, or modified to have, a zero budget.
Unless you know your partition needs to run only in response to
client requests, i.e. receipt of messages, you should set this option.
- root_makes_critical or the SCHED_APS_SEC_ROOT_MAKES_CRITICAL flag
- You have to be the root in order to create a nonzero critical
budget or change an existing critical budget.
- sys_makes_critical or the SCHED_APS_SEC_SYS_MAKES_CRITICAL flag
- You must be running in the System partition to create a nonzero
critical budget or change an existing critical budget.
- root_joins or the SCHED_APS_SEC_ROOT_JOINS flag
- You must be root in order to join a thread to a partition.
- sys_joins or the SCHED_APS_SEC_SYS_JOINS flag
- You must be running in the System partition in order to join a thread.
- parent_joins or the SCHED_APS_SEC_PARENT_JOINS flag
- You must be running in the parent partition of the partition you wish
- join_self_only or the SCHED_APS_SEC_JOIN_SELF_ONLY flag
- A process may join only itself to a partition.
- partitions_locked or the SCHED_APS_SEC_PARTITIONS_LOCKED flag
- Prevent further changes to any partition's budget, or overall
scheduling parameters, such as the window size.
Set this after you've set up your partitions.
Any thread can make itself critical, and any designer can make any sigevent critical (meaning that it
will cause the eventual receiver to run as critical), but this isn't a security issue. That's because a thread marked as critical has no effect on the
thread scheduler unless the thread is in a partition that has a critical budget.
The thread scheduler has security options that control who may set or change a partition's critical budget.
For the system to be secure against possible critical thread abuse, it's important to:
- assign a critical budget only to the partitions that need one
- move as much application software as possible out of the System partition (which has an infinite critical budget)