API Call inside a trusted function

[AlTi]

Hi again,

I have the following configuration:

-MCU is TriCore TC275 B-Step
-3 OS-Applications: AppCore0 (trusted) on Core0. AppCore1 (untrusted) and AppCore1_t (trusted) on Core1.
-I have one Event assigned to TaskMaster that belongs to AppCore0. ACCESSING_APPLICATION of TaskMaster is AppCore1_t.
-AppCore1_t offers a trusted function, that calls inside SetEvent(TaskMaster, Event). My idea was here, that AppCore1, which has no accesss rights to TaskMaster directly, should be able to Set the Event of TaskMaster with the provided trusted function.

Then I made a call to the trusted function from the task that belongs to AppCore1 and SetEvent returned E_OS_ACCESS. I assume that SetEvent is called with the service protection limitations of the calling application (AppCore1) and as AppCore1 has no access rights to TaskMaster, it returns E_OS_ACCESS.
I didn´t know if that behavior is correct and therefore I have looked into the AUTOSAR specification for trusted functions. In SWS_Os_00266 it says, that "function shall be executed with the same processor mode, memory protection boundaries and the service protection limitations of the OS-Application to which it belongs". In my view, that means that the call of SetEvent inside the trusted function should work, since the trusted function belongs to an application that has access to TaskMaster. Maybe it´s a bug, maybe it´s a fault in my configuration? What do you think?

Regards,
Alex

[e.guidieri]

Hi Alex,

I Bet that you got that requirement from the last realese of Autosar Specification (4.2.1). If yes: congratulations you caught a not documented disruptive & not backward compatible requirement change. :)

The same requirement until version 4.1 Rev 3 was like this:

[SWS_Os_00266] When CallTrustedFunction() calls the function <FunctionIndex>, that function shall be executed with the same processor mode and memory protection boundaries as the OS-Application to which it belongs. It shall however retain the service protection limitations of the calling Task or ISR, and the notion of "current application" shall remain that of the calling Task or Category 2 ISR.

[AlTi]

yes, the requirement is from 4.2.1. and the old requirement explains the behavior I have observed.

In which state is ERIKA currently? Is ERIKA synchronous with 4.2.1 (except sws_os_00266) and do you plan to implement the changes?

Thank you for your support :)

[e.guidieri]

Actually ERIKA is declared to follow AUTOSAR 4.0 rev 3 specification, during the development I kept on eye on the following version the 4.1 (rev 1 & rev 2) and I didn't notice any functional difference (but I could be wrong).

I would love to be allocated full time to kept ERIKA updated with the specification, but we are a small company and I can do that only if a customer pay for the development, otherwise I need to focus on paying thing.

Regards,
Errico

[AlTi]

ok, I will then use the shared memory section for the communication between the two Tasks.

Thank you again for your help Errico.

[e.guidieri]

BTW You could relax the service protection giving explicitly access, it's still a safer solution the use shared memory.

[AlTi]

I don´t know if it´s safer. I want to avoid that issue (from your wiki):
(5) to manipulate Operating System objects that belong to another OS-Application (to which it does not have the necessary permissions), e.g. an OS-Application tries to execute ActivateTask() on a task it does not own.

TaskMaster on Core0 is very important for the system (it acts like a supervisor) and I don´t want to grant more rights for the other OS-Applications than they need. Furthermore I have to use the shared memory anyway .... because I have to exchange data between TaskMaster and the other OS-Applications.

[e.guidieri]

For the communication you should implement something like Autosar IOC.

We just have implemented a prototype without configurator for this feature.

If you want to play with, it could be helpful for the ERIKA's project and I could try to give some advice.

Errico

[AlTi]

Hi Errico,
I have integrated parts of this example
\examples\tricore\tc2Yx\as_multicore_examples\08_IOC_save_non_primitive_unqueued
now in my application and I have faced some problems with the IOC prototype if Memory and and Service Protection are enabled.

That is the the read-inlinefunction which I call directly in the task on Core1 (from ioc_common.h):

Code: Select all

__INLINE__ Std_ReturnType __ALWAYS_INLINE__ IocRead_0(TASKParams3 * data)
{
    Std_ReturnType  result;
    EE_FREG         flags = EE_hal_suspendIRQ();

    /* generated only in case of interprocessor comunication */
    EE_as_GetSpinlock(spinlock_1);

    result = IocRead((EE_UINT8)0U, (EE_IOC_DATA_PTR)data);

    /* generated only in case of interprocessor comunication */
    EE_as_ReleaseSpinlock(spinlock_1);

    EE_hal_resumeIRQ(flags);

    return result;
}

1. Problem if ServiceProtection is enabled: The calling task needs rights to spinlock_1 otherwise GetSpinlock would return E_OS_ACCESS. I see here two options:
a) give the task the needed rights in the oil-file
b) bypass service protection in IocRead_0() or change the rights for IocRead_0().

2. Problem if MemoryProtection is enabled: The shared memory for the data exchange has to be accessible from both sides. Currently
I am using the predefined Shared Memory Section for the data, but as only trusted OS-Applications have write access to this section,
it´s not possible to use IocWrite_0() in an untrusted OS-Application. I see here some options:

a) disable MemProtection temporarily (not good)

b) change the memory protection set inside IocRead_0(), so that the predefined shared memory is accessible.

c) call IocWrite_0() in a trusted function.

I think, 1b and 2b would be the best solution. What´s your opinion or advice?

Alex

[paolo.gai]

Hi Alex,

Thanks for your posts... I see they are very detailed... Just curious... are your posts linked to your work in some research project?

Ciao,

PJ

[AlTi]

yes, they are .... here you can find some information about this project http://www.edas-ev.eu/.

[e.guidieri]

Hi Errico,
I have integrated parts of this example
\examples\tricore\tc2Yx\as_multicore_examples\08_IOC_save_non_primitive_unqueued
now in my application and I have faced some problems with the IOC prototype if Memory and and Service Protection are enabled.

You are right the examples do not address Memory Protection. IOC functions are supposed to belong to "Kernel OS-Application", actually you have to emulate it transforming each function in a TRUSTED function, belonging to yours TRUSTED OS Application (a TRUSTED OS-Application has same privileges than Kernel).

1. Problem if ServiceProtection is enabled: The calling task needs rights to spinlock_1 otherwise GetSpinlock would return E_OS_ACCESS. I see here two options:
a) give the task the needed rights in the oil-file
b) bypass service protection in IocRead_0() or change the rights for IocRead_0().

Each service needed by IOC implementation SHALL be transparently granted to each OS-Application that use IOC by the configurator, so to emulate this just follow b)

2. Problem if MemoryProtection is enabled: The shared memory for the data exchange has to be accessible from both sides. Currently
I am using the predefined Shared Memory Section for the data, but as only trusted OS-Applications have write access to this section,
it´s not possible to use IocWrite_0() in an untrusted OS-Application. I see here some options:

a) disable MemProtection temporarily (not good)

b) change the memory protection set inside IocRead_0(), so that the predefined shared memory is accessible.
I guess, there is already a similar mechanism in CallTrustedFunction().

c) call IocWrite_0() in a trusted function.

I think, 1b and 2b would be the best solution. What´s your opinion or advice?

I don't have perfectly clear to which Shared Memory section you are referring too (IOC or API)?
Could you explain how you want to achieve 2b) and which mechanism of CallTrutedFunction you are referring too?

Errico

[paolo.gai]

yes, they are .... here you can find some information about this project http://www.edas-ev.eu/.

Very Nice! what is the kind of usage the project plans to do with ERIKA?

Ciao,

PJ

[AlTi]

Thank you for your patience,

Each service needed by IOC implementation SHALL be transparently
granted to each OS-Application that use IOC by the configurator, so to emulate this just follow b)

I understand that each OS-Application using IOC needs access to the services that are used by the IOC, if I wrap ioc_common.h in trusted functions
, because of the requirement SWS_Os_00266. I don´t exactly understand what you mean with "transparently granted"?

I don't have perfectly clear to which Shared Memory section you are referring too (IOC or API)?
Could you explain how you want to achieve 2b) and which mechanism of CallTrutedFunction you are referring too?

I´m referring to the section which is defined with

#define SHARED_START_SEC_VAR_DATA
#include "MemMap.h"
#define SHARED_STOP_SEC_VAR_DATA
#include "MemMap.h"

Btw: There should be no problem anymore with the memory protection
if I wrap ioc_common.h into trusted functions, because trusted functions have access to this shared memory.

But I want to explain how I wanted to achieve 2b: If I call a trusted function from an untrusted OS-Applicatoin, there must be a switch inside, that
changes the memory protection set from the calling OS-Application to the memory protection set of the OS-Application that belongs to the
trusted function. I guess, this switching is done in the syscall handler (correct me please if I´m wrong). So the idea was roughly, to copy the needed
parts from the syscall handler into the IOC-functions. But I think, using trusted functions is much easier :D.

yes, they are .... here you can find some information about this project http://www.edas-ev.eu/.

Very Nice! what is the kind of usage the project plans to do with ERIKA?

Ciao,

PJ

ERIKA is used on a Central Computing Unit (CCU) which contains the Battery Management for an aircraft. On the website there are some pictures about
the usage, too:
http://assrv2.haw-aw.de/EDAS/images/EDA ... _Train.jpg
http://assrv2.haw-aw.de/EDAS/images/EDA ... ftware.png

Alex

[e.guidieri]

I understand that each OS-Application using IOC needs access to the services that are used by the IOC, if I wrap ioc_common.h in trusted functions
, because of the requirement SWS_Os_00266. I don´t exactly understand what you mean with "transparently granted"?

It will be the configurator, when it will be finished, that under the hood without explicit configuration, will generate the configuration that will enable the service access.

But I want to explain how I wanted to achieve 2b: If I call a trusted function from an untrusted OS-Applicatoin, there must be a switch inside, that
changes the memory protection set from the calling OS-Application to the memory protection set of the OS-Application that belongs to the
trusted function. I guess, this switching is done in the syscall handler (correct me please if I´m wrong). So the idea was roughly, to copy the needed
parts from the syscall handler into the IOC-functions. But I think, using trusted functions is much easier :D.

The magic is done by the svc instruction so you couldn't simply copy the code. You don't put people in jail giving them the key for the door. :)

Ciao