Hi Dan,
Sorry for the late reply. Actually, I may express the problem incorrectly. Now I will describe it again.
(1) What happen: I config a region in TZASC, in which the security attribute is: {S_RDWR, NS_None}. I use NS EL1 (Linux OS) to read it. It generates a data abort. I use NS EL1 (Linux OS) to write it. It ignores the write and no data abort. (values are unchanged.) I use NS EL2 (no KVM now) to read/write it. It both generates a data abort.
(2) Can I handle it in EL2? I think it is difficult because I didn't see any "write" data abort generated. So I worry that EL2 cannot trap it.
(3) Why? I am not sure. Maybe the Linux OS jumps to the next instruction when facing such data abort. But why does it only ignore the "write" data abort and report "read"?
Do you have any idea?
Sincerely, WANG Chenxu
Dan Handley Dan.Handley@arm.com 于2022年8月23日周二 21:21写道：
Hi
I'm only guessing but could the write operation be taking longer to generate the (imprecise) abort than the read, by which time execution has switched to EL2 and the abort is handled there instead? If EL2 is present you could check this by adding a handler there too.
Regards
Dan.
-----Original Message----- From: Chenxu Wang via TF-A tf-a@lists.trustedfirmware.org Sent: 23 August 2022 13:31 To: Olivier Deprez Olivier.Deprez@arm.com Cc: tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: How to trap aborts caused by TZASC?
Sorry, but I forget to provide something important.
It seems that only NS EL1/0 ignores the write instruction, while NS EL2 will generate such an EA. (Here I didn't enable KVM, just call a hvc and perform WRITE operation in NSEL2 exception handler).
What is wrong with the Linux kernel?
Sincerely, WANG Chenxu
Chenxu Wang irakatz51@gmail.com 于2022年8月23日周二 19:31写道：
Thank you Olivier,
I recently place the handler into NS-EL1 (in my scenario) and it can trap the READ operations. But, when I execute a WRITE instruction (e.g., ldr). I find the TZASC will "ignore" the write operation, instead of generating an exception.
This happens in both RevC FVP and Juno R2 board. Thus, if I want to generate an exception instead of "ignored", what can I
do?
Sincerely, WANG Chenxu
Olivier Deprez Olivier.Deprez@arm.com 于2022年8月23日周二 14:51写
道：
Hi,
Se this test: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/ misc_tests/test_invalid_access.c#n77
It traps a sync EA at NS-EL2: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/ misc_tests/test_invalid_access.c#n58
It isn't necessary to trap at EL3 unless required by the test goal.
Regards, Olivier.
From: Chenxu Wang via TF-A tf-a@lists.trustedfirmware.org Sent: 23 August 2022 00:08 To: tf-a@lists.trustedfirmware.org Subject: [TF-A] How to trap aborts caused by TZASC?
Hi all,
I want to test how to trap the aborts caused by TZASC. For example, when I use NS-EL1 (e.g., OS) to access a Secure region (configured in TZASC), it will generate an abort.
But I am not sure how to trap it. I think it is an external abort, so I enable the SCR_EL3.EA=1 and write a handler. However I cannot trap it. Also, my other handlers in EL3 still do not report the abort.
Thus, how can I trap a TZASC abort? If I want to route it into EL3 to handle, how can I do it?
Sincerely, WANG Chenxu -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org