Added bscript thing

Blastproof/keygen/keygen.cpp

@@ -281,8 +281,8 @@ int main(int argc,char **argv) {
   }
   secure_erase(sigsbuf.data(),sigsbuf.size());
   if (!password_env) {
-    cout<<"[Keygen] You are about to define a boot password. This password will be asked everytime you boot this instance of Vystem."<<endl;
+    cout<<"[Keygen] You are about to define a boot password. This password will be asked everytime you boot this instance of Vystem B."<<endl;
-    cout<<"[Keygen] It will be used to sign every public key on this instance of Vystem. Make sure it's secure. Here are the requirements:\n  - It should be at least 12 characters.\n  - Password can only include ASCII characters.\n  - Password shouldn't be longer than 512 characters.\n  - DO NOT use the numerical pad at all. It's not supported in the EFI environment."<<endl;
+    cout<<"[Keygen] It will be used to sign every public key on this instance of Vystem B. Make sure it's secure. Here are the requirements:\n  - It should be at least 12 characters.\n  - Password can only include ASCII characters.\n  - Password shouldn't be longer than 512 characters.\n  - DO NOT use the numerical pad at all. It's not supported in the EFI environment."<<endl;
     cout<<"[Keygen] Leave empty for us to generate entropy as a password."<<endl;
     char* pwd=getpass("[Keygen] Enter boot password: ");
     if (strlen(pwd)==0) {

Blastproof/src/libs/src/vftm.c

@@ -194,10 +194,10 @@ EFI_STATUS bp_vftm_check_manifest_authenticity(UINT8 *pk_root,UINT8* sig_root) {
   status=bp_crypto_sphincsplus_verify(assets.manifest_signature,CRYPTO_BYTES,(UINT8*)&assets.manifest,sizeof(assets.manifest),assets.pk_manifest);
   if (EFI_ERROR(status)) {
     Print(L"[BlastVFTM] Error: critical security violation in boot process:\n",status);
-    Print(L"[BlastVFTM] Provided Vystem FAT Trusted Manifest couldn't be authentified.\n",status);
+    Print(L"[BlastVFTM] Provided Vystem B FAT Trusted Manifest couldn't be authentified.\n",status);
     while (TRUE) {};
   }
-  Print(L"[BlastVFTM] Successfully authentified provided Vystem FAT Trusted Manifest.\n",status);
+  Print(L"[BlastVFTM] Successfully authentified provided Vystem B FAT Trusted Manifest.\n",status);
   return EFI_SUCCESS;
 }
 EFI_STATUS bp_vftm_check_manifest_content() {

build.json

@@ -2,7 +2,7 @@
   "version":"0.1",
   "root_folder":"%filefolder%",
   "run_context":"root",
-  "name":"Vystem build",
+  "name":"Vystem B build",
   "global_uuid":[
     "INITFS_UNIQUE_UUID",
     "SIGNSYST_UNIQUE_UUID",

common/versions.h

@@ -1,5 +1,5 @@
 // SPDX-License-Identifier: MPL-2.0
-// This file provide the versions of all the components of Vystem
+// This file provide the versions of all the components of Vystem B
 #ifndef VY_COMMON_VERSIONS
 #define VY_COMMON_VERSIONS
 #define VY_COMMON_VERSIONS_OS 0x00000002

disk.json

@@ -24,7 +24,7 @@
         "unique_guid_variables":true,
         "unique_guid":"$ESP_PARTITION_UNIQUE_GUID$",
         "name_variables":false,
-        "name":"Vystem ESP Partition",
+        "name":"Vystem B ESP Partition",
         "source_file_variables":true,
         "source_file":"%rootcallerfolder%/$EDK2_DIR$/esp.bin"
       }

docs/blastproof/bootprocess.md

@@ -28,5 +28,5 @@ Blastproof boot process follow a very rigid sequences of steps that are detaille
   - Generating Shelter boot configuration
   - Allocating pages for kernel sections
   - Creating page table
-  - Parsing EFI Memory Map and transforming it into a understandable format for Vystem
+  - Parsing EFI Memory Map and transforming it into a understandable format for Vystem B
   - Jumping to kernel

docs/blastproof/fbm.md

@@ -13,7 +13,7 @@ Each FBM font start with the following 10 bytes header:
 - Width: 1 byte, the width in pixel of a glyph
 - Height: 1 byte, the heigth in pixel of a glyph
 
-Please note that the provided font in Vystem are only tested for ASCII encoding.
+Please note that the provided font in Vystem B are only tested for ASCII encoding.
 
 ## Glyphs table
 
@@ -50,4 +50,4 @@ When rendering the font, the renderer will take two values: background color and
 
 ## Provided font
 
-Vystem provides a basic font named `bitra`, with 12 pixels as width and 20 as height, only supporting ASCII characters. This font is stored in the file `FONT.FBM`.
+Vystem B provides a basic font named `bitra`, with 12 pixels as width and 20 as height, only supporting ASCII characters. This font is stored in the file `FONT.FBM`.

docs/blastproof/fs.md

@@ -2,7 +2,7 @@
 
 ## Introduction
 
-Vystem define two new filesystems: InitFS and SignSyst. The purpose of these filesystems are to store any sensitive systems files. Both of these filesystems are designed to be integrated together. For each InitFS, there is always a SignSyst and vice versa. These filesystems are generated by the `initfsgen` utility. In this file, we describe how they are structured, not how they are generated, verified or used. Please take note that these filesystems has been designed for the x86-64 architecture and for little endian usage.
+Vystem B define two new filesystems: InitFS and SignSyst. The purpose of these filesystems are to store any sensitive systems files. Both of these filesystems are designed to be integrated together. For each InitFS, there is always a SignSyst and vice versa. These filesystems are generated by the `initfsgen` utility. In this file, we describe how they are structured, not how they are generated, verified or used. Please take note that these filesystems has been designed for the x86-64 architecture and for little endian usage.
 
 ## InitFS
 

docs/blastproof/index.md

@@ -2,11 +2,11 @@
 
 ## Introduction
 
-Blastproof is Vystem's bootloader. It is a UEFI x86-64 only bootloader that rely on EDK II for all hardware interactions. It is able to confirm the integrity of his files and partition, locate the kernel and load it into memory, using the specific boot protocol designed for Shelter.
+Blastproof is Vystem B's bootloader. It is a UEFI x86-64 only bootloader that rely on EDK II for all hardware interactions. It is able to confirm the integrity of his files and partition, locate the kernel and load it into memory, using the specific boot protocol designed for Shelter.
 
 ## Blastproof architectural overview
 
-The Blastproof bootloader rely mainly on the EDK II framework for printing to the EFI console, interacting with disks and FAT32 filesystem, graphic output protocol, and memory allocation. However, it uses Vystem standard formats for fonts, filesystems, security and integrity checks, graphic renderer, and kernel loading.
+The Blastproof bootloader rely mainly on the EDK II framework for printing to the EFI console, interacting with disks and FAT32 filesystem, graphic output protocol, and memory allocation. However, it uses Vystem B standard formats for fonts, filesystems, security and integrity checks, graphic renderer, and kernel loading.
 
 ## Ressources
 
@@ -14,7 +14,7 @@ The Blastproof bootloader rely mainly on the EDK II framework for printing to th
 2) [Keyboard layouts](kbdlayout.md)
 2) [Boot configuration](bootconfig.md)
 3) [Security and integrity model at boot level](security.md)
-4) [Vystem FAT Trusted Manifest](vftm.md)
+4) [Vystem B FAT Trusted Manifest](vftm.md)
 5) [Secure Boot Files Integrity Enforcement (SBFIE)](sbfie.md)
 6) [Custom filesystems](fs.md)
 7) [Font Bitmap](fbm.md)

docs/blastproof/vftm.md

@@ -1,8 +1,8 @@
-# Vystem FAT Trusted Manifest
+# Vystem B FAT Trusted Manifest
 
 ## Introduction
 
-Vystem FAT Trusted Manifest (VFTM) is a structure that can be found in the reserved sectors of any FAT32 filesystem generated by VyBuild (please see the conditions for VyBuild to generate this manifest in the VyBuild documentation). It's the first layer of defense in the Vystem Secure Boot Chain, being verified independantly at each boot.
+Vystem B FAT Trusted Manifest (VFTM) is a structure that can be found in the reserved sectors of any FAT32 filesystem generated by VyBuild (please see the conditions for VyBuild to generate this manifest in the VyBuild documentation). It's the first layer of defense in the Vystem B Secure Boot Chain, being verified independantly at each boot.
 
 ## Position and structure
 
@@ -34,7 +34,7 @@ VyBuild will sign the generated manifest with `sk_manifest`, and erase it immedi
 The manifest structure can be represented like this:
 ``` C
 #pragma pack(1)
-struct vystem_fat_trusted_manifest {
+struct vystem_b_fat_trusted_manifest {
   uint8_t sig[8];
   uint16_t manifest_version;
   uint16_t bootloader_version;

docs/boottools/bootanim.md

@@ -2,7 +2,7 @@
 
 ## Introduction
 
-The `bootanim` utility is responsible for generating the boot animation. It is used even if the bootloader configuration specify to not play the boot animation, as it contain the Vystem logo blueprint.
+The `bootanim` utility is responsible for generating the boot animation. It is used even if the bootloader configuration specify to not play the boot animation, as it contain the Vystem B logo blueprint.
 
 ## Detailled informations
 
@@ -42,12 +42,12 @@ bootanim logo.png folder 2160 1440
 The first thing to know about Blastproof boot animation is that, due to poor FAT32 read performance, we decided to find a compromise between the amount of data being stored into the generated file and the amount of data computed at each boot. In order to maintain a fluid, 60 fps animation at each boot on most hardware, we landed on this compromise:
 - We only store 16 frames per second, under the form of points coordinates
 - The 48 others frames per second are computed using linear interpolation at each boot
-This result in the `bootanim.bin` file being only 14 megabytes in size, instead of 56 megabytes, for the actual Vystem logo and a resolution of 1920x1080.
+This result in the `bootanim.bin` file being only 14 megabytes in size, instead of 56 megabytes, for the actual Vystem B logo and a resolution of 1920x1080.
 
 The detailled generation procedure is as follow:
 1) Locate and open the logo file in monochrom mode (with only one color channel, conversion is made by stb_image). The utility will reject any non-square logo.
 2) Center the logo on a black canva the size provided by `width` and `height` arguments.
-3) Scan the canva to detect all points that have their value over 127. Save these points with their coordinates. In the Vystem logo, there is over 45k points.
+3) Scan the canva to detect all points that have their value over 127. Save these points with their coordinates. In the Vystem B logo, there is over 45k points.
 4) For each of these points, generate a random position in the canva, the seed doesn't have any cryptographic implication and is randomised for every new build.
 5) Apply two quadratic bezier curves: one for the "explosion" (all points starting from the exact center of the screen and being scattered around the screen to their random position) and one for the logo appearence (each point is assigned a random coordinates in the logo points and will be attrected to this position from their random position).
 6) Generate the selected output media and write it into the files.

docs/boottools/commoncrypto.md

@@ -8,7 +8,7 @@ The `commoncrypto` library is responsible for providing all cryptographic functi
 
 Folder: `Blastproof/commoncrypto`
 
-It's build using VyBuild, as both a static and shared library. The provided build file doesn't allow yet for the library to be build outside of Vystem build process.
+It's build using VyBuild, as both a static and shared library. The provided build file doesn't allow yet for the library to be build outside of Vystem B build process.
 
 The `-Ofast -march=native` is used on every source file, to make it faster in every use case.
 

docs/boottools/fontgen.md

@@ -25,7 +25,7 @@ fontgen <text color> <background color> [ascii/utf8/utf16] <path to folder conta
 ```
 
 The text and background color arguments must be given under a hexadecimal RGB color code, starting with `#`. They serve as boundary for generating the shading scale.
-The encoding argument can be `ascii`, `utf8` or `utf16`, however in Vystem build script, only the `ascii` encoding is used. Others supported encoding modes haven't been tested.
+The encoding argument can be `ascii`, `utf8` or `utf16`, however in Vystem B build script, only the `ascii` encoding is used. Others supported encoding modes haven't been tested.
 The final argument is the path to the folder that contain all images files for the font characters.
 Each character is encoded with the following format:
 - they must named with this format `0xXXXXXXXX` where `X` is an hexadecimal character. All `X` aren't mandatory, and the utility interprete them as characters codepoint. For example, file name `0x00` will be interpreted as a codepoint of value `0x00000000`, resulting in the `\0` character for ASCII

docs/boottools/index.md

@@ -1,6 +1,6 @@
 # Bootloader tools Docs
 
-In order to generate all necessary components for the build of a Vystem disk image, we have created several C++ tools and library designed to help generating these components. All of these tools have been intented to be used only in a normal Linux environnement. Here is the list of bootloader tools:
+In order to generate all necessary components for the build of a Vystem B disk image, we have created several C++ tools and library designed to help generating these components. All of these tools have been intented to be used only in a normal Linux environnement. Here is the list of bootloader tools:
 1) [commoncrypto](commoncrypto.md)
 2) [bootanim](bootanim.md)
 3) [fontgen](fontgen.md)

docs/boottools/initfsgen.md

@@ -9,7 +9,7 @@ The `initfsgen` utility is responsible for generating the InitFS and SignSyst fi
 Folder: `Blastproof/initfsgen`
 Source code file: `initfsgen.cpp`
 
-For building `initfsgen`, you will need to use the provided build file. But for the moment, the provided build file doesn't allow yet for the utility to be build outside of Vystem build process. The build file will require `libcommoncrypto.a` to be provided inside the `initfsgen` folder.
+For building `initfsgen`, you will need to use the provided build file. But for the moment, the provided build file doesn't allow yet for the utility to be build outside of Vystem B build process. The build file will require `libcommoncrypto.a` to be provided inside the `initfsgen` folder.
 
 External library provided by `commoncrypto` and used inside `initfsgen`:
 - SPHINCS+, made by the SPHINCS+ team, sourced from [sphincs/sphincsplus](https://github.com/sphincs/sphincsplus), under the MIT-0 license

docs/boottools/keygen.md

@@ -9,7 +9,7 @@ The `keygen` utility is responsible for generating VFTM keys, SBFIE keys, files
 Folder: `Blastproof/keygen`
 Source code file: `keygen.cpp`
 
-For building `keygen`, use the provided build file. The provided build file doesn't allow yet for the utility to be build outside of Vystem build process.
+For building `keygen`, use the provided build file. The provided build file doesn't allow yet for the utility to be build outside of Vystem B build process.
 
 External libraries provided by `commoncrypto` and used inside `keygen`:
 - SPHINCS+, made by the SPHINCS+ team, sourced from [sphincs/sphincsplus](https://github.com/sphincs/sphincsplus), under the MIT-0 license

docs/build.md

@@ -2,22 +2,22 @@
 
 ## Introduction
 
-In this file, we will see how you can build and boot successfully into a VM containing a Vystem disk image or boot a Vystem instance on a real computer. It's recommanded to read the whole documentation for better understanding of why certains parts are necessary.
+In this file, we will see how you can build and boot successfully into a VM containing a Vystem B disk image or boot a Vystem B instance on a real computer. It's recommanded to read the whole documentation for better understanding of why certains parts are necessary.
 
 ## Prerequisites
 
-You should have cloned the full repository on your device. You can uses Vystem in two cases:
+You should have cloned the full repository on your device. You can uses Vystem B in two cases:
 - in a VM
 - on a real computer
 
-In both cases, Vystem has been designed to be build and run from a standard Linux system. Any Linux distro should work. A WSL environnement can also work but, if you are testing in a VM, the VM might be very slow or unstable in the benchmark results, because of KVM unavailability. Make sure you have KVM enable and accessible before starting, or else remove the `-accel kvm` argument at the end of the `build.json` file.
+In both cases, Vystem B has been designed to be build and run from a standard Linux system. Any Linux distro should work. A WSL environnement can also work but, if you are testing in a VM, the VM might be very slow or unstable in the benchmark results, because of KVM unavailability. Make sure you have KVM enable and accessible before starting, or else remove the `-accel kvm` argument at the end of the `build.json` file.
 
 Before starting, please make sure that you have the following binary reachable in your terminal path:
 ``` 
 python3 python nasm g++ gcc iasl git make unzip  
 ```
 
-You may also want `qemu-system-x86_64` if you are testing Vystem in a VM.
+You may also want `qemu-system-x86_64` if you are testing Vystem B in a VM.
 
 Finally, please make sure that you have an internet connexion if EDK II isn't yet setuped as well as root access/sudo permissions, as it is necessary for running `keygen`. Root permissions is only obtained as soon as it's needed.
 
@@ -48,7 +48,7 @@ vybuild/vybuild build.json img
 
 Then, just flash the generated disk image on a USB disk and boot from it on real hardware.
 
-**Warning:** depending the properties of the firmware and available video cards on the hardware used to test Vystem, the EFI GOP framebuffer might not survive after ExitBootServices.
+**Warning:** depending the properties of the firmware and available video cards on the hardware used to test Vystem B, the EFI GOP framebuffer might not survive after ExitBootServices.
 
 ## Troubleshooting
 

docs/commonlib.md

@@ -2,8 +2,8 @@
 
 ## Introduction
 
-Commonlib is a very simple C library that contains informations useful to all parts of Vystem. All the source code of Commonlib is stored inside the `common` folder.
+Commonlib is a very simple C library that contains informations useful to all parts of Vystem B. All the source code of Commonlib is stored inside the `common` folder.
 
 ## Versions
 
-The header `versions.h` defines the versions number of various Vystem components.
+The header `versions.h` defines the versions number of various Vystem B components.

docs/index.md

@@ -1,19 +1,19 @@
-# Vystem Docs
+# Vystem B Docs
 
 **Warning:** this documentation only includes currently implemented elements and doesn't include plannned future elements, except some confirmed planned updates scattered within the documentation
 
 ## Introduction
 
-Welcome to Vystem documentation. This documentation is divided into severals parts for easier understanding.
+Welcome to Vystem B documentation. This documentation is divided into severals parts for easier understanding.
 
 ## Components
 
-Vystem is an OS made of severals components which can be divided into severals categories:
+Vystem B is an OS made of severals components which can be divided into severals categories:
 1) [Blastproof](blastproof/index.md): the bootloader 
 2) [Bootloader tools](boottools/index.md): all the tools needed to generate components for the boot process
-3) [Vyx](vyx.md): Vystem Executable format
+3) [Vyx](vyx.md): Vystem B Executable format
-4) [VyBuild](vybuild/index.md): Vystem build system
+4) [VyBuild](vybuild/index.md): Vystem B build system
-5) [Commonlib](commonlib.md): very simple library that contains informations useful to all parts of Vystem
+5) [Commonlib](commonlib.md): very simple library that contains informations useful to all parts of Vystem B
 6) [Shelter](shelter/index.md): the kernel
 7) [Kernel tools](kerneltools/index.md): all the `.py` scripts used for various usage around the kernel
 

docs/licenses.md

@@ -2,7 +2,7 @@
 
 All license files can be found in the `licenses/` directory.
 
-License texts for Vystem components are derived from [IQAndreas/markdown-licenses](https://github.com/IQAndreas/markdown-licenses), while third-party license texts are extracted from their respective original repositories.
+License texts for Vystem B components are derived from [IQAndreas/markdown-licenses](https://github.com/IQAndreas/markdown-licenses), while third-party license texts are extracted from their respective original repositories.
 
 ## Licenses
 
@@ -12,7 +12,7 @@ All `.md` files stored in the root directory and in the `docs` folder are under
 
 ## Third party licenses
 
-The following third party libraries are used in Vystem:
+The following third party libraries are used in Vystem B:
 
 Original source code | Author | License
 --- | --- | ---

docs/roadmap.md

@@ -28,12 +28,12 @@ Initial release
   - A new build system, see documentation for more informations
 - Commoncrypto:
   - A new library made of three cryptographic libraries, required for Keygen, Initfsgen and VyBuild 
-- Vystem FAT Trusted Manifest:
+- Vystem B FAT Trusted Manifest:
   - A new signed manifest, injected inside the reserved sectors of the ESP partition FAT32
   - It's signed using a combinaison of Keygen and VyBuild
   - It allow to verify the link between ESP partition and current disk, as well as FAT32 integrity and self bootloader verification
 - Common Lib:
-  - In the `common` folder, new headers that will be accessible to all components of Vystem will be put here
+  - In the `common` folder, new headers that will be accessible to all components of Vystem B will be put here
   - For the moment, it only includes the reference version of each component
 - Shelter:
   - Can now manage TSS, GDT and IDT

docs/shelter/index.md

@@ -2,7 +2,7 @@
 
 ## Introduction
 
-Shelter is an hybrid kernel developped alongside and for the Vystem project. 
+Shelter is an hybrid kernel developped alongside and for the Vystem B project. 
 
 ## Principles
 

docs/shelter/ptp.md

@@ -2,7 +2,7 @@
 
 ## Introduction
 
-In order to easily manage pages that are used for pages tables (PT), the Vystem project use pages tables pool (PTP). For details about mapping the PTP inside the kernel virtual memory space, please see [boot contract docs](bootcontract.md).
+In order to easily manage pages that are used for pages tables (PT), the Vystem B project use pages tables pool (PTP). For details about mapping the PTP inside the kernel virtual memory space, please see [boot contract docs](bootcontract.md).
 
 ## Overview
 

docs/vybuild/index.md

@@ -2,7 +2,7 @@
 
 ## Introduction
 
-VyBuild is Vystem build system. It has been designed to considerably reduce the need for external tools and the pain of writing custom scripts. It is opinionated and optimized for OS development. While it was designed for Vystem, it can be used for others OS project, but feature such as Vyx/Vyld usage and VFTM aren't guaranteed to work. VyBuild is very integrated into the Vystem ecosystem and should not be considered complete for now.
+VyBuild is Vystem B build system. It has been designed to considerably reduce the need for external tools and the pain of writing custom scripts. It is opinionated and optimized for OS development. While it was designed for Vystem B, it can be used for others OS project, but feature such as Vyx/Vyld usage and VFTM aren't guaranteed to work. VyBuild is very integrated into the Vystem B ecosystem and should not be considered complete for now.
 
 ## Features
 
@@ -18,7 +18,7 @@ VyBuild is capable of the following:
 - Letting the user uses system variables (like `%rootcallerfolder%`) or define their own to use in almost any actions field, as well as providing variable on command line argument of VyBuild
 - Running differents actions or modules depending on differents condition, like folder existence, cache presence or variable value/existence
 - Create fully valid FAT32 images (only support short file names) and fully valid disk images with GPT tables, custom type/unique partitions GUID and importing partitions from file
-- Integrating Vystem FAT Trusted Manifest support for FAT32 images generation and interaction with `keygen`
+- Integrating Vystem B FAT Trusted Manifest support for FAT32 images generation and interaction with `keygen`
 
 ## Index
 

docs/vybuild/usage.md

@@ -2,7 +2,7 @@
 
 ## Build
 
-In order to use VyBuild, you must compile it first. For this, use the `build.sh` script located in the `vybuild` folder. This script should only be used from the root folder of the Vystem project, just like this:
+In order to use VyBuild, you must compile it first. For this, use the `build.sh` script located in the `vybuild` folder. This script should only be used from the root folder of the Vystem B project, just like this:
 
 ``` bash
 vybuild/build.sh

docs/vyx.md

@@ -2,7 +2,7 @@
 
 ## Introduction
 
-The VYX format, standing for Vystem Executable, is a very simple binary format made for simple binary loading from any environnement. As long as you can access the `.vyx` file, you can load a VYX binary. 
+The VYX format, standing for Vystem B Executable, is a very simple binary format made for simple binary loading from any environnement. As long as you can access the `.vyx` file, you can load a VYX binary. 
 
 ## Header
 
@@ -43,7 +43,7 @@ If the payload size in bytes is bigger that the remaining size in bytes into the
 
 ## Specifications
 
-The VYX binaries use the SystemV ABI. They doesn't support rellocations nor dynamic linking. While relative addressing into the binary code is theoretically working, all the Vystem binaries will be compiled 64 bits static addressing with position-dependent code (non-PIC), especially the kernel. That why respecting the indicated `.text` section base and order of sections loading is extremely important.
+The VYX binaries use the SystemV ABI. They doesn't support rellocations nor dynamic linking. While relative addressing into the binary code is theoretically working, all the Vystem B binaries will be compiled 64 bits static addressing with position-dependent code (non-PIC), especially the kernel. That why respecting the indicated `.text` section base and order of sections loading is extremely important.
 Obviously, the right privileges should be applied in term of pagging: no execution unless `.text` pages, read only `.text` and `.rodata` sections, read-write `.data` and `.bss` sections.
 For the moment, the entry point is located at the base of the `.text` section.
 The stack size can be decided at the convenience of the loader, but the stack size used for the Shelter kernel is, for the moment, 256 kilobytes. The stack growing downward, the initial stack pointer should be set to stack base + stack size.