Btw as Dan mentioned if the error reported on write access is imprecise it may justify it to be reported as system error. The error on read access being precise, is reported through a sync data abort.
________________________________________ From: Olivier Deprez via TF-A tf-a@lists.trustedfirmware.org Sent: 29 August 2022 10:10 To: Chenxu Wang; Dan Handley Cc: tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: How to trap aborts caused by TZASC?
Hi,
By checking the test case mentioned earlier, I noticed: -Synchronous data ext. abort exception is generated on read -System error exception is generated on write.
I cannot tell exactly why the exception type differs on read vs write (I asked our FVP modelling team). But it might be related to how the TZC400 and memory controller are integrated on FVP. I guess this integration and behaviour is platform dependent (perhaps configurable).
The reason for missing the SError exception on write (the NS EL1 case below), may be because of PSTATE.A masked.
On a debugging front, at the time of the fault, you can check TZC400 controller registers reporting an error in the corresponding region fail address registers e.g. for region 0: FAIL_ADDRESS_LOW_0 @ 0x2A4A0020
Regards, Olivier.
________________________________________ From: Chenxu Wang irakatz51@gmail.com Sent: 28 August 2022 16:28 To: Dan Handley Cc: Olivier Deprez; tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Re: How to trap aborts caused by TZASC?
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
-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org