2.9: 3.31: intro:
. certain attributes of data are essential to security;
eg, by retagging arbitrary data so that it is
usable as a pointer to code,
we can treat malware data as instructions to follow .
. generally all data can be tagged
just as it is done by xml .
. there are 2 possible ways to enforce
process isolation and ROM attributes:
# HW (hardware) mem'mgt,
# VM (virtual machine) mem'mgt .
. hardware mem'mgt can enforce VM mem'mgt:
the VM's run-time exec never needs to change;
so, HW mem'mgt can see that code as const;
also, any file that the VM is trying to interpret
can be treated by the HW mem'mgt as
something that only the VM process can modify .
. finally, the VM has its own process space
and this should keep other processes
from corrupting its work space .
. for the rest of this article,
we are referring only to the VM process,
so a "user process" in this context
is a virtual app that our VM is executing .
. there are 3 possible ways to ensure that
tags are not corrupted by a user process:
# a read-only permission;
# only VM can modify;
# a dual-owner mem'mgt strategy:
. put the tags and pointers in supervisor space,
while the data is still in user space .
. the symbol table contains object type.tags
(though subtype.tags can be on the stack);
and, the symbol table can be in ROM
along with the code its holding the symbols of .
. HW mem'mgt may not support dual-owner mem;
but it can isolate the VM,
and that can implement dual-owner mem .
2.9: the 2 implementations of dual-owner mem:
# the type.tag way:
. when user's want to implement tagged data,
they define datatypes that add type.tags;
and then, by well-understood mechanisms,
the VM recognizes type.tags .
# the xml way:
. xml inherently has a tree-like shape;
and, the usual way we define trees
is to define nodes of some constant size;
therefore, trees entail a lot of pointers:
each node is 3 pointers:
# 2 pointers to child trees,
# a pointer to symbol for the xml tag .
. a tree object has 2 parts:
the collection of same-size nodes
fit neatly in one part;
and then the odd-shaped data blocks
(like the text that xml is tagging)
are arranged in a heap within a 2nd part;
the first word of the tree object
is a pointer to the 2nd part .
. the xml tags can provide permissions
such as ROM or supervisor's space .
. for a read-only xml tree
we can save space like so:
. there are 2 types of xml objects:
# atom: (tag, ptr to data);
# enclosure:
(tag, number of items, item#1, ... item#n),
where item is a ptr to atom or enclosure .
. this way still gives us a tree-like structure
that is easy for robots to read,
in contrast to the xml style
that needs expensive parsing
before being quickly readable .]
2.9: resource display:
. when we say the "resources of a process"
we mean the other objects or programs
that a process can have access to .
. the "resource display" is a set of
pointers to these resources .
( all pointers are just indices;
most "pointers" are indexing the local symbol table;
whereas resources are indices into
an array of system modules).
. the resource display
is considered to be a dual-user space;
because, the supervisor can rewrite the display,
while at the same time the owning process
can only read it, not rewrite it .
2.9: how a VM offers protection:
. every object creation address
is recorded by the kernel (the supervisor)
...
that seems too complicated and wasteful
so, why can't a VM system alone
provide the needed supervisor-user separation ?
. here's how the kernel handles a
stack smasher attack:
. normally in code there is an evil alliance
between the coder and CPU
that is cutting out the kernel
from having an intermediary control .
. in a VM, on the other hand,
code is interpreted by the kernel not the CPU .
. code typically offers to accept input
that will be too large for a given input buffer
which is on the stack .
. code typically does not offer to
check buffer limits
so then when filling the buffer
it overwrites a return address,
and control is diverted to a malware module .
. but when interpreted by a VM,
the user code could not have established
a stack presence
without asking for an array to be placed there,
and once the VM is asked to
write to such an array
it knows to check the array's boundary limits
before writing to it;
(this might be slow but it's not space-wasting )
-- if you want only energy-efficient code,
run only code that you can trust,
and that you know won't change
because it's tagged as ROM .
. the supervisor is defining the data structures,
and can tag certain fields as being system-only
so that it knows that a user process's code
is not allowed to modify it .
. as it executes the user code,
it's doing the type-checking
which includes reservation of system tags
for access only by system code .
mis: complicated scheme obviated by VM control:
. each system-only field has an address;
and that address can't change
without system cooperation;
that address is in a sorted list or a hash & sort,
and in the kernel space;
but, similarly in a vm
the system checks that every object is a
ptr to modules symbol table in kernel space
so the symbol table entry
has permissions and data type .
mis: symbol-table isn't hardware-isolated:
( using the HW mem mgt unit to retain control,
pieces of data are tagged for meaning
just as in xml
and tags are in kernel space
using a twin system of mem allocation
...)
--. this is already being done:
the symbol table can be in kernel space;
...
so the idea added to that here is
the symbol table can belong to supervisor space ?
how can hardware's mem mgt provide isolation ?
No comments:
Post a Comment