Exercise 2: What ELF/PE Carry That LC-3's Own Model Never Needed — Possible Solution
====================================================================

WHAT LC-3'S SIMPLE MODEL NEVER NEEDED
------------------------------
Per assembly1-9, LC-3's own executable model is essentially a flat
block of bits, loaded starting at whatever address .ORIG specifies,
with no further structure or metadata describing how different parts
of that block should be treated once loaded. LC-3 has no privilege
levels and no memory protection at all (per assembly2-8's own
comparison table), so there was never any reason for its executable
format to describe anything beyond "here is the code and data,
starting at this address."

WHAT ELF/PE GENUINELY NEED TO CARRY INSTEAD
------------------------------
Per this chapter's own explanation, a real x86-64 executable format
has to carry MEMORY PERMISSION information per section — explicitly
marking which parts of the program are code (should be executable),
which are data (should be writable), and which are read-only
constants (should be neither writable nor treated as executable).

WHY THIS IS DIRECTLY TIED TO ASSEMBLY2-8'S PAGING MATERIAL
------------------------------
Per assembly2-8, x86-64's paging system enforces memory protection on
a PER-PAGE basis, with the OS setting up those protections through
the page tables it manages. The OS has to get the correct permission
information from SOMEWHERE in order to configure those page-level
protections correctly when it loads a program — and per this
chapter's own explanation, that's exactly what the ELF/PE file format
itself supplies: the file format is the literal source of the
section-by-section permission data the OS loader reads in order to
set up the real, hardware-enforced page protections assembly2-8
described. Without that information encoded somewhere in the
executable file itself, the OS would have no way to know which parts
of a freshly-loaded program should be allowed to execute, which
should be writable, and which should be neither.

WHY THIS WORKS AS AN ANSWER
------------------------------
It identifies specifically what information ELF/PE carry (per-section
memory permissions) that LC-3's own flat, unprotected model never
needed to represent at all, and explains the direct causal link to
assembly2-8's own paging material — the file format isn't just extra
bureaucracy, it's the actual source data the OS uses to configure
real page-level protection.