IKUZOと申します、お伺いしたいのですが、RX631でスタック領域を保護したいのですが、MPUを使用するのでしょうか？特権命令例外を使用するのでしょうか？スタック領域というのは保護可能なんでしょうか？スタック領域というのは簡単に壊すことができるので、保護することができれば、安全ではないかと
IKUZOさん、こんにちは。NoMaYです。スタック領域は実行禁止にするぐらいしか出来ないと思います。文面からライト禁止にすることを考えているのだと思われますが、そうしてしまうと、そもそもC言語のauto変数(関数内の通常のスタック変数)へのライトがユーザモードになっている通常処理(割り込み処理(スーパバイザモード)外)ではニッチモサッチモ行かなくなってしまいますよね。
こんにちは
以下はプロフェッショナル版のみの機能ですが参考までにご紹介します。
CS+オンラインヘルプ
スタックの保護はソフトウェア的に行うものかと。上記のオプション説明がその手法の参考になるのではないでしょうか。
何がスタックを壊すと考えてますか？１．もともとの設定で必要なスタックサイズを取らない。２．ソフトエラー。３．プログラムが予定以外でスタックエリアを書き換えに行く。４．ヒープエリアが浸食してくる。他にありますかね？
１ならCallWalkerでチェックして十分なサイズを取っておけば割り込みスタック領域がオーバーフローしてユーザスタック領域を壊す様なことはないと思います。２は特別な場所でなければ気にしなくても良いと思います。高所など宇宙線が無視できない場所なら金属ケースが必須と思います。３はバグだと思ってます。プログラムを直した方が良いと思います。意図的にバグは作らないので発生させないような対処はできないと思います。発生してしまった場合はデータの検証機能やフローの検証機能でリセットと思います。４は難しいと思います。制限するとダイナミックなデータの良さが無くなってしまうように感じます。私はマイコンでmalloc、realloc、calloc、newを使いません。ダイナミックなデータを使うならメモリー管理機能の付いたOSが必須に思えます。
＞MPUを使用するのでしょうか？から、IKUZOさんの欲しい答えはまったく違うような感じもします。
じまさんいつもお世話になっています
「プロフェッショナル版のみの機能」として__stack_chk_fail関数を利用できるということですね、
バージョン情報を見るとプロフェッショナル版?
「スタックの保護はソフトウェア的に行う」なるべく早くテストしまして
ご報告いたします
IKUZOさん、こんにちは。NoMaYです。今回の「保護」は間口が広いのですね。まず、私の前の投稿に関しては、以下の通りに考えました。＞特権命令例外とかは関係ないですよね？ハードウェアマニュアルを見たところ、以下の画面コピーの通り、例外事象の優先順位としては命令アクセス例外の方が特権命令例外や未定義命令例外より高くなっていましたので、実行禁止にすることで充分かと思います。14.7 例外事象の優先順位 (赤枠は私が書いたものです)resource.renesas.com/resource/lib/jpn/online_docs/um/RX/RX63N_RX631_ja/?Exceptions#TOC_14_7それで、以下に関しては、そもそもC言語ではスタック上に取った変数を扱うことが圧倒的に多いので、スタック領域は簡単に壊すことが出来る、というようなイメージが出来ているのではないでしょうか。また、スタック上にはリターンする時の「戻り番地」が格納されていますが、これが壊されてしまうとプログラムが暴走するので、そのイメージが更に強くなるのかも、と思います。あと、スタックオーバーフローが発生したりすることも、そのイメージが強くなる要因かも、と思います。(先程、別スレッド『RX610 1MからRX610 1.5Mへの置き替え』を読んでいて、そう思いました。)(そういえば、スタックオーバーフローでプログラムが暴走するのも、結局、戻り番地が壊されてしまうから(あるいはIRAMの下限を突き抜けてしまって戻り番地が滅茶苦茶になるから)、ということに帰着されるケースが多そうですね。)＞これはC言語の場合ポインターが使用できたりしますので＞うっかり他のアドレスを書き換えることはないのかということです、そういう間違ったプログラムで壊してしまう割合(というか危険性)は、スタックも他の領域も同程度ではないかと思うのです。そういえば、じまさんが紹介された機能ですが、CS+オンラインヘルプの文面からすると、スタックオーバーフローのチェックは行われないようですね。将来、そういうチェックをするオプションが追加されたりするかも知れないですね。ちょっと思ったのですが、この機能では、スタック上の「戻り番地」の直下(0x00000000方向)あたりに固定32ビット整数値を埋め込んでおいて、それが書き換わっているかどうかチェックしているのですが、固定値を埋め込むのではなくて「戻り番地のビット反転」を埋め込むようにする、というのもアリではないだろうか、と思いました。[追記]ああっ、でも、UスタックオーバーフローならMPUを使っても出来そうですね。例えば、以下のようにセクションをレイアウトしてMPUを適切に設定すれば良さそうな気がしてきました。
0x00000000～0x0000000F 未使用 リード/ライト/実行禁止 (つまり全禁止のBAC領域とする)0x00000010～0x0000LLLF Uスタック リード/ライト許可,実行禁止0x0000MMM0～0x000NNNNF Iスタック,DATA,BSS,等 リード/ライト許可,実行禁止略0xFFFPPPP0～0xFFFQQQQF CONST,等 リード許可,ライト/実行禁止0xFFFRRRR0～0xFFFSSSSF プログラム 実行許可,リード/ライト禁止0xFFFTTTT0～0xFFFFFFFF 未使用,固定ベクタ リード/ライト/実行禁止 (つまり全禁止のBAC領域とする)
注)・0x0000MMM0 ＝ (0x0000LLLF ＋ 1) としています・0xFFFRRRR0 ＝ (0xFFFQQQQF ＋ 1) としています・0xFFFTTTT0 ＝ (0xFFFSSSSF ＋ 1) としています・RX62N,RX621グループ用のアプリケーションノートを見た感じでは固定ベクタは全禁止のBAC領域で良さそうです[追記]他方、Iスタックオーバーフローは、少し手間を掛けられる且つオーバーフローしたタイミングから幾らか検出されるのが遅れることを大目にみられるなら、以下のような手もありそうです。(1) スタートアップルーチンかmain()の始め辺りでIスタックの底にシグネチャを書いておく(2) 例外ハンドラの入口ではISPの値がIスタックの底を突き抜けていないかチェックする(3) 例外ハンドラの出口ではIスタックの底に書いたシグネチャが書き換わっていないかチェックする
__stack_chk_fail関数を利用しようとするのですが、動作できないみたいです
#ifdef __cplusplus
extern "C" {
#endif
void __stack_chk_fail(void)
{
printf("スタックオーバーフロです！");
sys_beep(0xFFFF);
sr_reset
}
テストのモジュール
int cmd_test(char *str)
int t[5];
int i;
for(i=0; i<20; i++){
t[i]=0;
(void)t[i];
return CMD_OK;
何が原因であるのか、アドバイスいただけないでしょうか？
-------------------
C:\>T
C:\>
なにも表示されなく、__stack_chk_fail(void)を実行しているようなそぶりをみせない？
IKUZOさん、こんにちは。NoMaYです。＞__stack_chk_fail関数を利用しようとするのですが、動作できないみたいです＞。。。＞何が原因であるのか、アドバイスいただけないでしょうか？コンパイラのリストファイルでは、cmd_test()に対して、どういうコードが生成されているでしょうか？(RTSの1命令だけだったりするかも、、、)
NoMaYさんいつもアドバイスありがとうございます、違反部分のソースコードになります
t[i]='A';
printf("%c\r",t[i]);
コンパイラーのその部分のリストです
000017DB _cmd_test: .STACK _cmd_test=24 .LINE "C:\Dev\BASE\RX63N\RX631\csp\csp\com.c",871 000017DB 6E67 PUSHM R6-R7 000017DD FBE2CCCCADDE MOV.L #0DEADCCCCH, R14 000017E3 7EAE PUSH.L R14 000017E5 754614 MOV.L #00000014H, R6 .LINE "C:\Dev\BASE\RX63N\RX631\csp\csp\com.c",877 000017E8 FB72rrrrrrrr MOV.L #_L87, R7 000017EE L1040: ; bb 000017EE 6080 SUB #08H, R0 000017F0 E307 MOV.L R7, [R0] 000017F2 3E0141 MOV.L #00000041H, 04H[R0] 000017F5 05rrrrrr A BSR _printf 000017F9 6280 ADD #08H, R0 .LINE "C:\Dev\BASE\RX63N\RX631\csp\csp\com.c",875 000017FB 6016 SUB #01H, R6 000017FD 21rr BNE L1040 000017FF L1041: ; bb21 .LINE "C:\Dev\BASE\RX63N\RX631\csp\csp\com.c",880 000017FF EC0E MOV.L [R0], R14 00001801 6601 MOV.L #00000000H, R1 00001803 740ECCCCADDE CMP #0DEADCCCCH, R14 00001809 18 S BNE L1043 0000180A L1042: ; bb21 0000180A 3F6703 RTSD #0CH, R6-R7 0000180D L1043: ; bb21 0000180D 04rrrrrr A BRA ___stack_chk_fail 00001811 _cmd_test2: .STACK _cmd_test2=8 .LINE "C:\Dev\BASE\RX63N\RX631\csp\csp\com.c",883 00001811 FBE2CCCCADDE MOV.L #0DEADCCCCH, R14 00001817 7EAE PUSH.L R14 .LINE "C:\Dev\BASE\RX63N\RX631\csp\csp\com.c",886 00001819 EC0E MOV.L [R0], R14 0000181B 6601 MOV.L #00000000H, R1 0000181D 740ECCCCADDE CMP #0DEADCCCCH, R14 00001823 18 S BNE L1046 00001824 L1045: ; entry 00001824 6701 RTSD #04H 00001826 L1046: ; entry 00001826 04rrrrrr A BRA ___stack_chk_fail 0000182A _cmd_test3: .STACK _cmd_test3=8 .LINE "C:\Dev\BASE\RX63N\RX631\csp\csp\com.c",888 0000182A FBE2CCCCADDE MOV.L #0DEADCCCCH, R14 00001830 7EAE PUSH.L R14 .LINE "C:\Dev\BASE\RX63N\RX631\csp\csp\com.c",891 00001832 EC0E MOV.L [R0], R14 00001834 6601 MOV.L #00000000H, R1 00001836 740ECCCCADDE CMP #0DEADCCCCH, R14 0000183C 18 S BNE L1049 0000183D L1048: ; entry 0000183D 6701 RTSD #04H 0000183F L1049: ; entry 0000183F 04rrrrrr A BRA ___stack_chk_fail 00001843 _rtc_init: .STACK _rtc_init=12 .LINE "C:\Dev\BASE\RX63N\RX631\csp\csp\rtc.c",61 00001843 7EA6 PUSH.L R6 00001845 FBE2CCCCADDE MOV.L #0DEADCCCCH, R14 0000184B 7EAE PUSH.L R14 .LINE "C:\Dev\BASE\RX63N\RX631\csp\csp\rtc.c",64 0000184D FB6E22C408 MOV.L #0008C422H, R6 00001852 F16806 BCLR #00H, 06H[R6].B 00001855 FBEEFE0308 MOV.L #000803FEH, R14 .LINE "C:\Dev\BASE\RX63N\RX631\csp\csp\rtc.c",66 0000185A F8E90BA5 MOV.W #0A50BH, [R14] 0000185E FBFE330008 MOV.L #00080033H, R15 .LINE "C:\Dev\BASE\RX63N\RX631\csp\csp\rtc.c",67 00001863 F0F0 BSET #00H, [R15].B 00001865 L1051: ; bb1 .LINE "C:\Dev\BASE\RX63N\RX631\csp\csp\rtc.c",68 00001865 F4F0 BTST #00H, [R15].B 00001867 20rr BEQ L1051 00001869 L1052: ; bb7
IKUZOさん、こんにちは。NoMaYです。先程のはソースが変わってしまっています。まず、その前のソースの時の生成コードを確認したいです。。。