Add top-level folders, quick proofread

Signed-off-by: Jenni Nikolaenko <evgeniia.nikolaenko@unikie.com>

src/overview.md → src/about/overview.md

@@ -1,13 +1,13 @@
-# Overview
+# About Ghaf
 
 Secure Tech-project studies secure technologies in the context of embedded virtualization. This documentation-project, named after Ghaf tree, provides a landing site to our work. Our applied software research supports [Secure Systems Research Center](https://www.tii.ae/secure-systems) focus areas.
 
 ## Embedded Virtualization
 
 Embedded virtualization builds on cloud technologies in the development of end-to-end security. With hardware support for virtualization, we provide hardened system of small trusted computing base (TCB) - thin host - that enables isolation of use cases and their resources. Use cases are protected in guest virtual machines. Embedded targets small devices - personal or headless - instead of high performance cloud servers. Our scope is illustrated in the following diagram.
 
-![Scope!](img/overview.png "")
+![Scope!](img/overview.png "Embedded Virtualization Scope")
 
 ## Reference Implementation
 
-//Our work in progress reference implementation on NXP i.MX8 is available [here](https://github.com/tiiuae/spectrum-config-imx8).
+Our work in progress reference implementation on NXP i.MX8 is available [here](https://github.com/tiiuae/spectrum-config-imx8).

src/architecture/adr.md

@@ -1,7 +1,5 @@
 # Architecture Decision Record
 
-## Overview
-
 [Architecture decision records (ADR)](https://adr.github.io) are used to constitute the Ghaf platform decision log.
 
 ## Contributions

src/build_config/build_configurations.md

@@ -0,0 +1,28 @@
+# Build Configurations
+
+Our hardened operating system (OS) targets are build configurations based on NixOS. The canonical URL for the upstream git repository is: [https://github.com/NixOS](https://github.com/NixOS).
+
+Build configurations define our dependencies and configuration changes to packages and build mechanisms of NixOS. If you want to try and check the details, see the [build-configurations](https://github.com/tiiuae/build-configurations/) repository.
+
+## Approach
+
+A build configuration is a target to build our hardened OS for a particular hardware device. The supported development target devices are listed in [build-configurations](https://github.com/tiiuae/build-configurations/). The packages used in a build configuration come from [nixpkgs - NixOS Packages collection](https://github.com/NixOS/nixpkgs).
+
+The upstream first approach means we aim the fix issues by contributing to nixpkgs. At the same time, we get the maintenance support of NixOS community and the benefits of the Nix language on how to build packages and track the origins of packages in the software supply chain security. For more information, see [Supply Chain Security](scs/scs.md).
+
+NixOS, a Linux OS distribution packaged with Nix, provides us with:
+- generic hardware architecture support (``x86-64`` and ``AArch64``);
+- declarative and modular mechanism to describe the system;
+- Nix packaging language mechanisms:
+  - to extend and change packages with [overlays](https://nixos.wiki/wiki/Overlays),
+  - to [override](https://nixos.org/guides/nix-pills/override-design-pattern.html) packages.
+
+Even when unmodified upstream is often preferred, even ideal, to ensure timely security updates from upstream — customizations are sometimes required.
+
+### Example
+
+To support a reference board without a vendor board support package (BSP) — bootloader, kernel, device drivers — is often not feasible. With this approach, we can overlay the generic NixOS Linux kernel with the vendor kernel and add a vendor bootloader to build a target image.
+
+Often the vendor BSPs are also open source but sometimes contain unfree binary blobs from the vendor's hardware. Those are handled by allowing ``unfree`` - if the user agrees with the end-user license agreement (EULA). If not, ``unfree`` support can be dropped along with that part of the BSP support.
+
+The same goes with the architectural variants as headless devices or end-user devices differ in terms what kind of virtual machines (VM) they contain. The user needs graphics architecture and VM support for the user interface (UI) whereas a headless device is more like a small server without the UI.