or *promiscuOS* removal of segmentation in networked and application layers [storage and execution] of an already existing OS. other characteristics/symptoms:
[one methodology would be to implement more or less from scratch on simple hardware (abstraction of an abstraction - inoperative but then isn't really OS rather ap0201 devices), another is to patch a free OS such as GNU/Linux or GNU Hurd]
see also http://lemonodor.com/archives/001016.html - gracle
characteristics:
*a) self display [also in context of say fm01web - actively displaying rather than as response - certain notion of activity]
b) all process memory is readable and writable by any process(and apps to misuse this) - there is no hierarchy, no model of secure computing
c) able to generate, disperse and run mobile code between machines
d) pluggability - small apps can plug themselves together a la Unix model or a la Pd (but not in such graphic manner)
and in relation to pluggability streams rather than static segregated files*
(inetd allowing for execution of incoming code on certain ports (some sort of notification between such enabled machines)- this is implementation specific)
see wiki also - can envisage networks of virtual machines exchanging/containing and authoring streams of pseudo data and pseudo code
notes from http://www.1010.co.uk/tech.html
also relates to crash
strands here:
0) promiscuous OS at level of OS or of vm on top of OS (q levels abstraction) 0.5) pluggability is currently obscured by issues of security. promiscuity-mobile arbitrary code execution pluggability-model
1) bootable cd which could include clisp? and grid style software running generated code nodes and/or ap02 style software → need decide on format for generated code - micro-code approach or lisp style
executing arbitrary/generated code across networked machines working at sufficient level of abstraction/interface
question of interface micro-macro language/abstraction with data as micro-level = code without arbitrary translation (a la ap02)
rules of association and of expression
- ad-hoc expression through use of a protocol such as OSC? or raw data streams for ad-hoc visualisation through an application such as pd
2) crash influenced work with patched memory management:
inserted notes:
1) working on crash issues/questions and perhaps towards promiscuous OS / promiscuous GNU/Linux project which features:
a) no access control b) promiscuous net I/O and attachment to all I/O as data code/sources for flat code/data memory (again question is of a VM model for this or just rebuild/patch kernel and overlay apps c) executes any code/data d) nor protected mode (but priveleged kernel avoids system crash?)
thus research which includes following urls:
http://www.linux-mag.com/1999-07/kernel_04.html http://www.phrack.org/show.php?p=61&a=7 http://www.cs.umb.edu/cs444/classnotes23.html http://lists.rlug.org/pipermail/rlug/2004-March/002729.html
segfault: occurs when an invalid page table entry is encountered by the MMU - a hardware trap (like an interrupt see arch/i386/kernel/traps.c) which causes kernel to jump to page fault handler (arch/i386/mm/fault.c) - if caused by virtual memory ref to a bad address page fault handler will kill process
note we're just in userspace as in kernel space is all physical memory (oops in this case)
relevant function is do_page_fault
what happens if we ignore page fault?
1) if re-executes faulty instruction = infinite loop 2) if skip instruction what is destination register of the load?
other notes on vm :
process makes reference to place in virtual memory space not yet existing in physical memory
virtual addresses are converted to physical addresses by processor based on information held in tables maintained by OS (how this works)
if page table entry (PTE) is invalid → page fault flags in PTE contains valid and invalid flag
access control is also in page table - fields in PTE are processor dependent (ie. if accesses/writes/tries execute memory it shouldn't)
Linux has 4 level hierarchical page table thing VMA - virtual memory area descriptor is a high level desciption of region of process's page table - see exploit as above
see also:
mm/ pageattr.c fault.c init.c pagetable.c
2) for promiscuous Linux note OS/VM interface in sbcl:
src/runtime/linux-os.c
which is one of files changed by Lazy-sbcl.diff:
from peter van eynd: http://pvaneynd.blogspot.com
"The patch is at the wrong place (linux-os.c) because there is no abstraction layer for 'get memory' and 'handle memory fault'."
——————————————————————
notes 27 May 2005+
3) rather patch kernel so that: a) all pages are writeable and readable (how easy is this?) b) we choose a random page if a page is not available for whatever other reason
_
3 June 2005+
self-display as essential - some sort of strace or gdb style stepping through kernel and application code required - how this could be automated achieved.
also look at old self[cpu] app which does self-display of processor registers
why it forks?
forks itself to make use of ptrace functionality to monitor registers
what level of self-display (level of abstraction of display) [ also brings to mind dual time/freq domain idea for cur/gdapp style app]
7 June 2005+
simply patching do_page_fault in arch/i386/mm/fault.c so does not send SIGSEV would work [test simply by handling SIGSEV in own code] but then would just repeatedly page fault - need allocate memory elsewhere within random process or all process memory is read/writeable by all processes in page table (and if is unallocated on page fault we allocate)