COMP 435 Quiz 2 Study Guide

Computer Security Concepts · UNC Fall 2026 · Unit 1: Trusting the Machine · Covers L05–L14 + the Rowhammer guest lecture

Download as PDF

0. Quiz logistics and how to use this guide

0.1 The six topics Kaki listed on the L14 slide

These are the announced quiz topics, verbatim from the Quiz Topics slide in Lecture 14. Everything in this guide is organised around them.

Extra context beyond the slides: Rowhammer (L12) and the L13 side-channel survey are not on the topic list by name, but L12/L13 are inside the covered window and the official practice set does ask about DRAM bit flips (Q8.2). The practice set also asks nothing about L14 OS material, so treat §8 as insurance, not a priority.

0.2 Lecture-by-lecture scope

0.3 How to use this guide

Each section ends with a Check yourself set whose questions are modelled on the actual in-class practice sheets for that lecture. §10 is a full mock quiz built to mirror the official Quiz 2 practice set — nine questions, same shapes, different numbers and scenarios — and §11 walks the official practice set itself with the released answers plus commentary on why each answer is what it is. §12 is a one-screen cram sheet.

L051. Defining trust

The whole of Unit 1 hangs on one distinction, and the quiz topic list names it first. Get this pair exactly right and several questions answer themselves.

1.1 Trusted vs. trustworthy

So "trusted" is a statement about you — about what your security happens to depend on. "Trustworthy" is a statement about the component — about whether it actually behaves. A component can be trusted and not trustworthy; that combination is exactly what a vulnerability is.

The slides list what trustworthy means concretely. A trustworthy component is secure against:

• intentional, malicious actions,
• accidental actions, and
• third-party actions.

1.2 The Trusted Computing Base

Kaki pairs the definition with a quotation that is worth memorising because it says the same thing from the other direction:

That second framing is the useful one for exam answers. A component is in the TCB precisely because it can break the policy — the OS kernel can read any process's memory, the processor can ignore a privilege check. Being in the TCB is not an endorsement; it is an admission of exposure.

Extra context beyond the slides: the two definitions match because "security relies on it" and "it could violate the policy if it misbehaved" describe the same set of components. If a component could not possibly violate the policy, nothing about your security depends on it.

1.3 The postcard example (know this one — it is the recurring illustration)

Kaki runs the same scenario three times, shrinking the TCB each round. "Mail this for me, please":

1.4 Should the TCB be big or small?

This is a literal in-class practice question (L05 practice Q1) and it is the most likely short-answer opener on the quiz.

Note how this connects backwards to Saltzer and Schroeder: a small TCB is economy of mechanism plus least privilege applied at the architecture level. L14 restates it as the first "feature of a trusted system": the TCB should be small and well defined.

1.5 Honest, but curious

In the postcard story, the honest-but-curious TA does not open the sealed envelope — they follow the rules — but they will happily read anything visible without breaking a rule, i.e. the postcard.

The in-class practice sheet (L05 Q2) is multiple choice, and the correct option is "It can reveal information leaks in protocols." The reasoning: precisely because the adversary stays inside the protocol, anything they learn is leaked by the protocol's own design, not by an attack on it. It is not the most powerful threat model — a malicious adversary who deviates is strictly stronger — which is what makes it an interesting lower bound.

1.6 Check yourself

L062. Hardware as the root of trust

Guiding question from the deck: what must we trust at the lowest level in a computing system?

2.1 The stack we are trusting

Every software security mechanism rests on assumptions about the layers below it. The deck draws exactly this stack, twice (L06 and again in L11):

Read it upward and it is a chain of assumptions. The application assumes the OS isolates processes; the OS assumes the ISA enforces privilege levels; the ISA assumes the hardware implements it faithfully. Hardware sits at the bottom with nothing beneath it to appeal to — which is precisely what "root of trust" means.

2.2 Why hardware is the security foundation

Four bullets from the slide, and they are the four things a "why is the processor part of the TCB?" answer should draw on:

• The processor decides which instructions actually execute.
• Hardware mediates access to memory and devices.
• Software relies on hardware checks to enforce security boundaries.
• If hardware allows software to bypass a boundary, higher-level protections may fail.

2.3 Security boundaries

The examples given on the slide:

• one process vs. another process,
• user code vs. kernel code,
• one user's memory vs. another user's memory,
• software vs. privileged hardware operations.

And the rule attached to it: crossing a security boundary should require a controlled check → that is complete mediation, straight out of Saltzer and Schroeder.

2.4 Hardware-enforced privilege

The canonical mechanism. Not all code should have the same authority:

1. The CPU tracks the current privilege level.
2. Some instructions and resources are only accessible in privileged mode.
3. If a user requests a privileged operation, the CPU traps it to the OS.

All three steps are hardware doing the work. This is why practice Q1.3 — "what assumption made by the operating system has failed?" — has the answer the OS assumed the hardware would prevent user-mode code from modifying protected state. The OS has no independent way to enforce that; it delegated the check to step 2 above.

2.5 Thought experiment: no hardware protection

Suppose every program could read any memory, modify any memory, execute any instruction, directly control devices, and interrupt or stop other programs. This is the L06 in-class practice sheet, and it is a good compact way to rehearse the C.I.A. mapping.

The third practice question — are there guarantees the OS could still reliably provide? — has an answer worth rehearsing, because it is a "root of trust" argument in miniature:

Extra context beyond the slides: authentication survives only in the weak sense that the OS can still ask for a password — it cannot protect the stored credentials or the "is authenticated" flag from being overwritten.

2.6 Trusted systems: standards and process

Two standards named on the slides. Know the contrast between them, not the details.

The trusted-systems process has three stages, and the deck expands each:

2.7 What guarantees do we expect from hardware?

Correct execution

Instructions behave according to the architecture

Restricted operations

Sensitive actions cannot be performed by ordinary programs

Controlled transitions

Crossing into privileged code happens through defined mechanisms

Memory checks

A program cannot freely access memory

2.8 Check yourself

L073. Security properties and verification

Guiding question: how can we determine or test if hardware deserves our trust? This section is the most mechanical part of the quiz — there is a fill-in-the-blank template and you should leave the room able to produce it under pressure.

3.1 Hardware background (311 is not a pre-req)

CPU / processor

Hardware that executes program instructions

SoC

A processor plus other hardware components in one system

ISA

The behavior the processor exposes to software — e.g. MIPS, RISC-V, x86

RTL

A code-like description of hardware behavior and state — e.g. Verilog, VHDL

Signal

A value moving through hardware

Register

Stores a value across clock cycles

Clock cycle

One step of hardware execution

Module

A hardware component with inputs, outputs, and state

The example on the slide is a four-bit counter in SystemVerilog. You will not be asked to write RTL, but you should be able to read this much:

module counter (
    input  logic clk,
    input  logic reset,
    output logic [3:0] count
);

always_ff @(posedge clk) begin
    if (reset)
        count <= 0;
    else
        count <= count + 1;
end

endmodule

The slide's own annotation is the reason it is there: security properties are often specified as "this state should never change in this situation." Hardware has state that persists across clock cycles, so "never changes" is a meaningful, checkable claim about it.

3.2 Architecture vs. implementation — the three levels

This slide reappears verbatim in L10, which tells you how central it is. Official practice Q9 — "can the processor be functionally correct and still create a security problem?" — is this slide restated as a question.

3.3 From security policy to security property

Security policy

A statement of what a system should and should not allow in order to protect its assets

Security property

A precise rule describing behavior that a secure design should always satisfy

Counterexample

A sequence of events showing the property can be violated

The worked pair from the slide:

3.4 The property pattern — memorise this

The three examples the deck gives, which are also the three policies on the L07 practice sheet:

• IF privilege = user, THEN privileged register cannot change
• IF debug interface is locked, THEN debug write cannot occur
• IF authentication has not succeeded, THEN protected state cannot be modified

A "state cannot change" consequent is written formally as a claim about the next cycle's value:

lock = 1  ⇒  config_next = config_current

That is the released answer to official practice Q2.1, and it is the form to reach for whenever the policy says "should not change." Writing config_next = config_current rather than English earns the point cleanly, but the slides are explicit that English or pseudocode is acceptable — "just use pseudocode + math notation, doesn't have to be perfect."

Notice the shape of every counterexample: establish the antecedent, perform an action, observe the consequent fail. Three lines. Nothing more is required — and the slide notes that "a counterexample is not always the full real-world attack, but it can reveal a feasible violation path."

3.5 How do we check a property?

Each has a named limitation on its own slide, and the quiz will want the word:

L09 draws the trade-off as a single axis: testing wins on scalability, formal methods win on completeness. Testing "often takes random sequences in as inputs"; formal methods "often take a formal security property as input."

3.6 Hardware CWEs

Why CWEs? They help researchers and security professionals compare bugs and properties across designs instead of treating every flaw as totally unique.

Extra context beyond the slides: the slide asks "Different from CVE! How?" without answering on the slide itself, so this is exactly the kind of thing that gets asked. One line: CWE = the weakness type, CVE = the identified vulnerability in a shipped thing.

The five example hardware CWEs listed (in both L07 and L09):

• Improper access control for protected resources
• Improper isolation of shared resources
• Incorrect privilege management
• Debug/test interface exposed or insufficiently protected
• Side-channel exposure through timing, power, or shared state

The last one is worth pausing on: side channels are not an exotic curiosity, they are a catalogued weakness class. And the second one — improper isolation of shared resources — is precisely what a shared cache is.

3.7 The debug interface example

The recurring concrete asset across the practice problems. Desired behavior: imagine a boolean debug_mode; only when it is TRUE should the processor be able to inspect the contents of the protected registers. The slide notes that most ISAs only expose behavior and state at clock-cycle boundaries or after the end of an instruction — which is why debug interfaces, which see internal state, are so dangerous when left unlocked.

Property: IF debug_mode = FALSE THEN protected_register ⤳̸ debug_output, or in the simpler if-then form, IF debug_mode = FALSE THEN debug_read = FALSE.

3.8 Check yourself

L094. Hardware bugs, errata and the FDIV case study

Guiding question: where do hardware bugs come from? The quiz topic line is "specifications, implementations, security consequences" — three words that are also the three origins of a hardware bug.

4.1 Errata and the three origins of a bug

But a mismatch between spec and implementation is only one of three cases. The slide adds two more:

Two structural reasons this keeps happening, both on their own slides:

• Hardware bugs are hard to patch post-deployment. You cannot push an update to silicon. Mitigations end up in microcode, firmware, compilers or the OS, and they usually cost performance.
• Increasing design complexity. The transistor-count-over-time chart appears three separate times across the decks. More transistors → a larger attack surface.

4.2 Case study: the Pentium FDIV bug (1994)

The one named historical hardware bug in the course. Know the story, the cost, and the moral.

Extra context beyond the slides: FDIV is a correctness bug rather than a security bug — nobody's secret leaked — which makes it the perfect contrast case for the unit's central claim. FDIV is the case where the architecture was wrong and the harm was obvious. Spectre is the case where the architecture was right and the harm was invisible to every architectural test. Both motivate formal methods, for opposite reasons.

4.3 Bug-finding, revisited

L09 restates the L07 comparison and adds the axis explicitly:

The third leg the deck adds: security experts identifying common weaknesses and documenting vulnerabilities, and the writing of good security properties and specifications — which is what lets the community as a whole vet and check their designs for the same bugs and flaws. That is the CWE programme (§3.6).

4.4 Check yourself

L105. Information flow

Guiding question: how can an attacker learn secret information without directly accessing it? Information flow is the vocabulary that makes the rest of the unit sayable, and the quiz topic line asks for two things: explicit vs. implicit flow, and which security primitives unintended or indirect flows violate.

5.1 Explicit vs. implicit flow

The slide's example, in Verilog-ish pseudocode with line numbers, because the line numbers are how the distinction is taught:

1  input A
2  output E
3  reg B, C, D;
4  assign E = D;

5  if (A)
6      D <= B;
7  else
8      D <= C;

Apply it to the official practice Q3 code and you get the released answers directly:

if (secret)
    x = public_a;
else
    x = public_b;

output = x;

• Explicit flow: x → output (last line — a plain assignment).
• Implicit flow: secret → x (the value of secret determines which branch assigns x).
• Why observing output reveals something about secret: by observing the value of output, an observer may be able to determine which branch executed, and therefore learn information about secret.

5.2 Writing information-flow properties

The deck introduces a notation for "must not flow to," drawn as a squiggly arrow. The AES example on the slide: a module takes key, data and rst as inputs and produces rdy and ciphr.

φ:  key  ⤳  rdy

Read as: information must not flow from key to rdy. (The slide writes the flow relation; the property being verified is that this flow does not exist. Write it as key ⤳̸ rdy, or just say in words "no information flows from key to rdy" — the slides accept English.)

The L10 in-class practice sheet is four of these. Worked:

Extra context beyond the slides: an information-flow property is strictly stronger than a "do not assign" property, and that is the reason the course introduces it. "The key is never written to the debug register" is a statement about explicit flows only. "No information flows from the key to the debug output" also forbids the implicit paths — including timing, if timing is in your set of observables.

5.3 Which security primitives do unintended flows violate?

The quiz topic line names this explicitly, so have the mapping ready.

5.4 Check yourself

t = secret & 1;
if (t)
    log = "odd";
else
    log = "even";
count = count + t;

L106. Caches and timing side channels

The quiz topic line asks for two things: the mechanisms required for a timing side channel, and how timing observations are used to infer secret information. Both are conceptual — you will not be asked to compute a hit rate — but the cache background is what makes the mechanism explicable.

6.1 Why caches exist

The observation that drives the whole memory hierarchy: as capacity goes up and cost goes down, latency gets worse.

You cannot have all three from one technology, so you stack them:

The cache holds temporary copies of selected main-memory locations, and the average access time is

t_ave = α·t_c + (1 − α)·(t_c + t_m) = t_c + (1 − α)·t_m

α    = hit ratio, the fraction of references found in cache
1−α  = miss ratio
t_c  = time to access cache
t_m  = time to access main memory

6.2 Caches are a microarchitectural optimisation

The thought experiment on the next slide makes it concrete. Given

array[0];              // warm up
time(array[0]);   vs.  time(array[1]);

the left is faster, because array[0] was just accessed and is now cached. Conclusion: memory access time reveals something about cache state.

6.3 The mechanisms a timing side channel requires

This is the topic line "conceptually: the mechanisms required for a timing side channel," so here is the checklist. All four must hold:

Remove any one and the channel closes. That framing is also how mitigations are classified: partitioning the cache kills #2, constant-time code kills #1, adding timer noise attacks #3 and #4.

6.4 The simple timing side channel

The victim program from the slide:

if (secret)
    access(array[0]);
else
    access(array[1000]);

The attacker cannot read secret. But they can measure timing, and they see array[0] → FAST, array[1000] → SLOW. Slide conclusion: the secret was probably true.

The debrief slide draws the path, and this diagram is worth being able to reproduce from memory because official practice Q5 asks you to fill in its boxes:

The fully-labelled four-stage chain, which is the sentence to write whenever a question says "why is this an inference rather than a read":

secret → secret-dependent memory access → cache state → timing → attacker

6.5 What is leaking?

The second victim on the slide:

if (password[0] == 'A')
    access(table[0]);
else
    access(table[1]);

Extra context beyond the slides: note the attack is cheap because it decomposes. A password guessed all-at-once is exponentially hard; a password leaked one character at a time is linear. Side channels frequently convert an exponential search into a linear one, which is why "it only leaks one bit" is rarely reassuring.

6.6 Reading a timing trace

Official practice Q4 hands you a table and a threshold. The skill is mechanical — do not overthink it.

The reasoning, in the order to write it: the attacker flushed all four locations first, so every one started slow. After the victim ran, exactly one is fast. Something must have brought C back into the cache, and the only thing that ran in between was the victim. If A, B, C, D correspond to secret values 0, 1, 2, 3, then secret ≈ 2.

6.7 Check yourself

L117. Speculative execution and Spectre

Guiding question: how can cache timing + speculative execution create a complete attack? The topic line is unusually specific — "the steps of the attack and why each step is necessary" — so this section is organised around justifying every step, not just listing them.

7.1 Why processors speculate

When the CPU encounters

if (condition) {
    do_A();
} else {
    do_B();
}

it does not wait to learn the result of condition. It predicts which path will execute and starts the work early. If the prediction is correct → faster. If it is wrong → it must discard the results.

The slide poses the question that opens the door: if the CPU discards the result, does it undo every effect of that execution? Answer: no. Some microarchitectural side effects can remain — such as changes to the cache.

7.2 Spectre, simply put

Three key points from the slide:

• The attacker does not receive the secret as a normal program output.
• The attack creates an indirect path — an implicit flow — from secret → cache state → timing.
• The architectural mistake is rolled back; the cache footprint may remain.

The four pieces the attack needs:

7.3 The victim code

Every slide in this part of the deck refers back to two lines:

if (x < array1_size):
    y = array2[array1[x] * 4096]

Three things to notice before the attack starts:

• The bounds check x < array1_size is correct. The code is not buggy.
• array1[x] is the value that becomes the secret when x is out of bounds.
• The multiplier 4096 spreads consecutive secret values one page apart, so each possible byte value maps to a different cache line. Without it, several secret values would land in the same line and the probe could not distinguish them.

7.4 The steps, and why each is necessary

7.5 The canonical ordering question

Official practice Q6 shuffles six lettered steps. The released order:

And the follow-up, Q6.1 — why does step A not eliminate the attack? The released answer: the processor eventually realizes that the speculative path was incorrect and discards the architectural results; however, microarchitectural effects such as changes to cache state may remain, and the attacker can measure those remaining effects.

7.6 Flush & Reload

The measurement primitive, drawn on its own slide:

flush(array2[0   * 4096]);
flush(array2[1   * 4096]);
...
flush(array2[255 * 4096]);
// ... victim runs ...
time(array2[0   * 4096]);
time(array2[1   * 4096]);
...
time(array2[83  * 4096]);   // FAST
...
time(array2[255 * 4096]);

256 probe locations because a byte has 256 possible values. One fast index → one secret byte.

7.7 The gap — the sentence the whole unit is building toward

The full attack path, with the information flow written underneath — reproduce this diagram and you have answered half a dozen possible questions:

7.8 Check yourself

L12 · L138. Rowhammer and the side-channel landscape

L12 was a guest lecture by Noah Brown; L13 was the group research session. Neither appears by name on the quiz topic list, but official practice Q8.2 asks about DRAM bit flips and Q8.3 asks which primitive they threaten — so the distinction between observing a signal and causing a change is examinable.

8.1 Side channel vs. fault attack — the distinction that is on the quiz

Extra context beyond the slides: Rowhammer is a nice case because it uses a side channel as a tool (timing, to reverse-engineer which addresses share a bank — see §8.4) while being a fault attack in its effect. If a question asks what Rowhammer "primarily" is, the answer is the effect: an unintended change.

8.2 DRAM organisation

Enough structure to explain the attack:

How a read works:

1. A read request is sent to a row.
2. The entire row is copied into the row buffer.
3. Data in the row buffer is sent to the CPU.
4. The row buffer acts as a cache: until a new row is activated, requests are fulfilled directly from the row buffer.

8.3 What Rowhammer is

The physics, in the four beats the guest deck uses:

1. The value of a cell (bit) is stored as charge or no charge in the cell.
2. Reading a row causes charge to leak out of adjacent cells.
3. If enough charge leaks, a bit can flip (Kim et al., SIGARCH '14).
4. Therefore an attacker controlling two rows can write to the row between them — even if someone else's memory is there.

That last line is the security statement: the OS ensures memory stays isolated, and Rowhammer breaks that isolation without ever issuing a write to the victim's memory.

Why the periodic refresh does not save you: charge leakage was known before Rowhammer, so DRAM issues a refresh to all rows roughly every 64 ms, restoring each cell's charge to its full value (or lack of one). Rowhammer accelerates the leakage beyond what those periodic refreshes catch. If you hammer a 1 to a 0 before the next refresh, the bit is permanently flipped — the refresh then faithfully restores the wrong value.

8.4 How to actually hammer (three obstacles)

The deck teaches this as a sequence of naive attempts that each fail for an instructive reason. Goal: flip a bit in Row C.

Remaining obstacle: we only see physical addresses, and we do not know which rows they map to. Page tables translate virtual → physical, but physical → DRAM location is an undocumented vendor function. So the attacker reverse-engineers it — with a timing side channel:

Repeat over large amounts of memory, apply some math, and you recover the address-mapping functions. Bottom line from the slide: by using a timing side channel, we can find rows that map to the same bank — which is what allows us to Rowhammer effectively.

8.5 What Rowhammer buys an attacker, and the mitigation arms race

• Escape browser sandboxes (Seaborn and Dullien, '15)
• Read private RSA keys (Kwong et al., IEEE S&P '20)
• Change host memory from the GPU (Hu et al., IEEE S&P '26)

The defense, and its break:

Mitigations were proposed on both the software side (Brasser et al., SEC '17) and the hardware side (Hassan et al., MICRO '21), and later work broke both — software (Cheng et al., TDSC '19) and hardware (Frigo et al., IEEE S&P '20).

8.6 L13: the pattern across real side-channel attacks

L13 was a research-and-present session. The attacks assigned were Meltdown, Foreshadow, Flush&Reload-style cache attacks, GoFetch, ZombieLoad and Hertzbleed. You are not expected to know the internals of each; you are expected to know the two patterns Kaki put on the wrap-up slide.

The framework for analysing any of them, taken from the assignment instructions — a good scaffold if the quiz hands you an unfamiliar attack:

1. What is the attacker trying to learn or control?
2. What hardware behavior or side channel is exploited?
3. What can the attacker observe?
4. How does the attack turn that observation into useful information?
5. Connect it back to class concepts: cache state, timing, speculation, information flow.

Extra context beyond the slides: the optimisation being exploited is a useful one-word index into each attack — Meltdown and Foreshadow: out-of-order/speculative execution past a permission check; ZombieLoad: internal CPU buffers being forwarded before they are validated; GoFetch: a data-memory-dependent prefetcher treating data as if it were a pointer; Hertzbleed: dynamic frequency scaling, so power behavior becomes timing behavior. In every case an optimisation made execution depend on data it was not supposed to depend on.

8.7 Check yourself

L149. Operating systems security (background)

Guiding question: how does the operating system create isolation and manage access? L14 was taught two days before the quiz and its material is not on the announced topic list — but it was accompanied by a practice sheet, so it is cheap insurance. Read this section once; do not let it displace §7.

9.1 User mode vs. kernel mode

Operating system

Software that manages hardware and software resources, and provides common services for software programs

System call (syscall)

The mechanism by which a program in user space asks the operating system to do something on its behalf

The CPU can operate in several modes; the two common ones are user mode and supervisor (kernel) mode. When executing OS code the CPU is in supervisor mode, where more instruction types and more memory ranges are accessible. Two rules from the slide:

• The processor should never execute user-provided code with supervisor-level privileges.
• System calls are the mechanism for mode transition — the controlled transition from §2.4, seen from the software side.

9.2 The five responsibilities of the OS

Practice sheet Q2 asks for these by name. Memorise the list with its syscall examples:

On the last one the deck is explicit about why it is a responsibility and not vanity: the data structures and code the OS uses to enforce access control, process separation and fair time sharing all reside in memory, so they need to be protected from other code running on the machine.

9.3 Five features of a trusted system

TCB

should be small and well defined

Trusted path

authenticates the OS to the user

Secure start-up

starts in a known good state

Object sanitization

no object reuse — free your memory!

Auditing

audit log tracks any changes

Extra context beyond the slides: "trusted path" runs the opposite direction from the usual authentication story. Passwords authenticate the user to the system; a trusted path authenticates the system to the user, so that a fake login prompt drawn by a malicious program cannot harvest your credentials.

9.4 Four styles of separation

The practice sheet asks you to classify four scenarios. Answers:

9.5 Memory protection mechanisms

Practice sheet Q3 asks which statement best describes base–bounds and segmented memory protection. The answer: "Hardware and the operating system work together to protect the memory of one process from access by another process." Both halves matter — the OS populates the registers and descriptor tables, the hardware enforces them on every access. Neither could do it alone, which is §2.1 in miniature.

9.6 Race conditions

The ATM example. Balance starts at 900; two withdrawals interleave:

The customer withdrew $150 and the balance ends at 800 or 850 depending on which write lands last — either way the bank has lost money.

The L14 practice sheet also asks which principle a TOCTTOU (time of check to time of use) vulnerability violates. The answer is complete mediation: the check and the use are separated in time, so the authorization decision is made once and then relied on at a later moment when it may no longer hold. Complete mediation demands the check happen at every access, not once up front.

9.7 Check yourself

10. Mock quiz

Nine questions in the same shapes as the official practice set, with different scenarios and numbers. Do it closed-book on paper, with a 40-minute timer, before you read §11.

10.1 Questions

len = strlen(secret_token);
if (len > 16)
    buf = big_pool;
else
    buf = small_pool;

memcpy(buf, greeting, 8);
send(buf);

11. The official practice set, walked

These are the nine questions from 435-fa26-ep2.pdf with the released solutions, plus commentary on what each one is really testing and where students lose points. If you only have twenty minutes left, read this section.

12. One-screen cram sheet

Everything the quiz topic list names, in the order you would want it in the last ten minutes before the room opens.