On May 21, 12:18嚙窮m, Richard Norman <
r_s_nor...@comcast.net> wrote:
> On Mon, 20 May 2013 15:24:02 -0700 (PDT), alextangent
>
>
>
>
>
>
>
>
>
> <
b...@rivadpm.com> wrote:
> >On May 20, 1:35嚙窮m, Paul J Gans <
gan...@panix.com> wrote:
> >> Mike Duffy <
Use.web.form@website_in_sig.com> wrote:
> >> >Richard Norman <
r_s_nor...@comcast.net> wrote in
> >> >
news:po6ip8t3do61icg76...@4ax.com:
> >> >> Do you have a citation with more information about that idea?
> >> >None. It is simply a guess on my part.
> >> >> It certainly is a proper thing to discuss.
> >> >Probably I'm relating it (overly?) to my IT-biased understanding of
> >> >systems.
> >> >A sophisticated program consists of data structures and program structures.
> >> >Ideally, a good "creator" will attempt to delineate the two so that they do
> >> >not interfere with each other.
>
> >> Not to start an argument,
>
> >Too late!
>
> >> but while what you say here is true,
> >> it was not known in the Early Days of Computing. 嚙畿ack then
Yes, qv Multics. Code was not allowed to be self modifying -- and the
languages used helped in that goal, as did the virtual memory
segmentation model. But then IBM took a different approach; the
operating systems for the S/360 through to the present day Z/ allow
it. I blame COBOL; it had a number of self-modifying features built
into the language. Although IBM boxes now have an NX (no execute)
feature at the page level, it can be turned on and off for that memory
that is in the user's control. The same is true of Windows.
(An aside; the IBM instruction set has an operation that has the
effect of modifying another operation for a single execution. It's an
oddity.)
> One essential protection is
> designation of memory as non-executable because embedding virus or
> trojan code into data is a preferred hacking method. 嚙磅o there are
> hardware methods built into "modern" CPUs to separate data from
> executable code and rather high level privileges are needed to control
> these.
Not if it's memory the user is in charge of. For instance, the stack
in Windows is marked NX as it is a common virus vector, but there's a
non-privileged (i.e. available at the lowest level of security) call
to turn this off.
>
> PC's with 8 bit CPUs and even early 16 bit CPUs didn't have that but
> now all systems do. 嚙磕hether the operating system takes full advantage
> of these controls is another issue.
Virus writers seem to have got round the protection. It's an arms
race.
>
> Incidentally I have done a substantial amount of ROM-based programming
> for embedded systems. 嚙瞑utting data into ROM obviously fails but
> putting executable code into RAM (which really should be called RWM)
It was named after its major feature; random access. The W in RWM is
redundant; it really isn't memory if you can't write to it at least
once. ROM is the wrong 'un and should really be called WORM for write
once, read many.
> was never a problem. 嚙瘩ebugging methods often implement breakpoints
> simply by overwriting the instruction at the desired location with an
> operating system call, usually a special interrupt instruction. 嚙磐ou
> do not want to try to debug programs if you can't modify the code in
> this way and are denied breakpoints. 嚙瞌f course the idea of a virtual
> machine requires treating code as data.
Not all virtual machines treat code as data; VMware, VirtualBox, BOCHS
and so on treat code as code. They execute code directly on the
hardware, but maintain control by requiring the hardware to interrupt
on privileged operations and other exceptions. These are then emulated
by the VM; sometimes the hardware can assist the VM with special
instructions available only to it. Software VMs (JavaVM, CLR etc)
generally emulate all of an instruction set which may not be the
native instruction set of the processor. In general they need an OS to
support them.
Debugging is better done by setting control registers, of which modern
processors have many. They can watch memory for changes, trap on
execution and so on.
Anyhow, interesting though this is, it's seriously OT for T.O.