exams: Add 2024 autumn written exams

Add "Testing System" and "Fuzzing System" exams.

Signed-off-by: Teodor Dutu <[email protected]>

Author: teodutu

chapters/general/drills/tasks/fuzzing-system.md

@@ -0,0 +1,53 @@
+# Fuzzing Systems for Embedded Applications
+
+A fuzzer/fuzzing system generates semi-random inputs to send to a target application to discover bugs—inputs that lead to crashes.
+We propose building a fuzzing system for binary applications on embedded systems with specific architectures (e.g., ARM/MIPS).
+The fuzzing system runs on an x86 system and uses an emulator to run the application.
+The fuzzer sends inputs to the application through the emulator and extracts introspection information useful for fuzzing.
+
+Answer the following questions with "True" or "False" and justify your answer.
+Justifications should be simple, 2-3 sentences for each response.
+
+1. The fuzzing system is an application that must run with privileged permissions.
+    - **Answer:** False
+    - **Justification:** The fuzzing system starts the emulator and sends inputs without performing privileged actions.
+
+1. The fuzzing system can run inside a virtual machine.
+    - **Answer:** True
+    - **Justification:** Since the system uses an emulator, nothing prevents it from running inside a virtual machine.
+
+1. The performance of the fuzzing system (number of inputs sent per second) is comparable to that of a fuzzing system for native applications (running natively on the local x86 system).
+    - **Answer:** False
+    - **Justification:** Emulating instructions introduces significant overhead compared to running natively.
+
+1. During the execution of the embedded application in the emulator, no system calls are made on the local system.
+    - **Answer:** False
+    - **Justification:** The emulator performs system calls for tasks such as memory allocation or synchronization.
+
+1. The emulated application must be an ELF (Executable and Linking Format) file, specific to Linux.
+    - **Answer:** False
+    - **Justification:** The executable format depends on the emulator and can be ELF, PE, COFF, or raw.
+
+1. We can run only one instance of the fuzzing system because we can run only one instance of the emulator.
+    - **Answer:** False
+    - **Justification:** Multiple emulator instances can run simultaneously, limited only by available resources.
+
+1. The application source code is required to run the application on the emulator.
+    - **Answer:** False
+    - **Justification:** The emulator runs machine code, so only the binary application is needed, while the source code is optional.
+
+1. The emulator appears as a process in the local system.
+    - **Answer:** True
+    - **Justification:** Applications run as processes, and the emulator on the local system functions as a process.
+
+1. Using the emulator, the fuzzing system can have direct access to the memory of the running application.
+    - **Answer:** True
+    - **Justification:** The emulator emulates memory and the processor, allowing direct memory access.
+
+1. If the system is x86 on 32-bit, the emulated application architecture cannot be 64-bit.
+    - **Answer:** False
+    - **Justification:** Emulation allows any architecture to be simulated, depending on the emulator's capabilities.
+
+1. A crash in the emulated application can lead to a crash of the fuzzing system.
+    - **Answer:** False
+    - **Justification:** The application crashes inside the emulator, which should not affect the local system if implemented properly.

chapters/general/drills/tasks/testing-system.md

@@ -0,0 +1,57 @@
+# Testing System
+
+A testing system allows building an application that can run on different architectures and platforms (operating systems).
+For real testing, the application must run on a system with the appropriate architecture and platform.
+The testing system provides configurations that enable local builds followed by deployment of the resulting application (and necessary files - build artifacts) to a dedicated system for testing.
+The test result is returned to the local (build) system.
+
+Answer the following questions with "True" or "False" and justify your answer.
+Justifications should be simple, 2-3 sentences for each response.
+
+1. The application cannot be compiled on another architecture or platform, it must be compiled on the running system, not locally.
+    - **Answer:** False
+    - **Justification:** Cross-compiling suites, along with build systems or containers, can be used to create a build environment for testing on another platform or architecture.
+
+1. Testing systems can be virtual machines.
+    - **Answer:** True
+    - **Justification:** Yes, the application can be tested on a virtual machine.
+    While there may be performance penalties, it is possible to test effectively on virtual machines.
+
+1. The testing system will be significantly more performant if written in a compiled language (C, Go, Rust) compared to an interpreted one (Python, JavaScript, Ruby).
+    - **Answer:** False
+    - **Justification:** The testing system invokes the application (via fork-exec).
+    The choice of a compiled or interpreted language does not significantly impact this process.
+
+1. The testing system must run with privileged permissions.
+    - **Answer:** False
+    - **Justification:** The system performs operations such as compiling, running, and copying files over the network, all of which can be executed by non-privileged users.
+
+1. The build process in the testing system is CPU-intensive.
+    - **Answer:** True
+    - **Justification:** The build process involves compiling, linking, and other operations that are CPU-intensive.
+
+1. The testing system's runtime process can be CPU-intensive or I/O-intensive depending on the application's nature.
+    - **Answer:** True
+    - **Justification:** The nature of the application dictates whether the testing system's runtime process will be CPU-intensive or I/O-intensive.
+
+1. The testing system would benefit from a multi-threaded implementation.
+    - **Answer:** False
+    - **Justification:** The testing system launches other processes (build, application).
+    A multi-threaded implementation would not significantly alter the overall behavior or efficiency.
+
+1. The local (build) system and testing systems can communicate using a network file system.
+    - **Answer:** True
+    - **Justification:** Yes, and it is recommended for efficient and easy transfer of build artifacts and test results.
+
+1. Testing systems can be used by multiple local (build) systems.
+    - **Answer:** True
+    - **Justification:** This is both possible and recommended to save resources, especially since testing systems may remain idle part of the time.
+
+1. Testing the application runtime is facilitated if the application is compiled into a static executable.
+    - **Answer:** True
+    - **Justification:** A statically compiled application does not require dependent libraries, making it easier to test by simply copying and running the executable.
+
+1. Applications built for a different architecture can be tested locally in a container without significant performance penalties.
+    - **Answer:** False
+    - **Justification:** Running an application built for another architecture locally requires an emulator, whether in a container or not.
+    Emulators are typically slow, leading to significant performance penalties.

config.yaml

@@ -388,6 +388,10 @@ docusaurus:
       - Exams:
           path: chapters/general/drills/tasks
           subsections:
+            - 2024 Autumn:
+                subsections:
+                  - Testing System/: testing-system.md
+                  - Fuzzing System/: fuzzing-system.md
             - 2024 Summer:
                 subsections:
                   - Syscall Tracing/: syscall-tracing.md