License Manager Project

2110-002-623
License Manager Support for Deos Development environment.

Description

This project has transformed into an evaluation version of the Kerenl that will be shipped when potential customers wish to demo the product. Once a customer has purchased Deos, the existing license check (i.e., the Integration Tool check) has been deemded sufficent.

Requirements

The requirement that has been offered:

"Theft must be prevented, or as a minimum made very difficult."

In the context that we will be conducting business, the decision to steal can likely be treated as a rational, economic decision. In other words, the potential theif has a choice: Do I create the thing myself, or steal a copy from someone else? The path chosen is likely to be the one that's the least expensive way to meet the thief's requirements.

With the premise above in mind, how do we raise the cost to steal higher than the cost to make? One way would be to add the equivalent of locks to the things we don't want stolen. Here we are trying to make theft "very difficult." These locks would prevent one to use the thing we want to protect, and thus raise the cost to steal hopefully higher than the cost to make. However, since we will be supplying technology to technologists, in a sense selling a padlocked thing to locksmiths, this technique will easily fail to tip the steal versus make-my-own trade off away from stealing. Any lock we can invent can easily be defeated by the locksmith. Instead, what we need to do is to make the thing we are protecting of so little perceived useful value that it is literally not worth stealing. By doing this we can meet the requirement that "theft must be prevented," as no rational thief will expend the calories to steal something that doesn't fulfill their needs.

We will assume in the above that the thing that we need to prevent being stolen is the Deos kernel executable object code. We will assume the workstation tooling is already protected via existing DDC-I licensing technology, and the intellectual property inherent in our DO-178B artifacts will not be made available, hence safe from theft. To summarize:

• The OpenArbor workstation tooling is already protected via licensing technology that renders it useless past a certain date.

• The DO-178B artifacts will be protected by never providing an opportunity for them to be copied. In other words, they are kept protected by DDC-I and only shown to customers and certification authorities when they need to be inspected.

The above leaves the requirement to protect the Deos kernel from theft, specifically theft during customer evaluation. We want to provide a Deos kernel that allows for honest and fair performance evaluations against other time and space RTOSes, and provides for customer training and preliminary application design; however outside of this context, we want the kernel to be perceived as worthless.

Implementation

Our original ideas all revolved around a similar theme: Add some checks to the Deos kernel that if false would prevent the kernel from executing. The obvious problem with this approach is that the decision on whether to execute or not resides within the thing we are trying to protect, hence it becomes trivially simple to patch the kernel, thus removing the check.

Instead, we think a better approach is to provide to potential thieving customers an "evaluation" kernel that is almost fully featured, or more precisely, featured enough for evaluation, but insufficiently featured for revenue service. This evaluation copy will literally be worthless outside of the evaluation environment.

Remove Features

Specifically, the evaluation kernel will:

• Only execute with the debugServicesHonored (DBSH) attribute set. All kernel code checking for this attribute will be removed, thus preventing one from patching back in the feature. This will render the evaluation kernel incapable of enforcing time and space partitioning. We feel this would be the single most effective subtraction from a potential thief's perceived value of the kernel. Why would one contemplate using the Deos evaluation kernel in a revenue system when it doesn't even provide the sole reason one was thinking of using it for?

While the above may be sufficient to deter theft, we can do more to reduce the evaluation kernel's value if used outside an evaluation:

• The checkKernelFileIntegrity() APIs will be altered to always return true. This will make it impossible to use the evaluation kernel to meet file integrity checking requirements inherent in most embedded products.
• The Built-In-Test (BIT) APIs will be removed. This will make it impossible for users to use the evaluation kernel to meet their safety analysis requirements.
• The Deos password check that is required for certain APIs will be removed. As with the first bullet above, this will prevent one from claiming low design assurance code can be safely executed alongside high design assurance code. In other words, without this check it would be possible for low design assurance code to disrupt platform availability.
• The kernel's behavior and or performance starts degrading after some semi-long period.
  • The above needs more investigation to determine an acceptable value for "semi-long." The risk is that if we pick a value that's too short, it may make Deos come out unfavorably in a customer designed performance evaluation. On the other hand, if we pick a value too long, the feature loses effectiveness as a deterrent. There was discussion of a notion that after so many system ticks, the evaluation kernel would do something, e.g. slow down, reboot, etc; however we couldn't reach agreement on the proper number of system ticks to set the threshold to. Opposing viewpoints centered on the worry that a potential customer would be running some semi-long performance evaluation, and hence trip over the threshold. Other ideas such as limiting the number of threads that could be created met a similar fate. Also, this feature likely could be thwarted by removing the decision via a patch to the kernel binary.
• Remove the check to prevent a process from writing to the kernel file system.
• Remove support for the Power Down Look Ahead (PDLA) call (i.e. make it a no-op).
• Remove support for Deos PAL Machine Check Exception (MCE) handler on the Power PC (PPC) architecture (this means no Error Correcting Code (ECC) memory support for the PPC).

The above feature removals will not prevent an honest and fair evaluation of Deos performance against other time and space RTOSes, and it will not prevent training and preliminary customer application design.

Show Due Diligence

A concern has been raised about the potential for the (legitimate) user to inadvertently use the evaluation kernel in a real product. When this happens (I say when because we all know this will happen some day) we need to be able to show we did everything reasonable to try and prevent such an error. The following steps will be taken:

• Documentation will be provided warning users to avoid using the evaluation kernel in a environment where safety and or quality assurances are required.
• We envision an extension to the Deos integration tool where the evaluation kernel's feature provider XML file (the mechanism we see as forcing DBSH true in the registry), can halt and wait for user affirmative agreement to generate a registry if it detects via the feature provider XML file that a registry for an evaluation kernel is being generated.
• The evaluation kernel will contain code that executes at kernel start up that checks to see if DBSH is set within the Deos platform registry. If it is not set, the evaluation kernel will halt. Implementing such a notion will allow us to show that the user would have had to explicitly make two undetected mistakes:
  • They would have had to officially integrate a non-verified kernel into their product. In other words, they would have had to ignore our and certification authority objectives that state software integrated on the product must be traceable to documentation showing the software has been verified and validated. Such a mistake would be easily caught in a pre-certification audit where they attempt to trace the kernel's integrity key value (CRC) to the appropriate Software Accomplishment Summary (SAS). Since the evaluation kernel would not have a SAS, the mistake would be caught at this time, prior to deployment.
  • They would have to fail to satisfy documented software/software integration objectives, specifically running the qualified verification tool known as 'regchk' against the Deos platform registry. If they had run regchk, they would not have been allowed to formally use the result as registries with DBSH set will cause regchk to fail verification.

Packaging

The evaluation kernel will be yet another kernel variant, much like the debug and critical timing kernels are variants. However, we suggest that the evaluation kernel be packaged as a stand-along distribution much like the current Deos kernel component is packaged. Our rationale for this stems from the need to reduce impact on exisitng DESK tooling (hyperstart configuration files for example), and the realization that the evaluation kernel will likely come with a debug version much like the "real" kernel does. Therefore, we recommend the evaluation kernel be built into a kernel-evaluation-<version>.zip alongiside the non-evaluation kernel's kernel-<version>.zip file.

Rationale for debug evaluation kernel: As part of an evaluation, customers may need to develop a Board Support Package (BSP) for the board they will be performing the evaluation on. A debug kernel is used to assist BSP development.

Status

Milestones	Due Date	Estimated Delivery	Delivered	Percentage Complete	Estimate
[1] Eval. Release	15-JUL-2009	05-AUG-2009	05-AUG-2009	100%	184

The Evaluation Kernel is all that will make the 30-SEP-09 Bach deadline. Further work, if any, will be accomplished in a later release.

[1] Eval. Release

Refer to the discussion tab for information. Once we have an agreed upon approach (per the discussion) we'll document the plan here.

Task	Dependency	Assignee	Original Estimate	Elapsed	Remaining
1.0 Design/Implement Scheme	None	Ryan, Matt, Mike	80	75	0
1.1 Test Scheme	1.0	Ryan, Mike	40	98	0
1.2 Deos "Setup.exe" Package	1.1	Ryan, Mike	24	5	0
1.3 DDS Eval. Release	1.2	Mike	40	4	0
Totals			184	182	0