Exercise 1: sys_write() Is Exactly as Isolated as sys_read() — Possible Solution
====================================================================

THE TEST
------------------------------
    proc_x = kernel.create_process(num_pages=1)
    proc_y = kernel.create_process(num_pages=1)

    syscall.sys_write(proc_y, 0, b'PRIVATE-Y')
    before = syscall.sys_read(proc_y, 0, 9)

    syscall.sys_write(proc_x, 0, b'X-OVERWRT')   # X writing to X's OWN vaddr 0

    after = syscall.sys_read(proc_y, 0, 9)

RESULT
------------------------------
    process Y's own data before X writes to X's own vaddr 0: b'PRIVATE-Y'
    process Y's own data after: b'PRIVATE-Y'

Y's own data is completely unchanged by X's write, even though both
processes used the identical virtual address (0) for their own
operations.

WHY THE SYMMETRY BETWEEN sys_read() AND sys_write() ISN'T A COINCIDENCE
------------------------------
Both methods share the exact same structural pattern: walk the write
or read in page-sized chunks, and for EVERY chunk, call
pcb.page_table.translate(current_vaddr) using the pcb THAT WAS PASSED
IN -- never any other process's own PCB, and never a raw physical
address supplied directly. When X calls sys_write(proc_x, 0, ...),
the only page table involved anywhere in that call is proc_x's own --
proc_y's own page table is never even looked at, let alone touched.
There's no code path by which X's own write could resolve to Y's
own physical frame, because "translate through the CALLER's own page
table" is baked into both methods identically, not just one of them.

WHY THIS MATTERS AS ITS OWN, SEPARATE CHECK
------------------------------
Finding 2's own demonstration only tested READS. It's a reasonable
question whether a real implementation might have gotten sys_read()
right while still leaving sys_write() vulnerable -- perhaps by
accidentally accepting a raw address, or by forgetting the same
translation discipline on the write path specifically. Testing
sys_write() independently, with a genuinely different process
writing to the SAME virtual address another process is using,
confirms the isolation property holds for BOTH directions of the
interface, not just the one direction the chapter's own worked
example happened to demonstrate.

WHY THIS WORKS AS AN ANSWER
------------------------------
Constructing a scenario where isolation failing would be immediately
and unambiguously visible -- Y's own real data literally changing
value -- and confirming it doesn't change, verifies sys_write()'s own
isolation directly rather than assuming it must be fine because
sys_read() was already shown to be fine.