DPAA-PRL Partitioning Inspection

Targeted Component Inspection for DPAA-PRL Partitioning Violations

This project is to satisfy a deliverable for the Celestial_Program. This is the purpose as described to the customer:

   DDC-I's Targeted Component Inspection service can be used to
   increase the confidence that a specific version of a DDC-I provided
   Deos component satisfies a particular property. This service is
   intended to support pre-certification complete activities, such as
   flight test, where elevated confidence in some constrained property
   is required prior to the component completing all verification
   activities.
   
   DDC-I is proposing to provide this service for the DPAA PRL
   specifically targeted at ensuring the DPAA PRL will not cause
   unanticipated time or space partition effects.

This project will perform an inspection, i.e., not a formal review. The intent is to use your engineering judgement to increase confidence that the DPAA-PRL does not cause time or space partitioning violations. The inspection is not concerned with proper operation of the driver itself. Of course if an operational defect is found during inspection, make sure to record it.

Matt has confirmed that all DPAA-PRL hardware resources are not writable by user-mode software. This means that any software running in user mode can be ignored.

Kernel mode software must be inspected to ensure:

No time partitioning violations

Time partitioning can only be impacted by code executing within critical sections. Any code outside of a critical can be ignored for time partitining purposes. Code within a critical should not contain abnormally long criticals, i.e., criticals that have a duration substantially larger than what would be expected if the component was verified. E.g., unbounded loops, large amounts of code, etc.

No space partitioning violations

There are two aspects, software induced, and hardware induced.

Software induced are effects directly caused by the execution of driver software. These are coverd in the Deos Library code checklist sub-section: "Kernel mode Libraries Only:". For example ensuring no incorrect pointer dereferencing.

Hardware induced means that the driver cannot cause the hardware to access memory other than the intended platform resources.

Loss of kernel Availability

Time partitioning can be violated if code executing in kernel mode causes the kernel to stop operating due to an exception, or corruption of kernel data structures, including the thread's kernel stack. The exceptions for PowerPC are listed in the kernel 10.8.0 User Guide section "8.5.3.2.2. Exception Handling on PowerPC Processors". The relevant exceptions are:

• DSI/ISI -- mostly covered by pointer dereferencing issue above
• Alignment -- See /scm/Deos/docs/reference-data/cpu/ppc/freescale/EREF_RM.rev1.pdf section 8.8.6. Note especially restrictions on load/store conditional instructions.
• Trap/Debug -- Only caused by trap instructions.
• Floating point/Altivec -- Kernel mode code must not use floating point/SIMD.
• Hypervisor call -- Not permitted

Calls to DEOSKERNPPI functions must be appropriate.

Status

File	Assignee	Status	Comments
bman.cpp
bman.h
bman_portals.cpp
More to come...

Status is Blank (not started), Work, Done