[Trustable-distros] [trustable-software] "Requirements" for a trustable OS/distro

Colin Robbins Colin.Robbins at nexor.com
Wed Aug 15 15:40:44 BST 2018


Hi Paul,

Presumably memory confidentiality is important too.   
I.e., when the memory is allocated to a different process, the memory does not leak data from the previous owner.
This could also be testable by seeding memory with a known pattern, then allocating memory in a new process and hunting for the pattern.

Regards,

Colin Robbins
Nexor

Tel: +44 (0) 115 953 5541 

-----Original Message-----
From: trustable-software <trustable-software-bounces at lists.trustable.io> On Behalf Of Paul Sherwood
Sent: 14 August 2018 14:56
To: trustable-distros at lists.trustable.io
Cc: trustable-software at lists.trustable.io
Subject: [trustable-software] "Requirements" for a trustable OS/distro

Hi folks,
things have slowed slightly due to the holiday season but I've been discussing operating system requirements with various folks in private and wanted to suggest a couple of things in the hope of getting feedback. As we have discussed previously, one of the criteria for 'requirements' in this context is that they should be testable, so I'm using that to focus the discussion as follows:

1) POSIX compliance
- if the OS is asserted to be 'POSIX compliant' it MUST pass the POSIX file system test suite (we could and should do some provenance checking to ensure that what can be found on the internet e.g. [1] and [2] represents the actual test suite)

2) memory integrity
- generically an OS MUST offer memory to its processes/guests, and MUST ensure the integrity of the memory

- so this leads to the suggestion that we could establish a test which
   - requests some memory
   - populates the memory with a known pattern
   - later interrogates the memory and verifies the pattern

- presumably it would be worthwhile to exercise the test many times, under as much 'stress' of the OS as possible, to verify that integrity is maintained

- for specific use-cases it might make sense to choose a representative or useful allocation of memory (e.g. a video frame buffer for image processing applications), and possibly perform some representative transaction on the result

3) realtime performance and/or deterministic latency
- for some usecases guarantees are required for latency on calls to processes or guests. the guarantees may be fixed or within a tolerance

- again presumably it would be useful to test latency over a long period of time, under various stresses

- Codethink has been doing some work on this in public at [3] - initially our testing has been on Linux-based systems but the test approach should be applicable for other OSes too.

I wonder if readers can suggest additional requirements/tests, either from scratch or based on existing work? Also any feedback about the above approach in general would be appreciated.

br
Paul

[1] https://www.tuxera.com/community/posix-test-suite/
[2] https://github.com/zfsonlinux/fstest
[3] https://gitlab.com/CodethinkLabs/determinism


_______________________________________________
trustable-software mailing list
trustable-software at lists.trustable.io
https://lists.trustable.io/cgi-bin/mailman/listinfo/trustable-software


More information about the Trustable-distros mailing list