-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path00232.html
74 lines (58 loc) · 2.56 KB
/
00232.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>00232.mbox</title>
</head>
<body>
<div><strong>From</strong>: David Walter <[email protected]></div>
<div><strong>Date</strong>: Mon, 15 Jul 2002 13:29:03 -0400</div>
<hr/>
<pre>[email protected] writes:
> On Mon, Jul 15, 2002 at 08:03:55AM -0700, James Morrison wrote:
>> Who delegates where the shared memory is
>
> But, I think, whatever component does now memory management.
>
>> and who has access to it?
>
> Of course, the processes involved in message passing. I've some
> vague ideas on how this could be performed, but because of my poor
> English it's not so simple for me to put them down. Nevertheless,
> if you think it's not wholly time lost, I'll try to do my best.
There is a dependency on someone arbitrating who has control over the
memory. Eventually it boils down to one of two models (oversimplified
but hopefully this will help clarify things)
1. Some priviledged user/process determines which memory is
available for communication.
2. A free for all, anyone can arbitrarily choose to negotiate who
to communicate with, and or which memory to use.
In traditional multi{user,tasking} OS design the kernel or a
supervisory program running with some special priviledge accepts
requests and grants(or denies) communication channels or allocation of
memory [1]. In a microkernel design, this may be left to an
independent 'user space' process, but still it runs with the
priviledge of making the decision.
In [2] the process can access memory as it wants. One problem with
[2] is that, (as in {IBM-PC/MS}/DOS) a mis-behaving or evil process
can access memory which is being used by other processes. In the case
of an errant uninitialized or faulty pointer, the address can cause
_bad_(TM) things to occur.
Bad things include overwriting memory in other programs address space,
including device drivers and system resources. Imagine overwriting
the console driver's interface, or replacing an interrupt vectors
pointer to point to a memory location with your evil routine, then you
can capture keystrokes, or lock the machine.
This type of problem (lockup's or freezing or misbehaviour of
programs) was a frequent occurrence with pc's, up to the current
implementations of windows (non/NT (aka OS/2) kernel).
HTH.
--
Hope springs eternal!
/^\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
</pre>
</body>
</html>