Re: [JOS-Kernel] Device as a digital resource

[Gilbert Carl Herschberger II]

At 04:26 PM 3/21/00 +0200, Al <[EMAIL PROTECTED]> wrote:
>Of course, this goes for example's sake only, e? I don't think arbitrary
>memory access is exactly what we want in our security manifesto! :)

Security is precisely the reason why I brought up this example. First,
understand that any request can be denied. An object is returned only if a
request is appropriate. A subsystem determines if a request is appropriate.
If an arbitrary request is denied, null is returned or an exception is
thrown. It is the same is any request for RAM.

For non-shared RAM, an object has exclusive access to a block of RAM. If
one object has already opened a block of ram, no other object can open the
same block. For shared RAM, many objects can access the same block.

Arbitrary memory access is essencial part of writing a device driver. A
video driver must access the video buffer. A serial port driver must access
the I/O buffer for the port. An IDE driver must access the I/O buffer for a
drive.

A system process should be granted an arbitrary request for memory. Today,
JOS is implemented only as a system process. JOS has arbitrary and
*unsecure* memory access. That's how we are able to poke characters into
the video buffer.

A ram: sub-scheme must be carefully programmed to enforce appropriate
rules. All of the rules for RAM might be centralized, concentrated into a
URI-aware memory manager. In general, a system process must not use RAM
that contains the kernel or virtual machine.

Everything is a digital resource. RAM is a digital resource, too. This is
not a wildly irresponsible idea. It is not just for the sake of an example.
It shows that memory allocation might interact peacefully with a uniform
device identifier.

Would your program like to examine the current '486 interrupt table? Use a
URI like this:

device:ram:?start=0&end=0x100&access=readonly

In a Java standard class library, there is no read-only byte array. And
yet, this is vital to the function of an operating system. A custom virtual
machine, like decaf, could implement it by adding a read-only property to
the byte array class.

The Java standard class library was not written with the expressed goal of
building a world-class operating system. Maybe the ram: subscheme should
not return a byte array directly. Maybe it should return a MemoryBlock that
has a read-only property.

public interface MemoryBlock {
  public boolean isReadOnly();
  public byte getByte( int index );
  public void setByte( int index, byte v );
}


_______________________________________________
Kernel maillist  -  [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel