この節では，カーネルオブジェクトのアクセス保護について述べる．この節の内容は，保護機能対応カー ネルにのみ適用される．
【μITRON4.0/PX仕様との関係】
システム時刻に対するアクセス許可ベクタと，それを設定する静的APIおよびサービスコールを廃止し，
保護ドメインに対するアクセス許可ベクタと，それを設定する静的APIおよびサービスコールを追加し た．
【TOPPERS新世代カーネル統合仕様との関係】
保護ドメインに対するアクセス許可ベクタと，それを設定する静的APIおよびサービスコールを追加し た．
2.11.1 オブ ジェクトのアクセス保護とアクセス違反の 通 知
カーネルオブジェクトに対するアクセスは，そのオブジェクトに対して設定されたアクセス許可ベクタに よって保護される【NGKI0405】．ただし，アクセス許可ベクタを持たないオブジェクトに対するアクセ
スや，特定のオブジェクトに関連しないシステムの状態に対する操作，オブジェクトを定義するサービス コールについては，スケジューリングに関係するものは保護ドメインに対するアクセス許可ベクタによっ て，その他はシステム状態に対するアクセス許可ベクタによって保護される【NGKI0568】．また，オブ ジェクトを生成するサービスコールは，生成するオブジェクトが属する保護ドメインに対するアクセス許 可ベクタによって保護される【NGKI0612】．
アクセス許可ベクタによって許可されていないアクセス（アクセス違反）は，カーネルによって検出さ れ，以下の方法によって通知される．
サービスコールにより，メモリオブジェクト以外のカーネルオブジェクトに対して，許可されていないア クセスを行おうとした場合，サービスコールからE_OACVエラーが返る【NGKI0408】．また，メモリオ ブジェクトに対して，許可されていない管理操作または参照操作を行おうとした場合も，サービスコール からE_OACVエラーが返る【NGKI0409】．
メモリオブジェクトに対して，通常のメモリアクセスにより，許可されていない書込みアクセスまたは読 出しアクセス（実行アクセスを含む）を行おうとした場合，CPU例外ハンドラが起動される【
NGKI0410】．どのCPU例外ハンドラが起動されるかは，ターゲット定義である【NGKI0411】．ターゲッ トによっては，エミュレートされたCPU例外ハンドラの場合もある．また，ターゲット定義で，アクセス 違反の状況に応じて異なるCPU例外ハンドラが起動される場合もある．この（これらの）CPU例外ハンド ラを，メモリアクセス違反ハンドラと呼ぶ．
メモリオブジェクトに対して，サービスコールを通じて，許可されていない書込みアクセスまたは読出し アクセスを行おうとした場合，サービスコールからE_MACVエラーが返るか，メモリアクセス違反ハンド ラが起動される【NGKI0412】．E_MACVエラーが返るかメモリアクセス違反ハンドラが起動されるか は，ターゲット定義である【NGKI0413】．
メモリアクセス違反ハンドラでは，アクセス違反を発生させたアクセスに関する情報（アクセスした番 地，アクセスの種別，アクセスした命令の番地など）を参照する方法を，ターゲット定義で用意する
【NGKI0414】．
メモリオブジェクトとしてカーネルに登録されていないメモリ領域に対して，ユーザドメインから書込み アクセスまたは読出しアクセス（実行アクセスを含む）を行おうとした場合には，メモリオブジェクトに 対するアクセスが許可されていない場合と同様に扱われる【NGKI0415】．カーネルドメインから同様の アクセスを行おうとした場合の動作は保証されない【NGKI0416】．
【未決定事項】
マルチプロセッサ対応カーネルにおいて，システム状態のアクセス許可ベクタをシステム全体で1つ持つ かプロセッサ毎に持つかは，今後の課題である．
【μITRON4.0/PX仕様との関係】
μITRON4.0/PX仕様では，アクセス保護の実装定義の制限について規定しているが，この仕様では，メモ リオブジェクトに対するアクセス許可ベクタのターゲット定義の制限以外については規定していない．
【TOPPERS新世代カーネル統合仕様との関係】
オブジェクトを生成するサービスコールの保護は，TOPPERS新世代カーネル統合仕様では，システム状態 に対するアクセス許可ベクタによって行っていたが，この仕様では，生成するオブジェクトが属する保護 ドメインに対するアクセス許可ベクタによって行うものとした．これに伴って，オブジェクトを生成する 際に使用するリソース（ID番号，カーネルメモリプール領域）の確保量についても，保護ドメイン毎に設 定することとした．
【仕様決定の理由】
オブジェクトを登録するサービスコールを，そのオブジェクトのアクセス許可ベクタによって保護しない のは，オブジェクトを登録する前には，アクセス許可ベクタが設定されていないためである．
2.11.2 メ モ リ オブ ジェクトに対するアクセス許 可ベ クタの 制 限
メモリオブジェクトの書込みアクセスと読出しアクセス（実行アクセスを含む）に対して設定できるアク セス許可パターンは，ターゲット定義で制限される場合がある【NGKI0417】．
ただし，少なくとも，次の5つの組み合わせの設定は，行うことができる．
(a) メモリオブジェクトが属する保護ドメインのみに，読出しアクセス（実行アクセスを含む）のみを許 可する【NGKI0418】．これを，専有リードオンリー（private read only）と呼ぶ．
(b) メモリオブジェクトが属する保護ドメインのみに，書込みアクセスと読出しアクセス（実行アクセス を含む）を許可する【NGKI0419】．これを，専有リードライト（private read/write）と呼ぶ．
(c) すべての保護ドメインに，読出しアクセス（実行アクセスを含む）のみを許可する【NGKI0420】．こ れを，共有リードオンリー（shared read only）と呼ぶ．
(d) すべての保護ドメインに，書込みアクセスと読出しアクセス（実行アクセスを含む）を許可する
【NGKI0421】．これを，共有リードライト（shared read/write）と呼ぶ．
(e) メモリオブジェクトが属する保護ドメインに，書込みアクセスと読出しアクセス（実行アクセスを含 む）を許可し，他の保護ドメインには，読出しアクセス（実行アクセスを含む）のみを許可する
【NGKI0422】．これを，共有リード専有ライト（shared read private write）と呼ぶ．
また，ターゲット定義で，1つの保護ドメインに登録できるメモリオブジェクトの数が制限される場合が ある【NGKI0423】．
2.11.3 デ フ ォ ルトのアクセス許 可ベ クタ
カーネルオブジェクトを登録した直後は，次に規定されるデフォルトのアクセス許可ベクタが設定され る．
保護ドメインに属するカーネルオブジェクトに対しては，通常操作1，通常操作2，参照操作の3つの種別 のアクセスが，その保護ドメインのみに許可される【NGKI0613】．すなわち，カーネルドメインに属す るオブジェクトに対しては，上記の3つのアクセス種別のアクセス許可パターンがTACP_KERNELに，ユー ザドメインに属するオブジェクトに対しては，上記の3つのアクセス種別のアクセス許可パターンがTACP (domid)（domidはオブジェクトが属する保護ドメインのID番号）に設定される．管理操作のアクセス許 可パターンは，そのカーネルオブジェクトが属する保護ドメインに対する通常操作1のアクセス許可パ ターンと同じ値に設定される【NGKI0614】．
無所属のカーネルオブジェクトに対しては，通常操作1，通常操作2，参照操作の3つの種別のアクセス が，すべての保護ドメインに許可される【NGKI0615】．すなわち，上記の3つのアクセス種別のアクセス 許可パターンが，TACP_SHAREDに設定される．管理操作のアクセス許可パターンは，無所属に対する通 常操作1のアクセス許可パターンと同じ値に設定される【NGKI0616】．
保護ドメインのアクセス許可ベクタは，通常操作1と参照操作はその保護ドメインのみに許可され，通常 操作2と管理操作はカーネルドメインのみに許可される【NGKI0569】．すなわち，カーネルドメインに対
しては，4つのアクセス許可パターンがいずれもTACP_KERNELに，ユーザドメインに対しては，通常操作 1と参照操作のアクセス許可パターンがTACP(domid)に，通常操作2と管理操作のアクセス許可パターン がTACP_KERNELに設定される．
無所属に対するアクセス許可ベクタは，通常操作1と参照操作はすべての保護ドメインに許可され，通常 操作2と管理操作はカーネルドメインのみに許可される【NGKI0617】．すなわち，通常操作1と参照操作 のアクセス許可パターンがTACP_SHAREDに，通常操作2と管理操作のアクセス許可パターン
がTACP_KERNELに設定される．
システム状態のアクセス許可ベクタは，4つの種別のアクセスがいずれも，カーネルドメインのみに許可 される【NGKI0537】．すなわち，4つのアクセス許可パターンがいずれも，TACP_KERNELに設定され る．
【TOPPERS新世代カーネル統合仕様との関係】
保護ドメイン以外のカーネルオブジェクトに対する管理操作のアクセス許可パターンを，そのカーネルオ ブジェクトが属する保護ドメインに対する通常操作1（無所属のカーネルドメイン場合は，無所属に対す る通常操作1）のアクセス許可パターンと同じ値に設定されるものとした．
2.11.4 アクセス許 可ベ クタの 設 定
アクセス許可ベクタをデフォルト以外の値に設定するために，カーネルオブジェクトのアクセス許可ベク タを設定する静的API（SAC_YYY）と，保護ドメインのアクセス許可ベクタを設定する静的API
（ACV_DOM），システム状態のアクセス許可ベクタを設定する静的API（SAC_SYS）が用意されている
【NGKI0570】．
また，動的生成対応カーネルにおいては，カーネルオブジェクトのアクセス許可ベクタを設定するサービ スコール（sac_yyy）と，保護ドメインのアクセス許可ベクタを設定するサービスコール（sac_dom），
システム状態のアクセス許可ベクタを設定するサービスコール（sac_sys）が用意されている【
NGKI0571】．ただし，静的APIによって登録したオブジェクトは，サービスコール（sac_yyy）によって アクセス許可ベクタを設定することができない．アクセス許可ベクタを設定しようとした場合に
は，E_OBJエラーとなる【NGKI0430】．
メモリオブジェクトに対しては，アクセス許可ベクタを設定する静的APIは用意されておらず，オブジェ クトを追加する静的API（ATT_YYY）によって，登録と同時にアクセス許可ベクタを設定することができ る【NGKI0605】．アクセス許可ベクタの記述を省略した場合には，デフォルトのアクセス許可ベクタが 設定される【NGKI0606】．
オブジェクトに対するアクセスが許可されているかは，そのオブジェクトにアクセスするサービスコール を呼び出した時点でチェックされる【NGKI0432】．そのため，アクセス許可ベクタを変更しても，変更 以前に呼び出されたサービスコールの振舞いには影響しない．例えば，待ち行列を持つ同期・通信オブジ ェクトのアクセス許可ベクタを変更しても，呼び出した時点ですでに待ち行列につながれているタスクに は影響しない．また，ミューテックスのアクセス許可ベクタを変更しても，呼び出した時点ですでにミ ューテックをロックしていたタスクには影響しない．
この仕様では，カーネルオブジェクトに設定されたアクセス許可ベクタを参照する機能は用意していな い．
【使用上の注意】
カーネルオブジェクトのアクセス許可ベクタをデフォルト以外の値に設定する際に，オブジェクトに対し て同じ保護ドメインに属する処理単位からアクセスできるようにするには，その保護ドメインからアクセ