Hello arm expects, While reading the tf-a spec about the section "3.5.1 Register state". It described that "The MMU must be disabled for a partition that does not run in S-EL0". Does this mean that the S-EL1 SP need to create their own page table and enable the MMU itself. I wonder in this way, it is not very friendly to a SP developer. Since the SP can be a verify simple binary, maybe a single driver which can benefited from the isolation from other partitions. So in the pointer of developing a single driver. I think it do not need to care about the MMU configuration. It will be more friendly to be as easy as developing a user-land binary. The SPMC(SEL2) can do this configure for the SEL1's page-tables and enable MMU for SEL1 before jump into the SP.
So I want to discuss here to understand the meaning behind it.
Cheers, Feng
FF-A spec :) https://developer.arm.com/documentation/den0077/latest
On 2020/8/24 11:30 下午, chen feng wrote:
Hello arm expects, While reading the tf-a spec about the section "3.5.1 Register state". It described that "The MMU must be disabled for a partition that does not run in S-EL0". Does this mean that the S-EL1 SP need to create their own page table and enable the MMU itself. I wonder in this way, it is not very friendly to a SP developer. Since the SP can be a verify simple binary, maybe a single driver which can benefited from the isolation from other partitions. So in the pointer of developing a single driver. I think it do not need to care about the MMU configuration. It will be more friendly to be as easy as developing a user-land binary. The SPMC(SEL2) can do this configure for the SEL1's page-tables and enable MMU for SEL1 before jump into the SP.
So I want to discuss here to understand the meaning behind it.
Cheers, Feng
Hi Feng,
On 24 Aug 2020, at 16:30, chen feng puck.chen@foxmail.com wrote:
Hello arm expects, While reading the tf-a spec about the section "3.5.1 Register state". It described that "The MMU must be disabled for a partition that does not run in S-EL0". Does this mean that the S-EL1 SP need to create their own page table and enable the MMU itself. I wonder in this way, it is not very friendly to a SP developer. Since the SP can be a verify simple binary, maybe a single driver which can benefited from the isolation from other partitions. So in the pointer of developing a single driver. I think it do not need to care about the MMU configuration. It will be more friendly to be as easy as developing a user-land binary. The SPMC(SEL2) can do this configure for the SEL1's page-tables and enable MMU for SEL1 before jump into the SP.
The usage model you describe is exactly why the SPM must create and enable the MMU for a S-EL0 SP. It has the same relationship with the SPM that an application has with a OS. It looks like a S-EL0 SP is more suitable for you?
The Arm architecture enables software that runs in a privileged exception level to initialise the exception level. So S-EL1 does not need to depend upon S-EL2. Creating this dependency will only increase the complexity of S-EL2 which defeats the aim of minimising the TCB of the system.
So I want to discuss here to understand the meaning behind it.
I hope this sounds reasonable.
Cheers, Achin
Cheers, Feng
Hi Achin,
Thanks.
On 2020/8/24 11:55 下午, Achin Gupta wrote:
Hi Feng,
On 24 Aug 2020, at 16:30, chen feng puck.chen@foxmail.com wrote:
Hello arm expects, While reading the tf-a spec about the section "3.5.1 Register state". It described that "The MMU must be disabled for a partition that does not run in S-EL0". Does this mean that the S-EL1 SP need to create their own page table and enable the MMU itself. I wonder in this way, it is not very friendly to a SP developer. Since the SP can be a verify simple binary, maybe a single driver which can benefited from the isolation from other partitions. So in the pointer of developing a single driver. I think it do not need to care about the MMU configuration. It will be more friendly to be as easy as developing a user-land binary. The SPMC(SEL2) can do this configure for the SEL1's page-tables and enable MMU for SEL1 before jump into the SP.
The usage model you describe is exactly why the SPM must create and enable the MMU for a S-EL0 SP. It has the same relationship with the SPM that an application has with a OS. It looks like a S-EL0 SP is more suitable for you?
Okay, Yes a S-EL0 SP can also do this.
The Arm architecture enables software that runs in a privileged exception level to initialise the exception level. So S-EL1 does not need to depend upon S-EL2. Creating this dependency will only increase the complexity of S-EL2 which defeats the aim of minimising the TCB of the system.
So, Do you mean that the S-EL1 SP is used for a SP with OS, and the S-EL0 SP is used for SP without OS(single binary)?
I agree the minimize about the TCB of SEL2. Beside the "runs in a privileged exception level to initialize the exception level" mentioned above.
No matter the SP in run in SEL1 or SEL0, the SEL2 seems need to do the same things :)
Cheers
So I want to discuss here to understand the meaning behind it.
I hope this sounds reasonable.
Cheers, Achin
Cheers, Feng
Hi Feng,
On 24 Aug 2020, at 17:32, chen feng puck.chen@foxmail.com wrote:
Hi Achin,
Thanks.
On 2020/8/24 11:55 下午, Achin Gupta wrote:
Hi Feng,
On 24 Aug 2020, at 16:30, chen feng puck.chen@foxmail.com wrote:
Hello arm expects, While reading the tf-a spec about the section "3.5.1 Register state". It described that "The MMU must be disabled for a partition that does not run in S-EL0". Does this mean that the S-EL1 SP need to create their own page table and enable the MMU itself. I wonder in this way, it is not very friendly to a SP developer. Since the SP can be a verify simple binary, maybe a single driver which can benefited from the isolation from other partitions. So in the pointer of developing a single driver. I think it do not need to care about the MMU configuration. It will be more friendly to be as easy as developing a user-land binary. The SPMC(SEL2) can do this configure for the SEL1's page-tables and enable MMU for SEL1 before jump into the SP.
The usage model you describe is exactly why the SPM must create and enable the MMU for a S-EL0 SP. It has the same relationship with the SPM that an application has with a OS. It looks like a S-EL0 SP is more suitable for you?
Okay, Yes a S-EL0 SP can also do this.
The Arm architecture enables software that runs in a privileged exception level to initialise the exception level. So S-EL1 does not need to depend upon S-EL2. Creating this dependency will only increase the complexity of S-EL2 which defeats the aim of minimising the TCB of the system.
So, Do you mean that the S-EL1 SP is used for a SP with OS, and the S-EL0 SP is used for SP without OS(single binary)?
An OS can vary in complexity. I meant that the S-EL1 SP should be able to initialise S-EL1 and launch the driver at the very least. It does not have to be an OS.
I agree the minimize about the TCB of SEL2. Beside the "runs in a privileged exception level to initialize the exception level" mentioned above.
No matter the SP in run in SEL1 or SEL0, the SEL2 seems need to do the same things :)
I agree if by "same things" you mean that the SPM in S-EL2 is responsible for address space isolation. There is a bit of detail here:
If VHE is disabled, S-EL2 SPM programs isolation of a S-EL1 SP through Stage 2 translations in the PE and SMMUs. The S-EL1 SP might implement just a single driver in S-EL0 as you described above. The SPM only sees a S-EL1 SP. How the S-EL1 SP maintains isolation between S-EL1 and S-EL0 is an implementation detail that the SPM is not aware of.
If VHE is enabled, S-EL2 SPM programs isolation of a S-EL0 SP through Stage 1 translations in the PE and SMMUs. There is no S-EL1.
Please let me know if that is not what you have in mind.
Cheers, Achin
Cheers
So I want to discuss here to understand the meaning behind it.
I hope this sounds reasonable. Cheers, Achin
Cheers, Feng
Hi Achin,
On 2020/8/25 1:10 上午, Achin Gupta wrote:
Hi Feng,
On 24 Aug 2020, at 17:32, chen feng puck.chen@foxmail.com wrote:
Hi Achin,
Thanks.
On 2020/8/24 11:55 下午, Achin Gupta wrote:
Hi Feng,
On 24 Aug 2020, at 16:30, chen feng puck.chen@foxmail.com wrote:
Hello arm expects, While reading the tf-a spec about the section "3.5.1 Register state". It described that "The MMU must be disabled for a partition that does not run in S-EL0". Does this mean that the S-EL1 SP need to create their own page table and enable the MMU itself. I wonder in this way, it is not very friendly to a SP developer. Since the SP can be a verify simple binary, maybe a single driver which can benefited from the isolation from other partitions. So in the pointer of developing a single driver. I think it do not need to care about the MMU configuration. It will be more friendly to be as easy as developing a user-land binary. The SPMC(SEL2) can do this configure for the SEL1's page-tables and enable MMU for SEL1 before jump into the SP.
The usage model you describe is exactly why the SPM must create and enable the MMU for a S-EL0 SP. It has the same relationship with the SPM that an application has with a OS. It looks like a S-EL0 SP is more suitable for you?
Okay, Yes a S-EL0 SP can also do this.
The Arm architecture enables software that runs in a privileged exception level to initialise the exception level. So S-EL1 does not need to depend upon S-EL2. Creating this dependency will only increase the complexity of S-EL2 which defeats the aim of minimising the TCB of the system.
So, Do you mean that the S-EL1 SP is used for a SP with OS, and the S-EL0 SP is used for SP without OS(single binary)?
An OS can vary in complexity. I meant that the S-EL1 SP should be able to initialise S-EL1 and launch the driver at the very least. It does not have to be an OS.
I agree the minimize about the TCB of SEL2. Beside the "runs in a privileged exception level to initialize the exception level" mentioned above.
No matter the SP in run in SEL1 or SEL0, the SEL2 seems need to do the same things :)
I agree if by "same things" you mean that the SPM in S-EL2 is responsible for address space isolation. There is a bit of detail here:
If VHE is disabled, S-EL2 SPM programs isolation of a S-EL1 SP through Stage 2 translations in the PE and SMMUs. The S-EL1 SP might implement just a single driver in S-EL0 as you described above. The SPM only sees a S-EL1 SP. How the S-EL1 SP maintains isolation between S-EL1 and S-EL0 is an implementation detail that the SPM is not aware of.
I want to discuss more about the VHE disabled scenes here.
+---------------+ +---------------+ | sel0 driver 0| |sel0 driver 1 | +---------------+ +---------------+
+---------------+ +---------------+ | SEL1 | | SEL1 | +---------------+ +---------------+
+------------------------------------+ | | | SEL2 SPM | | | +------------------------------------+
Does this show the software "The S-EL1 SP might implement just a single driver in S-EL0" mentioned above?
If yes, the SP developers seems have to do more work for a single driver. Or the SEL1 is a part of the VMAPI for a SP developer?
In this way it increase the memory usage for the same SEL1 software. Why not just put the driver into sel1 is my concern.
If we put the sel0 deiver0 and driver 1 above one SEL1-Software, there is no isolation.
If VHE is enabled, S-EL2 SPM programs isolation of a S-EL0 SP through Stage 1 translations in the PE and SMMUs. There is no S-EL1.
So does this is the normal case with VHE enabled with SEL2. But this seems like currently without SEL2, SEl1 can do this work.
Please let me know if that is not what you have in mind.
Cheers, Achin
Cheers
So I want to discuss here to understand the meaning behind it.
I hope this sounds reasonable. Cheers, Achin
Cheers, Feng
Hi Feng,
On 25 Aug 2020, at 00:03, chen feng puck.chen@foxmail.com wrote:
Hi Achin,
On 2020/8/25 1:10 上午, Achin Gupta wrote:
Hi Feng,
On 24 Aug 2020, at 17:32, chen feng puck.chen@foxmail.com wrote:
Hi Achin,
Thanks.
On 2020/8/24 11:55 下午, Achin Gupta wrote:
Hi Feng,
On 24 Aug 2020, at 16:30, chen feng puck.chen@foxmail.com wrote:
Hello arm expects, While reading the tf-a spec about the section "3.5.1 Register state". It described that "The MMU must be disabled for a partition that does not run in S-EL0". Does this mean that the S-EL1 SP need to create their own page table and enable the MMU itself. I wonder in this way, it is not very friendly to a SP developer. Since the SP can be a verify simple binary, maybe a single driver which can benefited from the isolation from other partitions. So in the pointer of developing a single driver. I think it do not need to care about the MMU configuration. It will be more friendly to be as easy as developing a user-land binary. The SPMC(SEL2) can do this configure for the SEL1's page-tables and enable MMU for SEL1 before jump into the SP.
The usage model you describe is exactly why the SPM must create and enable the MMU for a S-EL0 SP. It has the same relationship with the SPM that an application has with a OS. It looks like a S-EL0 SP is more suitable for you?
Okay, Yes a S-EL0 SP can also do this.
The Arm architecture enables software that runs in a privileged exception level to initialise the exception level. So S-EL1 does not need to depend upon S-EL2. Creating this dependency will only increase the complexity of S-EL2 which defeats the aim of minimising the TCB of the system.
So, Do you mean that the S-EL1 SP is used for a SP with OS, and the S-EL0 SP is used for SP without OS(single binary)?
An OS can vary in complexity. I meant that the S-EL1 SP should be able to initialise S-EL1 and launch the driver at the very least. It does not have to be an OS.
I agree the minimize about the TCB of SEL2. Beside the "runs in a privileged exception level to initialize the exception level" mentioned above.
No matter the SP in run in SEL1 or SEL0, the SEL2 seems need to do the same things :)
I agree if by "same things" you mean that the SPM in S-EL2 is responsible for address space isolation. There is a bit of detail here: If VHE is disabled, S-EL2 SPM programs isolation of a S-EL1 SP through Stage 2 translations in the PE and SMMUs. The S-EL1 SP might implement just a single driver in S-EL0 as you described above. The SPM only sees a S-EL1 SP. How the S-EL1 SP maintains isolation between S-EL1 and S-EL0 is an implementation detail that the SPM is not aware of.
I want to discuss more about the VHE disabled scenes here.
+---------------+ +---------------+ | sel0 driver 0| |sel0 driver 1 | +---------------+ +---------------+
+---------------+ +---------------+ | SEL1 | | SEL1 | +---------------+ +---------------+
+------------------------------------+ | | | SEL2 SPM | | | +------------------------------------+
Does this show the software "The S-EL1 SP might implement just a single driver in S-EL0" mentioned above?
Yes it does.
If yes, the SP developers seems have to do more work for a single driver. Or the SEL1 is a part of the VMAPI for a SP developer?
Sorry. I did not quite follow this. Are you asking if FF-A ABIs (VMAPI?) can be used between S-EL1 and S-EL0 ELs?
In this way it increase the memory usage for the same SEL1 software. Why not just put the driver into sel1 is my concern.
Whether the driver is put in S-EL1 or S-EL0 is an implementation choice.
It would be simpler to put it in S-EL1 as you would not need to worry about S-EL0.
On the other hand, the S-EL1 boxes in the diagram could be provisioned with a common S-EL1 library. The library would be responsible for MMU setup etc and reused in both boxes. S-EL0 would be used to isolate the drivers from S-EL1. So this is a better way of enforcing the principle of least privilege.
We are investigating the pros and cons of providing a reference S-EL1 library. It would forward FF-A SVCs from S-EL0 to S-EL2, setup MMU, provide simple fault handling etc. This would enable partners to just worry about writing the driver in S-EL0 with FF-A ABIs and reuse the reference library.
If we put the sel0 deiver0 and driver 1 above one SEL1-Software, there is no isolation.
Yes. With S-EL2 and without VHE, to isolate the drivers, they need to be put in separate S-EL1 partitions. Within the partition whether the driver runs in S-EL0 or S-EL1 is an implementation choice as I described above.
If VHE is enabled, S-EL2 SPM programs isolation of a S-EL0 SP through Stage 1 translations in the PE and SMMUs. There is no S-EL1.
So does this is the normal case with VHE enabled with SEL2. But this seems like currently without SEL2, SEl1 can do this work.
Yes. In the absence of S-EL2, S-EL1 can do this work.
We are working on enabling S-EL0 SPs with the OP-TEE Trusted OS. The patches can be found here:
https://review.trustedfirmware.org/q/project:OP-TEE%252Foptee_os+status:open
I hope we are understanding each other. I would be happy to have a call to discuss further if that helps. Please let me know.
Cheers, Achin
Please let me know if that is not what you have in mind. Cheers, Achin
Cheers
So I want to discuss here to understand the meaning behind it.
I hope this sounds reasonable. Cheers, Achin
Cheers, Feng
Hi Achin,
I's quite clear now, thanks very much.
On 2020/8/26 6:03 上午, Achin Gupta wrote: ...
I want to discuss more about the VHE disabled scenes here.
+---------------+ +---------------+ | sel0 driver 0| |sel0 driver 1 | +---------------+ +---------------+
+---------------+ +---------------+ | SEL1 | | SEL1 | +---------------+ +---------------+
+------------------------------------+ | | | SEL2 SPM | | | +------------------------------------+
Does this show the software "The S-EL1 SP might implement just a single driver in S-EL0" mentioned above?
Yes it does.
If yes, the SP developers seems have to do more work for a single driver. Or the SEL1 is a part of the VMAPI for a SP developer?
Sorry. I did not quite follow this. Are you asking if FF-A ABIs (VMAPI?) can be used between S-EL1 and S-EL0 ELs?
Yes, the FF-A ABIs.
In this way it increase the memory usage for the same SEL1 software. Why not just put the driver into sel1 is my concern.
Whether the driver is put in S-EL1 or S-EL0 is an implementation choice > It would be simpler to put it in S-EL1 as you would not need to worry about S-EL0.
On the other hand, the S-EL1 boxes in the diagram could be provisioned with a common S-EL1 library. The library would be responsible for MMU setup etc and reused in both boxes. S-EL0 would be used to isolate the drivers from S-EL1. So this is a better way of enforcing the principle of least privilege.
We are investigating the pros and cons of providing a reference S-EL1 library. It would forward FF-A SVCs from S-EL0 to S-EL2, setup MMU, provide simple fault handling etc. This would enable partners to just worry about writing the driver in S-EL0 with FF-A ABIs and reuse the reference library.
I think the reference S-EL1 library is necessary. Friendly development interface is much more easier to be accepted by developers. It likes a SDK for SP developers, but there can can be two choices.
A: +--------------------------------+ |S-EL1 SDK | | | | | | +-----------------+ | | | driver binary | | | +-----------------+ | +--------------------------------+
B:
+--------------------------+ | SEL0 driver binary | +--------------------------+
+--------------------------------+ |S-EL1 SDK | | | | | | | | | | | +--------------------------------+
Does the picture-a match the ARM specs? If yes, it can reduce the EL switch and context-save-restore. And also more easier to deal with interrupt.
However, in the point of a SP developer, they can choose where to put their driver. Right? Or even implement the whole S-EL0 & SEL-1 their self without using the SDK(eg: third party drivers).
Cheers, Feng
If we put the sel0 deiver0 and driver 1 above one SEL1-Software, there is no isolation.
Yes. With S-EL2 and without VHE, to isolate the drivers, they need to be put in separate S-EL1 partitions. Within the partition whether the driver runs in S-EL0 or S-EL1 is an implementation choice as I described above. >
If VHE is enabled, S-EL2 SPM programs isolation of a S-EL0 SP through Stage 1 translations in the PE and SMMUs. There is no S-EL1.
So does this is the normal case with VHE enabled with SEL2. But this seems like currently without SEL2, SEl1 can do this work.
Yes. In the absence of S-EL2, S-EL1 can do this work.
We are working on enabling S-EL0 SPs with the OP-TEE Trusted OS. The patches can be found here:
https://review.trustedfirmware.org/q/project:OP-TEE%252Foptee_os+status:open
I hope we are understanding each other. I would be happy to have a call to discuss further if that helps. Please let me know.
Cheers, Achin
Please let me know if that is not what you have in mind. Cheers, Achin
Cheers
So I want to discuss here to understand the meaning behind it.
I hope this sounds reasonable. Cheers, Achin
Cheers, Feng
Hi Feng,
Apologies for not replying sooner. I was on holiday!
On 26 Aug 2020, at 15:25, Chen Feng puck.chen@foxmail.com wrote:
Hi Achin,
I's quite clear now, thanks very much.
On 2020/8/26 6:03 上午, Achin Gupta wrote: ...
I want to discuss more about the VHE disabled scenes here.
+---------------+ +---------------+ | sel0 driver 0| |sel0 driver 1 | +---------------+ +---------------+
+---------------+ +---------------+ | SEL1 | | SEL1 | +---------------+ +---------------+
+------------------------------------+ | | | SEL2 SPM | | | +------------------------------------+
Does this show the software "The S-EL1 SP might implement just a single driver in S-EL0" mentioned above?
Yes it does.
If yes, the SP developers seems have to do more work for a single driver. Or the SEL1 is a part of the VMAPI for a SP developer?
Sorry. I did not quite follow this. Are you asking if FF-A ABIs (VMAPI?) can be used between S-EL1 and S-EL0 ELs?
Yes, the FF-A ABIs.
Yes they can. The SVC instruction can be used at S-EL0 to invoke FF-A ABIs.
In this way it increase the memory usage for the same SEL1 software. Why not just put the driver into sel1 is my concern.
Whether the driver is put in S-EL1 or S-EL0 is an implementation choice > It would be simpler to put it in S-EL1 as you would not need to worry about S-EL0. On the other hand, the S-EL1 boxes in the diagram could be provisioned with a common S-EL1 library. The library would be responsible for MMU setup etc and reused in both boxes. S-EL0 would be used to isolate the drivers from S-EL1. So this is a better way of enforcing the principle of least privilege. We are investigating the pros and cons of providing a reference S-EL1 library. It would forward FF-A SVCs from S-EL0 to S-EL2, setup MMU, provide simple fault handling etc. This would enable partners to just worry about writing the driver in S-EL0 with FF-A ABIs and reuse the reference library.
I think the reference S-EL1 library is necessary. Friendly development interface is much more easier to be accepted by developers.
I agree. It would help to have a detailed discussion about the requirements on the TF-A ML. As I said, we have also only started thinking about this. Partner feedback and code contributions would definitely help progress.
It likes a SDK for SP developers, but there can can be two choices.
A: +--------------------------------+ |S-EL1 SDK | | | | | | +-----------------+ | | | driver binary | | | +-----------------+ | +--------------------------------+
B:
+--------------------------+ | SEL0 driver binary | +--------------------------+
+--------------------------------+ |S-EL1 SDK | | | | | | | | | | | +--------------------------------+
Does the picture-a match the ARM specs? If yes, it can reduce the EL switch and context-save-restore. And also more easier to deal with interrupt.
From the FF-A spec perspective, both A and B are valid.
However, in the point of a SP developer, they can choose where to put their driver. Right? Or even implement the whole S-EL0 & SEL-1 their self without using the SDK(eg: third party drivers).
Yes. This makes sense.
Cheers, Achin
Cheers, Feng
If we put the sel0 deiver0 and driver 1 above one SEL1-Software, there is no isolation.
Yes. With S-EL2 and without VHE, to isolate the drivers, they need to be put in separate S-EL1 partitions. Within the partition whether the driver runs in S-EL0 or S-EL1 is an implementation choice as I described above. >
If VHE is enabled, S-EL2 SPM programs isolation of a S-EL0 SP through Stage 1 translations in the PE and SMMUs. There is no S-EL1.
So does this is the normal case with VHE enabled with SEL2. But this seems like currently without SEL2, SEl1 can do this work.
Yes. In the absence of S-EL2, S-EL1 can do this work. We are working on enabling S-EL0 SPs with the OP-TEE Trusted OS. The patches can be found here: https://review.trustedfirmware.org/q/project:OP-TEE%252Foptee_os+status:open I hope we are understanding each other. I would be happy to have a call to discuss further if that helps. Please let me know. Cheers, Achin
Please let me know if that is not what you have in mind. Cheers, Achin
Cheers
> > So I want to discuss here to understand the meaning behind it. I hope this sounds reasonable. Cheers, Achin > > Cheers, > Feng
tf-a@lists.trustedfirmware.org
-
Achin Gupta -
Chen Feng -
chen feng