CS Open CourseWare

Assignment

radu.mantu — 2026-07-28T15:20:06+03:00

@@ -1,7 +1,5 @@
  ====== Assignment ======
- 
- <hidden>
  
  ===== 01. Overview =====
  
  The goal of this assignment is to implement a tool based on [[https://man.archlinux.org/man/perf_event_open.2.en|Linux Perf Events]] that is able to monitor main memory accesses performed by another process.
@@ -75,6 +73,4 @@
  
  ===== FAQ =====
  
  :?:
- 
- </hidden>

GhostTag Apocalypse

cezar.zlatea — 2026-07-18T02:15:24+03:00

@@ -1,320 +1,233 @@
- ====== Hackathon: GhostTag Apocalypse ======
+ ====== GhostTag Apocalypse ======
  
- ===== Scope =====
+ ===== Challenge overview =====
  
- GhostTag Apocalypse is a firmware, security, and BLE simulation challenge.
- Students implement the protocol of an nRF52840 tag that must be found by
- authorized gateways without transmitting a stable identifier.
+ The Internet is unavailable, GPS is jammed, and only a sparse network of BLE
+ gateways remains operational. Your task is to complete the firmware protocol
+ for battery-powered rescue tags that must remain discoverable without
+ broadcasting a permanent identity.
  
- The challenge combines:
+ The protocol must survive unstable power, reject forged and replayed packets,
+ limit flash wear, and remain within a strict energy budget. The final system is
+ tested as a multi-device nRF52840 swarm in Renode.
  
-   * C code for the protocol;
-   * SipHash-2-4 for ephemeral identity and authentication;
-   * Zephyr firmware for ''nrf52840dk/nrf52840'';
-   * Renode simulation with multiple boards and a positional BLE environment;
-   * Automated validation, HTML report, and execution in Kubernetes.
+ This is an approximately 8-hour firmware challenge. You will work only in:
  
- This is a hackathon challenge, not a complete protocol for a real product.
- It does not fully cover secure provisioning, key protection, replay attacks,
- radio certification, or a complete privacy evaluation.
+ <code text>
+ firmware/ghost_protocol.c
+ </code>
  
- ===== Challenge Status =====
+ The public API, application code, gateway firmware, simulation scenario, and
+ validation rules are fixed contracts.
  
- ^ Component ^ Status ^ Remarks ^
- | Challenge code | Ready | Local commit ''29a2b3d'' on branch ''nrf52840-swarm/ghosttag-apocalypse'' |
- | Student starter | Ready | Contains exactly 3 TODOs in ''firmware/ghost_protocol.c'' |
- | Native tests | Ready | SipHash vectors, rotation, tamper, wrong seed, and leakage check |
- | Zephyr build | Ready | Tag and gateway for ''nrf52840dk/nrf52840'' |
- | Renode simulation | Ready | Tags, gateways, clones, deterministic positions and BLE range |
- | Validator and report | Ready | Produces ''validation.json'' and ''output/report.html'' |
- | Platform integration | Ready in repository | Manifest exists for the scenario and the Showcase Job |
- | Local reference validation | Passed | Last local evidence: 6/6 tags, 6/6 rotated, 75 rogue packets rejected |
- | Kubernetes cluster | Healthy | All 3 nodes are ''Ready'', no failed pods, public health 200 |
- | Active student scenario | No | Platform still uses ''rp2040-sensor-filter-tinyml'' |
- | GhostTag image in registry | Unconfirmed | Image must be rebuilt, pushed, and verified before activation |
- | GhostTag showcase | Not running | Job ''ghosttag-apocalypse'' is absent |
+ ===== Read this documentation thoroughly =====
  
- ===== What Is Already Implemented =====
+ <note important>
+ Do not start coding before reading every file in this section, in order. The
+ fixed C header and the complete problem statement are authoritative.
+ </note>
  
- ==== Radio Contract ====
+   - ''problem/problem.md'' -- the complete protocol, journal, recovery, energy,
+     and acceptance contract.
+   - ''firmware/include/ghost_protocol.h'' -- all public types, constants,
+     callbacks, and function signatures.
+   - ''firmware/ghost_protocol.c'' -- the starter implementation and the six
+     TODOs you must complete.
+   - ''firmware/tests/test_protocol.c'' -- the fast public tests and the expected
+     storage behavior.
+   - ''renode/README.md'' -- the files exposed for the simulation and the
+     reset/attacker sequence.
+   - ''renode/generate_swarm_resc.py'' and ''renode/run_test.sh'' -- how the swarm
+     is generated, executed, and passed to validation.
+   - ''docs/renode_primer.md'' -- the nRF52840 machines, BLE medium, provisioning
+     region, persistent journal region, and UART evidence.
+   - ''docs/exercise_guide.md'' -- the recommended solution order and the three
+     feedback layers.
  
- The BLE payload is exactly 28 bytes:
+ The values and byte layouts below are a summary. If this page and the fixed C
+ header differ, follow the header and ''problem/problem.md''.
  
- ^ Bytes ^ Content ^
- | ''0..1'' | Company ID ''0xF00D'' |
- | ''2'' | Protocol version ''2'' |
- | ''3'' | Flags |
- | ''4..7'' | Rotation epoch, little-endian |
- | ''8..11'' | Public sector, little-endian |
- | ''12..19'' | Authenticated ephemeral identifier |
- | ''20..27'' | Authentication tag for bytes ''0..19'' |
+ ===== What you must implement =====
  
- The packet does not contain the stable ID of the device. The radio identity
- changes at every epoch, and the gateway verifies the packet using the small
- authorized key space of the sector.
+ Complete the six TODOs in ''firmware/ghost_protocol.c'':
  
- ==== Student Environment ====
+   - canonical SipHash-2-4, including partial final message blocks;
+   - the two-lane persistent key-ratchet step;
+   - construction of the protocol-v3 packet, EID, and domain-separated MAC;
+   - strict packet verification with constant-time EID and MAC comparison;
+   - boot-time journal scan, validation, recovery, and lease reservation;
+   - payload emission with reservation before lease exhaustion and exactly one
+     in-memory epoch advance.
  
- The student receives in the browser:
+ Keep the existing function signatures. Do not change the packet size,
+ constants, storage callbacks, or public structures to work around the
+ contract.
  
-   * ''firmware/'' - Editable source;
-   * ''problem/'' - Challenge statement;
-   * ''output/'' - Logs, results, and HTML report;
-   * Run button - Starts the validation pipeline;
-   * Results panel - Displays ''output/report.html''.
+ ===== Packet contract =====
  
- Data is kept on the user's PVC. A scenario change archives the previous
- workspace. PVCs must not be deleted during the challenge or at rollback.
+ Every BLE manufacturer payload is exactly 28 bytes:
  
- ==== Automated Pipeline ====
+ ^ Bytes ^ Field ^
+ | ''0..1'' | company ID ''0xF00D'', little-endian |
+ | ''2'' | protocol version ''3'' |
+ | ''3'' | flags |
+ | ''4..7'' | persistent ratchet epoch, little-endian |
+ | ''8..11'' | public city sector, little-endian |
+ | ''12..19'' | keyed ephemeral identifier |
+ | ''20..27'' | keyed MAC over bytes ''0..19'' |
  
- Every Run executes, in order:
+ A stable tag identifier must never appear on air in either byte order.
  
-   - Native C17 compilation with ''-Wall -Wextra -Werror'';
-   - Known SipHash vectors and tamper tests;
-   - Zephyr build for the tag firmware;
-   - Zephyr build for the trusted gateway;
-   - Renode sector generation;
-   - Starting the nRF52840 machines in the BLE environment;
-   - Collecting UART logs from gateways;
-   - Fleet validation and HTML report generation.
+ ==== Key ratchet ====
  
- The validator uses only the traffic observed by gateways. It does not read
- the student's C variables and does not inspect the tags' memory.
+ The provided ''seed_to_key'' function derives the epoch-0 key. To derive the
+ key for ''next_epoch'', compute two SipHash outputs using the current 16-byte
+ key:
  
- ==== Scenario Scale ====
- 
- ^ Mode ^ Tags ^ Gateways ^ Rogue Clones ^ Total Boards ^
- | Local smoke | 6 | 3 | 2 | 11 |
- | Normal student run | 12 | 3 | 2 | 17 |
- | One showcase sector | 16 | 3 | 2 | 21 |
- | Complete showcase | 192 | 36 | 24 | 252 |
- 
- The showcase uses 12 independent sectors and runs a maximum of 4 in parallel.
- Each sector has a limit of ''3 CPU'' and ''2560 MiB'' RAM. These values were
- chosen after real testing; they must not be increased without a new capacity test.
- 
- ==== Live Infrastructure ====
- 
- The platform was recovered and hardened after the power incident:
- 
-   * CoreDNS is functioning and resolving internal and external names;
-   * Cloudflare tunnel uses token from mounted file, not token in arguments;
-   * Tunnel credential was rotated;
-   * Platform frontend is healthy;
-   * Provisioner selects only ''Ready=True'' and schedulable workers;
-   * All 3 nodes have systemd in ''running'' state;
-   * The infinite block in ''plymouth-quit-wait.service'' was removed;
-   * systemd journals are persistent on all nodes.
- 
- <hidden>
- Platform changes are in commit ''f5081ea'' from
- ''/home/pwd/eg106-platform'' on ''cloud_s1''.
- 
- </hidden>
- ===== What Students Need To Do =====
- 
- ==== Workspace ====
- 
- Students only modify:
- 
- <code>
- firmware/ghost_protocol.c
+ <code text>
+ 0x52 || next_epoch_le32 || lane
  </code>
  
- <note warning>
- The header, packet size, CMake, gateway, UART format, epoch duration, or
- testing harness must not be changed.</note>
+ Use lane ''0'' for new key bytes ''0..7'' and lane ''1'' for bytes ''8..15''.
+ Compute both outputs before replacing the current key.
  
- ==== TODO 1 - SipHash-2-4 ====
+ ==== EID and MAC ====
  
- The student implements ''ghost_siphash24'':
+ For a packet at epoch ''e'':
  
-   * 128-bit key;
-   * 64-bit result;
-   * Canonical SipHash-2-4 construction;
-   * Little-endian read;
-   * Correct support for lengths that are not a multiple of 8;
-   * Result identical to the known vectors included in tests.
+   * ratchet from epoch 0 through ''e'' to obtain the epoch key;
+   * compute the EID with SipHash over
+     ''0x45 || epoch_le32 || sector_le32'';
+   * copy the epoch key and XOR bytes ''0'', ''7'', ''8'', and ''15'' with
+     ''0x4d'', ''0x41'', ''0x43'', and ''0xa7'' to obtain the MAC key;
+   * authenticate packet bytes ''0..19'' with the MAC key;
+   * reject an incorrect company ID, version, EID, MAC, or an epoch above
+     ''1,000,000'';
+   * compare all EID and MAC bytes without returning on the first mismatch.
  
- An approximate implementation or with wrong byte order will not pass.
+ ===== Crash-safe persistent state =====
  
- ==== TODO 2 - Building The Payload ====
+ The tag has two 4096-byte journal pages. Erased bytes are ''0xff''; a write may
+ only change bits from 1 to 0; an erase operates on one complete page.
  
- The student completes ''ghost_build_payload'':
+ Each journal slot is a 40-byte record:
  
-   * Keeps the existing header and layout;
-   * Derives the ephemeral identity using domain ''0x45'', the epoch, and the sector;
-   * Writes the ephemeral identity in bytes ''12..19'';
-   * Derives the MAC with a different key domain than the one used for EID;
-   * Authenticates bytes ''0..19'';
-   * Writes the MAC in bytes ''20..27'';
-   * Does not copy ''device_seed'' into the packet.
+ ^ Bytes ^ Field ^
+ | ''0..3'' | magic ''0x47535452'' |
+ | ''4..7'' | generation |
+ | ''8..11'' | future resume epoch |
+ | ''12..15'' | cumulative page-erase count |
+ | ''16..31'' | ratcheted key for the resume epoch |
+ | ''32..35'' | IEEE CRC32 over bytes ''0..31'' |
+ | ''36..39'' | commit word ''0xC01117ED'' |
  
- The same raw key must not be reused directly for both roles.
+ Write the 36-byte body first. Write the commit word in a separate final storage
+ operation. A missing commit, bad CRC, bad magic, or partially written body is
+ not a valid record.
  
- ==== TODO 3 - Verifying The Payload ====
+ The journal reserves leases of 16 epochs:
  
- The student completes ''ghost_verify_payload'' so that it rejects:
+   * before the first advertisement, durably reserve epochs ''0..15'' by storing
+     the resume state for epoch ''16'';
+   * after a clean reboot, resume at the stored future epoch and reserve the next
+     lease before transmitting;
+   * if a non-erased invalid slot follows the newest valid record, skip two full
+     leases conservatively before reserving again;
+   * append after the newest record;
+   * when one page is full, erase the other page and write its first record;
+   * never erase the page holding the newest valid state before its successor is
+     committed.
  
-   * Wrong company ID;
-   * Wrong version;
-   * Wrong ephemeral identity;
-   * Wrong MAC;
-   * Flags modified after signing;
-   * Any modification to authenticated bytes;
-   * Verification with an unauthorized seed;
-   * Clone packets that only respect the protocol format.
+ These rules must prevent epoch reuse after a torn body write, torn commit,
+ corrupted CRC, page rollover, or power loss at any storage operation.
  
- The verification must reconstruct the expected values, don`t accept a packet
- just because it has the correct size and header.
+ ===== Energy and endurance limits =====
  
- ==== Recommended Student Workflow ====
+ Runtime energy is calculated as:
  
-   - Read ''problem/problem.md'' and the comments for the 3 TODOs;
-   - Implement and verify SipHash first;
-   - Implement EID and MAC;
-   - Implement verification;
-   - Run the challenge using the Run button;
-   - Fix native errors first, then Zephyr errors;
-   - Analyze Renode logs only after builds pass;
-   - Open or refresh the Results panel after the run finishes.
+ <code text>
+ energy = flash_writes * 8 + page_erases * 40 + advertisements
+ </code>
  
- ==== Success Criteria For Students ====
+ One committed record requires two writes: body, then commit. The power-cut
+ simulation must use no more than 80 energy units.
  
- A solution is accepted only if:
+ The endurance tests generate 2000 sequential payloads. A passing solution uses
+ at most 252 flash writes and exactly one page erase. Persisting every packet
+ cannot pass these limits; lease reservation is required.
  
-   * All SipHash tests pass;
-   * All 3 gateways start;
-   * All authorized tags are observed;
-   * Each tag changes its radio identity;
-   * Clone traffic is rejected;
-   * There are no fatal errors in the firmware;
-   * The validator displays ''GHOST_VALIDATION passed=1'';
-   * The run finishes with ''GHOSTTAG FLEET SURVIVED THE APOCALYPSE''.
+ ===== Simulation =====
  
- Compiling without errors is not enough.
+ The complete run starts:
  
- <hidden>
- ===== What We Need To Do As Organizers =====
+   * 6 authorized nRF52840 tags;
+   * 3 trusted observer gateways;
+   * 1 unregistered clone;
+   * 1 attacker replaying a captured, correctly authenticated packet.
  
- ==== Before The Challenge ====
+ At virtual second 3, Renode resets tag 1 while preserving its nonvolatile
+ journal. The replay attacker then transmits an old epoch-0 packet from a
+ different BLE address.
  
-   - Check the cluster, frontend, registry, and workers;
-   - Rebuild the GhostTag image from the correct branch;
-   - Run the smoke test with the reference implementation and 6 tags;
-   - Do not continue if the final success marker is missing;
-   - Explicitly push the tag
-     ''nrf52840-swarm-ghosttag-apocalypse'' to the registry;
-   - Verify the image manifest directly in the registry or by pulling on a node;
-   - Run server-side dry-run for both Kubernetes manifests;
-   - Save the active scenario ConfigMap for rollback;
-   - Activate ''k8s/platform/active-scenario.yaml'';
-   - Test with a disposable user.
+ A correct system must:
  
- The disposable test must demonstrate both directions:
+   * discover all six authorized tags;
+   * observe identity rotation for every tag;
+   * reject the unregistered clone;
+   * reject the captured replay;
+   * recover tag 1 without reusing an epoch;
+   * remain within the runtime energy budget;
+   * finish without firmware fatal errors.
  
-   * The starter is properly seeded and fails cleanly;
-   * The reference implementation passes completely;
-   * The report appears in Results;
-   * Old files are archived upon scenario change.
+ ===== Recommended workflow =====
  
- Complete operational commands are in ''docs/HACKATHON_RUNBOOK.md''.
+ ^ Goal ^
+ | Read every contract and pass all SipHash vectors. |
+ | Implement ratchet, packet generation, EID, MAC, and verification. |
+ | Implement record encoding, CRC32, scanning, append, and leases. |
+ | Handle torn writes, corruption, reboot, and page rollover. |
+ | Verify flash-wear and energy bounds. |
+ | Run Zephyr and Renode; diagnose the complete swarm. |
  
- ==== At The Beginning Of The Session ====
+ Use the fastest feedback first. Do not repeatedly run the full swarm while the
+ native protocol suite still fails.
  
- We must clearly explain:
+ ===== Understanding the Run result =====
  
-   * The privacy problem: a stable ID allows tracking the person;
-   * Why epoch, EID, and MAC exist;
-   * Why the trusted gateway searches within the authorized fleet;
-   * What the student controls and what the harness controls;
-   * Why rogue clones exist;
-   * Which is the only editable file;
-   * How to read the three feedback levels.
+ The Run action has three gates:
  
- We do not provide the reference implementation and do not expose fleet seeds.
- </hidden>
+   - native C17 tests for cryptography, packet integrity, persistence, recovery,
+     corruption handling, and endurance;
+   - Zephyr builds for the nRF52840 tag and trusted gateway;
+   - an 8-second Renode swarm followed by validation and report generation.
  
- ==== During The Challenge ====
+ The complete success output includes lines equivalent to:
  
- We monitor:
- 
-   * Node and pod health;
-   * The Job queue for student runs;
-   * Image pull errors;
-   * CPU, RAM, and ephemeral storage usage;
-   * Frontend and ingress availability;
-   * Participants' PVCs;
-   * Renode execution times.
- 
- We help students with compilation errors, platform usage, and interpreting
- the report. We do not implement TODOs for them.
- 
- ==== Final Showcase ====
- 
- The showcase is optional and separate from student runs.
- 
- Before launching:
- 
-   * Check requested resources on both workers;
-   * Confirm there is at least one healthy worker and enough space for the
-     approx. 3.76 GB image;
-   * Keep ''parallelism: 4'';
-   * Do not delete pods or student PVCs to make room.
- 
- Launch ''k8s/showcase/indexed-job.yaml'' and monitor all 12 completions.
- The showcase is successful only if all 12 sectors finish successfully and
- each log contains ''GHOST_VALIDATION passed=1''.
- 
- ==== After The Challenge Or At Rollback ====
- 
-   * Only delete the Showcase Job if it needs to be stopped;
-   * Restore the saved ConfigMap if reverting to the previous scenario;
-   * Do not delete student PVCs;
-   * Keep reports and logs useful for evaluation;
-   * Check the public health endpoint again;
-   * Document any cluster incident or observed capacity limit.
- 
- ===== Definition Of Done For Organizers =====
- 
- The challenge can be opened to students when all points are true:
+ <code text>
+ PROTOCOL_CONTRACT_TESTS failures=0
+ Renode exit status: 0
+ GHOST_VALIDATION passed=1 ... tags=6/6 rotated=6/6 ... recovered=1 energy=.../80
+ >>> GHOSTTAG FLEET SURVIVED THE APOCALYPSE <<<
+ </code>
  
-   * [ ] GhostTag image is built from the desired commit;
-   * [ ] Reference smoke test passes;
-   * [ ] Image tag is confirmed in the registry;
-   * [ ] All required nodes are ''Ready'';
-   * [ ] Frontend and DNS are healthy;
-   * [ ] Manifest dry-run passes;
-   * [ ] Previous scenario state is saved;
-   * [ ] GhostTag scenario is active;
-   * [ ] Starter fails in a controlled manner for the disposable user;
-   * [ ] Reference passes for the disposable user;
-   * [ ] HTML report loads in Results;
-   * [ ] Rollback is prepared;
-   * [ ] Reference solution is not accessible to participants.
+ After the run, refresh the Results panel and inspect ''output/report.html''.
+ When a check fails, read the first failing gate and its log before changing
+ code.
  
- At the time of writing, the first two remaining operational actions are build/push
- for the image and controlled activation of the scenario. The showcase must not
- be launched before the disposable test.
+ ===== Completion checklist =====
  
- ===== Important Files =====
+ Before considering the challenge complete, confirm that:
  
- ^ File ^ Role ^
- | ''firmware/ghost_protocol.c'' | The only file edited by the student |
- | ''firmware/include/ghost_protocol.h'' | Wire contract and API |
- | ''firmware/tests/test_protocol.c'' | Public native tests |
- | ''ide/problem/problem.md'' | Full statement displayed in the browser |
- | ''support/gateway/'' | Trusted gateway |
- | ''docker/scripts/build_firmware.sh'' | Native tests and Zephyr builds |
- | ''docker/scripts/generate_swarm_resc.py'' | Renode topology generation |
- | ''docker/scripts/validate_swarm.py'' | Automated acceptance criteria |
- | ''docker/scripts/generate_report.py'' | HTML report |
- | ''k8s/platform/active-scenario.yaml'' | Scenario activation for students |
- | ''k8s/showcase/indexed-job.yaml'' | 252-board showcase |
- | ''docs/HACKATHON_RUNBOOK.md'' | Operational procedure and rollback |
- | ''docs/instructor_notes.md'' | Recommended structure for the 3-hour session |
+   * all six TODOs have real implementations;
+   * all 64 SipHash vectors pass;
+   * the exact ratchet and 28-byte packet vectors pass;
+   * malformed, tampered, forged, and unreasonable packets are rejected;
+   * fresh boot reserves a lease before any packet is emitted;
+   * every recovery path avoids epoch reuse;
+   * torn and corrupted records remain invalid;
+   * 2000 payloads stay within the write and erase limits;
+   * both Zephyr applications build;
+   * the Renode validator reports all six tags seen and rotated;
+   * clone rejection, replay rejection, recovery, energy, and fatal-error checks
+     all pass.
  
- <hidden>
- | ''reference/firmware/'' | Organizers' solution |
- </hidden>

01. [Re]Configuring & building OP-TEE + ATF

florin.stancu — 2026-07-17T16:16:23+03:00

@@ -51,9 +51,9 @@
  
  <note warning>
  There is currently a bug inside OP-TEE that makes it unable to boot: it uses the NXP EdgeLock Enclave for TRNG generation, whose firmware does not start (and we weren't able to figure it out since its documentation is "secret" / available using NDA-only).
  
- As workaround, we can disable the ELE RNG driver and enable a software one using the following additional make configuration options: ''CFG_WITH_SOFTWARE_PRNG=y CFG_IMX_ELE=n''. So make sure to also set them!
+ As workaround, we can disable the ELE RNG driver and enable a software one using the following additional make configuration options: ''CFG_WITH_SOFTWARE_PRNG=y CFG_IMX_ELE=n CFG_IMX_TRUSTED_ARM_CE=n''. So make sure to also set them!
  </note>
  
  After a successful build, check the output (''O'') directory's ''core'' subdirectory for the ''tee.bin'', ''tee-raw.bin'' and many other files!
  We will keep the raw one for later inclusion into the firmware package using ''mkimage'' ;)
@@ -72,23 +72,35 @@
  You need to set the following additional configuration variables to its make invocation:
    * ''SPD=opteed'' -- this is the [[https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/index.html|Secure Payload Dispatcher]] module, aka: who does ATF's Secure Monitor need to talk with? Our OP-TEE, of course!
    * ATF also has to know the memory region where we've put OP-TEE (set the ''BL32_BASE'' variable to lower limit, in hexadecimal); we also need to specify its total size: ''BL32_SIZE'' (remember: we allocated ''36MB'', but give it in bytes, either in base 10 or 16 using C integer notation);
    * We want ATF to print some debug messages over the first serial peripheral so, finally, set the ''LOG_LEVEL=40'' and ''%%IMX_BOOT_UART_BASE=0x44380000%%'' (if you look in iMX93's Memory Map (the Reference Manual), this is the physical address of our LPUART1 - i.e. our serial communication module!).
+ 
  
  == Step 4. Rebuild the firmware image package ==
  
  Before we can take a look at the fruits of our effort so far, we need to re-build the firmware package with these last two components.
  
- This is easy if you saved your mkimage script (in your Makefile). You will need JUST one additional file copied: ''tee-raw.bin'' from ''optee'' build output directory, ''core'' subdirectory (as mentioned in the subtask above!) inside ''mkimage'''s build directory, but rename it as ''tee.bin''.
- The bundled scripts will [[https://github.com/nxp-imx/imx-mkimage/blob/lf-6.12.20_2.0.0/iMX93/soc.mak#L43|see that this file exists]] and add it to the image automatically!
+ Since we're using mainline [[https://docs.u-boot-project.org/en/latest/develop/package/binman.html|u-boot's binman]] to generate our ''flash.bin'', we must reconfigure its descriptor to embed our new ''BL32'' component.
  
- <note warning>
- One more thing: when calling the imx-mkimage's script, set ''TEE_LOAD_ADDR=<TrustZone DRAM start address>''.
- 
- The default value is wrong for our SoC.
- </note>
+ Fortunately, [[https://lists.denx.de/pipermail/u-boot/2026-June/621618.html|it's quite easy]], so manually apply this patch (minus the ''if def''):
+ <code patch>
+ diff --git i/arch/arm/dts/imx93-u-boot.dtsi w/arch/arm/dts/imx93-u-boot.dtsi
+ index dc86746ac90..06fe228d568 100644
+ --- i/arch/arm/dts/imx93-u-boot.dtsi
+ +++ w/arch/arm/dts/imx93-u-boot.dtsi
+ @@ -69,6 +69,7 @@
+  				container;
+  				image0 = "a55", "bl31.bin", "0x204E0000";
+  				image1 = "a55", "u-boot.bin", "0x80200000";
+ +				image2 = "a55", "tee-raw.bin", "0xfdc00000"; // replace with your OP-TEE TZDRAM addr
+  			};
+  		};
+  	};
+ </code>
  
+ Then simply copy ''tee-raw.bin'' from op-tee's ''build/core'' directory to u-boot's source and run your make script again.
  Also make sure to replace ''bl31.bin'' with the newly recompiled one from ARM Trusted Firmware-A!
+ To verify, the newly obtained ''flash.bin'' should be ''>=2MB'' in size.
  
  Proceed to load this image over the serial boot protocol using the IMX ''uuu'' utility.
  Check the serial console (the one provided by the board's DEBUG USB port) for confirmation!

Research projects

radu.mantu — 2026-07-17T13:29:08+03:00

@@ -2,6 +2,7 @@
  
  ===== Research projects  =====
  
  <html>
- <iframe src="https://docs.google.com/presentation/d/e/2PACX-1vQ7QFyYtR3yZU0yRlgX1Vrk245McK9iTw42L8WQAHvt5pRAJWw4Oks3EJnH8JNnXzxw44YLJbQtiFXG/pubembed?start=false&loop=false" frameborder="0" width="800" height="486" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe>
+ <iframe src="https://docs.google.com/presentation/d/e/2PACX-1vSdlaU-Cvatr7LIMGgpOca1HW16qpVids9FwICEzdyV7JPCsR8zwIlf0tJqPEOdor3yTH_ytUy5-TM3/pubembed?start=false&loop=false" frameborder="0" width="800" height="486" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe>
  </html>
+

02. Writing Trusted Applications

florin.stancu — 2026-07-17T10:11:03+03:00

@@ -21,12 +21,15 @@
  make ARCH=... dtbs
  </code>
  </note>
  
- Oh, and re-enable **Buildroot** if disabled for the previous lab (you backed up your ITS file, hopefully).
- Then enter its ''menuconfig'' and search for ''PACKAGE_OPTEE_CLIENT''. Enable it and rebuild your rootfs!
+ Afterwards, you need to copy the new ''.dtb'' into your ''staging/'' directory and re-build the Linux uImage (using the previously provided ''staging/Makefile'').
  
- Afterwards, you need to copy the new ''.dtb'' into your ''staging/'' directory and [[:ass:labs-2025:02:tasks:01#task_d_-_fit_image|re-build the Linux FIT]] (e.g., ''linux.itb''). And upload it to your emmc (use u-boot's ''ums'' and simply copy the file on the FAT32 boot partition).
+ As for the userspace (rootfs), there are two choices: either **Debian** or **Buildroot** (disable RAUC nevertheless and use the first version of ''mk-disk-image.sh'' to upload the rootfs when ready to test, towards the end of the task).
+ 
+ For Buildroot, you must use ''menuconfig'' and enable ''PACKAGE_OPTEE_CLIENT''! Built it & unpack it to the secondary ext4 disk partition (just edit the mk-disk-image script).
+ 
+ For Debian, you can either cross compile the OP-TEE client or try out the ''optee-client'' package from APT (use a ''chroot'' to install from host).
  
  == Step 6. Building a TA ==
  
  We can use our workstation / laptop to cross-compile a trusted application!
@@ -36,21 +39,21 @@
  Build both the host app and the Trusted Application need to be compiled TOGETHER with the TEE Client Library, and the OPTEE OS exported SDK, respectively.
  
  Make sure to read the examples documentation to see the make variables to set!
  
- <note>
+ <spoiler Special Instructions for Buildroot>
  Note that, usually, you must build optee-client from source on the host machine [[https://optee.readthedocs.io/en/latest/building/gits/optee_client.html#build-instructions|the optee_client first]]. .
  
- But, since we're using Buildroot and have enabled it, you can find it already compiled for the target system at ''<buildroot-dir>/output/build/optee-client-<version>''.
+ Since you're using Buildroot, you can find it already compiled for the target system at ''<buildroot-dir>/output/build/optee-client-<version>''.
  
  Touugh we need to give a ''TEEC_EXPORT'' install path when invoking the TA makefile... Use find for ''tee_client_api.h'' and see where it's found (hint: ''sysroot'')!
- </note>
+ 
+ Also note that for building Buildroot-targeted applications, your classic ''aarch64-none-gnu-'' toolchain **won't work** since Buildroot uses a custom LibC by default. But, fortunately, you may find the cross compilation prefix at ''<buildroot-dir>/output/host/bin/aarch64-buildroot-linux-gnu-'' (see the difference?)!
+ </spoiler>
  
  <note>
  As for ''TA_DEV_KIT_DIR'' of a Trusted Application, it must point to an SDK generated inside BL32 (optee_os) source directory (something like ''export-ta...'''.
  </note>
- 
- Also note that for building Buildroot-targeted applications, your classic ''aarch64-none-gnu-'' toolchain **won't work** since Buildroot uses custom [[https://www.uclibc.org/|ucLibC]] by default. But, fortunately, you may find the cross compilation prefix at ''<buildroot-dir>/output/host/bin/aarch64-buildroot-linux-gnu-'' (see the difference?)!
  
  == Step 7. Signing the TA ==
  
  Remember the secure boot process?
@@ -73,73 +76,29 @@
  <code>
  u-boot=> ums mmc 0
  </code>
  
- Do not Ctrl+C yet, leave it running and mount the newly appeared USB device in your PC/VM!
+ Use ''lsblk'' to find out which is the second (ext4) partition, mount it and copy the TA files:
+ <code bash>
+ mount /dev/sda2 /mnt
+ ls -l /mnt
+ # copy them inside your home
+ cp $OPTEE_FILES /mnt/root/
+ </code>
  
  After copying the files, boot Linux.
  
- Now check if ''tee-supplicant'' is running... let's mount devtmpfs then start it:
+ On buildroot, check if ''tee-supplicant'' is running... or start it:
  <code bash>
- mount -t devtmpfs devtmpfs /dev
+ ps aux | grep tee-supplicant
  tee-supplicant -d
  </code>
  
- Mount the boot partition and run the TA (you might need to copy it somewhere else and ''chmod +x'')!
- Then execute the program ;) 
+ Then execute the trusted application ;) 
  
  <note info>
  Observe the error: OP-TEE cannot find the ''.ta'' file inside a trusted memory or REE.
  
  For this, you will need to copy the signed ''<UUID>.ta'' file to ''/lib/optee_armtz/'' (create it if it doesn't exist), as (very badly) documented.
  </note>
  
- 
- == TODO: format me ==
- 
- <code bash>
- # mount the relevant partitions
- [user@host]$ sudo mount /dev/nbd0p1 /mnt
- [user@host]$ sudo mkdir -p /mnt/{root,var,boot}
- [user@host]$ sudo mount /dev/nbd0p5 /mnt/root
- [user@host]$ sudo mount /dev/nbd0p6 /mnt/var
- [user@host]$ sudo mount /dev/nbd0p7 /mnt/boot
- 
- # delete the lost+found/ directories (because I don't like them)
- [user@host]$ sudo find /mnt -type d -name lost+found -delete
- 
- # bootstrap the rootfs and install qemu-user-static for chroot
- # NOTE: mainline debootstrap is broken on CachyOS; that's why we use a submodule
- [user@host]$ sudo ./third-party/debootstrap/debootstrap \
-                 --include=neovim,locales,iproute2       \
-                 --arch=arm64 --foreign                  \
-                 trixie /mnt
- [user@host]$ sudo cp $(which qemu-aarch64-static) /mnt/usr/bin
- 
- # finish up debootstrap process inside chroot
- # NOTE: arch-chroot automatically mounted /proc /sys /dev inside jail
- #       you can install it via the arch-install-scripts on non-ArchLinux distros
- [user@host]$ sudo arch-chroot /mnt
- 
- [root@jail]$ export PATH=/usr/sbin:${PATH}
- [root@jail]$ /debootstrap/debootstrap --second-stage
- 
- [root@jail]$ passwd
- 
- [root@jail]$ echo "en_US.UTF-8 UTF-8" >> /etc/locale.gen
- [root@jail]$ locale-gen
- [root@jail]$ update-locale LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8
- 
- [root@jail]$ exit
- 
- # before unmounting, create the fstab so that /root, /var and /boot are mounted
- # after the rootfs is verified; these three are unprotected but also unimportant
- [user@host]$ cat <<EOF | sudo tee /mnt/etc/fstab
- /dev/vda5   /root             ext4  rw,relatime                    0  2
- /dev/vda6   /var              ext4  rw,relatime                    0  2
- /dev/vda7   /boot             vfat  rw,relatime                    0  2
- EOF
- 
- # finally, do a recursive unmount of all three partitions
- [user@host]$ sudo umount -R /mnt
- </code>

03. RAUC

florin.stancu — 2026-07-16T15:34:28+03:00

@@ -15,11 +15,19 @@
    - Sets up ''/etc/fw_env.config'', ''fstab'', and enables systemd services
  
  But in order to run it, recursively copy the entire RAUC utils directory from host to somewhere inside the debian rootfs (e.g., ''/root/rauc-utils/'') and run it using ''chroot-enter.sh'' (as you've done in the prev. task).
  
- === Generate the disk image ===
+ === [Re]Generate the disk image ===
  
  We can now run ''mk-disk-image2.sh''. The ''disk.img'' will be updated with 4 partitions (boot, A, B + data), Debian will be copied to the first 2 EXT4 partitions and the bootloader will be installed at 32KB offset (the SoC's BL1/BOOTROM wants it there).
+ 
+ === Custom u-boot script ===
+ 
+ 📄 In order to have the A-B partitioning scheme, we'll need to add this script: ''rauc-utils/boot.cmd.in'' to our u-boot default environment. Feel free to study it (highly recommended)!
+ 
+ Use the ''rauc-utils/uboot-modify-bootcmd.sh'' script to just to this!
+ 
+ Then rebuild uboot (you must delete ''u-boot/.config'' and ''u-boot/flash.bin'' for our Makefile to trigger the recompilation of UBoot).
  
  === Flashing the board ===
  
  Power up the board and go into u-boot. Let ''fastboot'' start and use ''fastboot flash 0:0 disk.img''.

ass:labs-2025:deb-rauc-lab-skel-2026.tar.gz

florin.stancu — 2026-07-16T15:25:46+03:00

02. Bootstrapping Debian

florin.stancu — 2026-07-16T15:08:19+03:00

@@ -9,13 +9,12 @@
  📄 Edit the ''mk-debian-rootfs.sh'' script, read the code and fill the TODOs.
  
  Since we need to install the Debian binaries executable on a 64-bit ARM architecture, we will need to split the installation into two stages: first, the .deb (Debian install packages) are downloaded from a Debian mirror server and unpacked into the target rootfs directory. Afterwards, since Debian will need to run some scripts to setup its distro system, we must **emulate** the target architecture. Enter [[https://www.qemu.org/|qemu]] which will help us to just that!
  
- Finally, we need to obtain the ''debian-rootfs.tar.gz'' archive with the contents of our newly-created Aarch64 Debian. Use ''tar'' to ''c''reate a g''z''ipped archive, and be sure to ''p''reserve permissions!
+ Finally, we need to obtain the ''debian-rootfs.tar.gz'' archive with the contents of our newly-created Aarch64 Debian. Use ''tar'' to ''c''reate a g''z''ipped archive, and be sure to ''p''reserve permissions:
  
- The final results should be something like:
- <code>
- -rw-r--r--  1 root  root  213M 2026-07-26 14:23 debian-rootfs.tar.gz
+ <code bash>
+ sudo tar czpf debian-rootfs.tar.gz -C debian-rootfs/ .
  </code>
  
  Note: each time you chroot and install / modify your rootfs on your local machine, make sure to rebuild the ''tar.gz'' archive!

ass:labs-2025:04:deb-rauc-lab-skel-2026.tar.gz - created

florin.stancu — 2026-07-16T14:40:57+03:00

rasb:lab:pupper_viz.tar.gz - created

andrei.batasev — 2026-07-03T23:34:21+03:00

rasb:lab:base_back_kinematics.png - created

andrei.batasev — 2026-07-01T17:36:08+03:00

	current

rasb:lab:l3_ee_kinematics.png - created

andrei.batasev — 2026-07-01T17:25:21+03:00

	current

rasb:lab:l2_l3_kinematics.png - created

andrei.batasev — 2026-07-01T17:25:21+03:00

	current

rasb:lab:l1_l2_kinematics.png - created

andrei.batasev — 2026-07-01T17:25:21+03:00

	current

rasb:lab:base_l1_kinematics.png - created

andrei.batasev — 2026-07-01T17:25:21+03:00

	current

rasb:lab:p_control.png - created

jan.vaduva — 2026-06-28T08:52:42+03:00

	current

rasb:lab:pid_eqn.png - created

jan.vaduva — 2026-06-28T08:51:47+03:00

	current

rasb:lab:nxpcar-lab.zip - created

rares.sarmasag — 2026-06-26T15:47:09+03:00

rasb:lab:lab1_skel.zip - created

ciprian.popescu0411 — 2026-06-22T17:48:14+03:00

rasb:lab:llm_lab.zip

vlad.radulescu2901 — 2026-06-19T15:10:10+03:00