We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
as we know supervisor mode is priviliged and user is not. at reset time in debugging mode, i read the cpsr it is 0x1d3 means in supervisor mode, so i can change CPSR so i changed it to 0x1d0 which is user mode, since user mode is unpriviliged so i must not able to modify CPSR, but when i again write it to 0x1d3, i updates. why is it so?
Hi,
From your question, I assume that you are using the debugger to modify the contents of CPSR. Is that right? If so, then you have found that the debugger is not subject to the constraints of privilege - this is correct behaviour!
Best wishes
Chris
Thanks Chris, but if i want to verify this privilege check test of different modes,then rather in debugging mode, how should i do it?
Which processor it is? Cortex-M4?
Cortex M4 has APSR, EPSR and IPSR.
Try using the MSR instruction to write to the special registers. Also note the following from the M4 device user guide (Page 3-164): (OR see this link - ARM Information Center and ARM Information Center)
The register access operation in MSR depends on the privilege level. Unprivileged software can only access the APSR.
Attempts to write the EPSR using the MSR instruction in application software are ignored.
MSR
Table 2.3. PSR register combinations
[a] The processor ignores writes to the IPSR bits.
Hope it helps.
i am using CORTEX-A9 Processor.
anoopstm wrote: i am using CORTEX-A9 Processor.
anoopstm wrote:
Oh... in that case, my answer doesn't apply !!!
You have to execute an instruction which does what you want to check. So in your test you need to try and execute an MSR instruction to change CPSR from user mode to set supervisor mode and you should find it doesn't do it. If you want to be absolutely certain the result has nothing to do with debug state just set up a program with an MRS after the MSR and print the value out.
As mentioned below, you need to try to do it by executing an appropriate instruction and see if it works!
I'd be interested to know why you want or need to check that this works - I can assure you it does work exactly as described in the manual! If it didn't work, there would be a large security hole in every system implemented on an ARM platform.
i know and hope this will work. but since i am new to ARM , and i want to check for learning and debugging also. i want to be sure at the initial stage.
so by this discussion i came to know that debugging mode is not constraint to priviliged or unpriviliged modes.
I understand. However, I can assure you that you do not need to check things like this. Where a certain feature or behavior is mandated by the architecture, it is absolutely guaranteed to work the way it is described in the Architecture Reference Manual.
Good luck with your investigations. Let us know if there is any otherway we can help.
Well to quote HMS Pinafore: And I'm never, never sick at sea! Chorus. What, never? Captain. No, never! Chorus. What, never? Captain. Hardly ever! Chorus. He's hardly ever sick at sea!
But yes it is simply not worth worrying about hardware errata though it is a good idea to read the notices occasionally. If you do have the misfortune to come across one of these you'll probably pull your hair out investigating everything else first - and quite rightly too. They tend to involve some very obscure combination of circumstance such that any change like for instance sticking in a trace message which changes the alignment in a cache line makes it disappear.