SCENARIOS

  - Pure KESO running on top of CiAO
    - easily possible:
      - only safe domains, unknown to CiAO
      - only unsafe domains, unknown to CiAO, no protection at all
    - posing problems:
      - mixed safe and unsafe domains
        - requires mapping of domains to CiAO applications, which needs (I1), (I2)
        - KESO's infrastructure code (I3)
  - safe KESO / legacy CiAO
    - only safe KESO domains mapped to a single trusted application
    - legacy trusted and non-trusted CiAO applications


ISSUES

 (I1) Separation of CODE belonging to different domains at compile time. Needed to
      compile portions safe, others unsafe. Unsafe code needs be grouped to enable
      CiAO's MPU configuration.

 (I2) Separation of DATA belonging to different domains at compile time.

 (I3) KESO's infrastructure code is invoked in non-privileged mode. It assumes that
      no invalid values other than the NULL value is passed as parameter. Can this
      be guaranteed in an unsafe application? (Q1)

 (I4) KESO's infrastructure data structures will need to be protected from modification
      by a non-trusted/unsafe application. Thus, the data structures will need to be
      placed in a read-only memory region. Portions that require write access will be
      restricted to be modified by privileged code only. (Q2)

OPEN QUESTIONS

 (Q1) When KESO is compiled unsafe, which checks are omitted? Which effects can be
      caused by this?

 (A1) - Null Pointer Checks

      - Array Bounds Checks

      - Out of Memory Checks

      - Class Cast Checks

      - Alloc negative Array size?

      - Array Store Exception?

 (Q2) Which data structures are provided by KESO? How frequently are these data
      structures used, are they used read only or need they be modified?

INPUTS for a PURE KESO configuration
                                              |
                CiAO Side                     |                   KESO-Side
              (provides OS)                   |                (provides APP)
                                              |
  OS configuration(**)  APP configuration(*)  | KESO configuration(*)     APP Sources
     (vdm file)          (config.xml)         |    (kesorc file)          (Java Files)
         |                                    |          |                     |
         |                                    |          |                     |
         |                                    |          |                     |
---------|------------------------------------+----------|---------------------|-------------
OUTPUTS  |                                    |          |---------   ---------|
         |                                    |                    \ /
         L---> CiAO variant                   |   APP transformed sources w/ KESO runtime
               (config/...)                   |   (C files, generated to CiAO config dir)
                                              |
                                              |
                                              |
                                              |
---------------------------------------------------------------------------------------------

NOTES
(*) both the KESO configuration and the CiAO APP configuration specify system
    objects such as Tasks and Alarms, their properties such as priorities or
    actions, and OS options such as the scheduling policy. The definitions in
    these files need be consistent. Consistency is not checked by tools, but
    the build process will probably fail if the two files are inconsistent. At
    a later point, we will hopefully be able to automatically generate a valid
    config.xml from the keso configuration or the KESO generated OIL file to
    solve this issue.

(**) The CiAO OS configuration manually configures the OS facilities that the
    generated variant needs to provide. If the generated OS does not provide
    all facilities required by the application, the build process will fail.
    There may be some properties where the build process will work but the
    resulting system won't behave as expected, e.g. if the OS implements a
    different preemption model than that expected by the application. Normally,
    the requirements for the variant could automatically be determined from
    the application configuration (config.xml or kesorc), and this is just
    what most OSEK code generators do. With the p::v toolchain, this seems
    hard to implement, if possible at all.

FIXMEs

