Add what to verify section (#85)

* Add what to verify section

* Fix syntax

* Minor updates to verify paragraph in elf part

* Update updates

* Fix broken link

* Move useful info section from appendices

* Changes requested

* Minor fix on Nasm appendice

* Minor typo fixes

* Minor fix on cross compiling chapter

* Minor fix on cross compile chapter

* changes requested

Author: dreamos82

00_Introduction/01_README.md

@@ -25,6 +25,6 @@ Below the list of parts that compose the book:
 * *Inter-Process Communication (IPC)* - This part looks at how we might implement IPC for our kernel, allowing isolated programs to communicate with each other in a controlled way. 
 * *Virtual File System (VFS)* - This part will cover how a kernel presents different file systems to the rest of the system. We'll also take a look at implementing a 'tempfs' that is loaded from a tape archive (tar), similar to initrd. 
 * *The ELF format* - Once we have a file system we can load files from it, why not load a program? This part looks at writing a simple program loader for ELF64 binaries, and why you would want to use this format.
-* *Going Beyond* - The final part (for now). We have implemented all the core components of a kernel, and we are free to go from here. This final chapter contains some ideas for new components that you might want to add, or at least begin thinking about.
+* *Going Beyond* - The final part (for now). We have implemented all the core components of a kernel, and we are free to go from here. This final chapter contains some ideas for new components that we might want to add, or at least begin thinking about.
 
 In the appendices we cover various topic, from debugging tips, language specific information, troubleshooting, etc.

05_Scheduling/03_Processes_And_Threads.md

@@ -249,7 +249,7 @@ thread_t* add_thread(process_t* proc, char* name, void(*function)(void*), void*
 }
 ```
 
-You'll notice this function looks almost identical to the `create_process` function from before. That's because a lot of it is the same! The first part of the function is just inserting the new thread at the end of the list of threads.
+We can see that this function looks almost identical to the `create_process` outlined earlier in this chapter. That's because a lot of it is the same! The first part of the function is just inserting the new thread at the end of the list of threads.
 
 Let's look at how our `create_process` function would look now:
 

09_Loading_Elf/01_Elf_Theory.md

@@ -78,12 +78,12 @@ Finding the program headers within an ELF binary is also quite straightforward.
 Like section headers, each program header is tighly packed against the next one. This means that  program headers can be treated as an array. As an example is possible to loop through the _phdrs_ as follows:
 
 ```c
-void loop_phdrs(Elf64_Hdr* ehdr) {
-    Elf64_Phdr* phdrs = *(Elf64_Phdr*)((uintptr_t)ehdr + ehdr->e_phoff);
+void loop_phdrs(Elf64_Ehdr* ehdr) {
+    Elf64_Phdr* phdrs = (Elf64_Phdr*)((uintptr_t)ehdr + ehdr->e_phoff);
 
     for (size_t i = 0; i < ehdr->e_phnum; i++)
     {
-        Elf64_Phdr* program_header = phdrs[i];
+        Elf64_Phdr program_header = phdrs[i];
         //do something with program_header here.
     }
 }

09_Loading_Elf/02_Loading_And_Running.md

@@ -14,14 +14,56 @@ In the previous chapter we looked at the details of loading program headers, but
 
 - First a copy of the ELF file to be loaded is needed. The recommended way is to load a file via the VFS, but it could be a bootloader module or even embedded into the kernel.
 - Then once the ELF is loaded, we need verify that its header is correct. Also check the architecture (machine type) matches the current machine, and that the bit-ness is correct (dont try to run a 32-bit program if you dont support it!).
-- Find all the loadable program headers for the ELF, we'll need those in a moment.
+- Find all the program headers with the type `PT_LOAD`, we'll need those in a moment.
 - Create a new address space for the program to live in. This usually involves creating a new process with a new VMM instance, but the specifics will vary depending on your design. Don't forget to keep the kernel mappings in the higher half!
 - Copy the loadable program headers into this new address space. Take care when writing this code, as the program headers may not be page-aligned:. Don't forget to zero the extra bytes between `memsz` and `filesz`.
 - Once loaded, set the appropriate permission on the memory each program header lives in: the write, execute (or no-execute) and user flags.
 - Now we'll need to create a new thread to act as the main thread for this program, and set its entry point to the `e_entry` field in the ELF header. This field is the start function of the program. You'll also need to create a stack in the memory space of this program for the thread to use, if this wasnt already done as part of our thread creation.
 
 If all of the above are done,  then the program is ready to run! We now should be able to enqueue the main thread in the scheduler and let it run.
 
+### Verifying an ELF file
+
+When veryfying an ELF file there are few things we need to check in order to decide if an executable is valid, the fields to validate are at different points in the ELF header. Some can be found in the `e_ident` field, like the following:
+
+* The first thing we want to check is the magic number, this is the `ELFMAG` part. It is expected to be the following values: 
+
+| Value | Byte|
+|-------|-----|
+| `0x7f`| 0 |
+| `E`   | 1 |
+| `L`   | 2 |
+| `F`   | 3 |
+
+* We need to check that the file class match with the one we are supporting. There are two possible classes: 64 and 32. This is byte 4
+* The data field indicates the _endiannes_, again this depends on the architecture used. It can be three values: None (0), LSB (1) and MSB (2). For example `x86_64` architecture endiannes is LSB, then the value is expected to be 1. This field is in the byte 5.
+* The version field, byte 6,  to be a valid elf it has to be set to 1 (EVCURRENT).
+* The OS Abi and Abi version they  identify the operating system together with the ABI to which the object is targeted and the version of the ABI to which the object is targeted, for now we can ignore them, the should be 0.
+
+Then from the other fields that need validation (that area not in the `e_ident` field) are:
+
+* `e_type`: this identifies the type of elf, for our purpose the one to be considered valid this value should be 2 that indicates an Executable File (ET_EXEC) there are other values that in the future we could support, for example the `ET_DYN` type that is used for position independent code or shared object, but they require more work to be done.
+* `e_machine`: this indicates the required architecture for the executable, the value depends on the architectures we are supporting. For example the value for the AMD64 architecture is `62`
+
+Be aware that most of the variables and their values have a specific naming convention, for more information refer to the ELF specs.
+
+Beware that some compilers when generating a simple executable are not using the `ET_EXEC` value, but it could be of the type `ET_REL` (value 1), to obtain an executable we need to link it using a linker. For example if we generated the executable: `example.elf` with `ET_REL` type, we can use `ld` (or another equivalent linker):
+
+```sh
+ld -o example.o example.elf
+```
+
+For basic executables, we most likely don't need to include any linker script. 
+
+If we want to know the type of an elf, we can use the `readelf` command, if we are on a unix-like os: 
+```sh
+readelf -e example.elf
+``` 
+
+Will print out all the executable information, including the type.
+
+
+
 ## Caveats
 
 As we can already see from the above restrictions there is plenty of room for improvement. There are also some other things to keep in mind:

99_Appendices/C_Language_Info.md

@@ -199,8 +199,3 @@ If unfamiliar with caching, each page can have a set of caching attributes appli
 One of these is write-combine. It works by queueing up writes to nearby areas of memory, until a buffer is full, and then flushing them to main memory in a single access. This is much faster than accessing main memory each write.
 
 However if we're working with an older x86 cpu, or another platform, this solution is not available. Hence `volatile` would do the job.
-
-### Useful Links
-
-* [IBM inline assembly guide](https://www.ibm.com/docs/en/xl-c-and-cpp-linux/13.1.4?topic=compatibility-inline-assembly-statements) This is not gcc related, but the syntax is identical, and it contains useful and concise info on the constraintsa
-* [Fedora Inline assembly list of constraints](https://dmalcolm.fedorapeople.org/gcc/2015-08-31/rst-experiment/how-to-use-inline-assembly-language-in-c-code.html#simple-constraints)

99_Appendices/D_Nasm.md

@@ -79,15 +79,16 @@ quad_var:
 	dq	133.463 ; Example with a real number
 ```
 
-But what if we want to declare a string? Well in  this case we can use a different syntax for db:
+If we want to declare a string we need to use a different syntax for db:
 
 ```nasm
 string_var:
 	db	"Hello", 10
 ```
-What does it mean? We are simply declaring a variable (string_variable) that starts at 'H', and fill the consecutive bytes with the next letters. But what about the last number? It is just an extra byte, that represents the newline character. So what we are really storing is the string _"Hello\\n"_
 
-Now what we have seen so far is valid for a variable that can be initialized with a value, but what if we don't know the value yet, but we want just to "label" it with a variable name? Well is pretty simple, we have equivalent directives for reserving memory:
+The above code means that we are declaring a variable (`string_variable`) that starts at 'H', and fill the consecutive bytes with the next letters. And what about the last number? It is just an extra byte, that represents the newline character, so what we are really storing is the string _"Hello\\n"_
+
+What we have seen so far is valid for a variable that can be initialized with a value, but what if we don't know the value yet, but we want just to "label" it with a variable name? Well is pretty simple, we have equivalent directives for reserving memory:
 
 | Directive   | Description                     |
 |-------------|---------------------------------|

99_Appendices/E_Cross_Compilers.md

@@ -36,7 +36,7 @@ There's three environment variables we're going to use during the build process:
 
 ```
 export PREFIX="/your/path/to/cross/compiler"
-export TARGET="riscv64-elf"
+export TARGET="x86_64-elf"
 export PATH="$PREFIX/bin:$PATH"
 ```
 
@@ -154,16 +154,16 @@ Qemu is quite a large program, so it's recommended to make use of all cores when
 
 ## GDB
 
-The steps for building GDB are similar to binutils and GCC. We'll create a temporary working directory and move into it. Gdb has a few extra dependencies we'll need:
+The steps for building GDB are similar to binutils and GCC. We'll create a temporary working directory and move into it. Gdb has a few extra dependencies we'll need (name can be different depending on the distribution used):
 
 * libncurses-dev
-* libsource-highligh-dev
+* libsource-highlight-dev
 
 ```bash
 path/to/gdb_sources/configure --target=$TARGET  --host=x86_64-linux-gnu  --prefix="$PREFIX" --disable-werror --enable-tui --enable-source-highlight
 ```
 
-The last two options enable compiling the text-user-interface (`--enable-tui`) and source code highlighting (`--enable-source-highlight) which are nice-to-haves. These flags can be safely omitted if these aren't features we want.
+The last two options enable compiling the text-user-interface (`--enable-tui`) and source code highlighting (`--enable-source-highlight`) which are nice-to-haves. These flags can be safely omitted if these aren't features we want.
 
 The `--target=` flag is special here in that it can also take an option `all` which builds gdb with support for every single architecture it can support. If we're going to develop on one machine but test on multiple architectures (via qemu or real hardware) this is nice. It allows a single instance of gdb to debug multiple architectures without needing different versions of gdb. Often this is how the 'gdb-multiarch' package is created for distros that have it.
 

99_Appendices/H_Useful_Resources.md

@@ -81,6 +81,11 @@ This appendix is a collection of links we found useful developing our own kernel
 - Osdev Wiki Page ELF Tutorial: [https://wiki.osdev.org/ELF_Tutorial](https://wiki.osdev.org/ELF_Tutorial)
 - x86-64 psABI: [https://gitlab.com/x86-psABIs/x86-64-ABI](https://gitlab.com/x86-psABIs/x86-64-ABI)
 
+## C Language Infos
+
+* [IBM inline assembly guide](https://www.ibm.com/docs/en/xl-c-and-cpp-linux/13.1.4?topic=compatibility-inline-assembly-statements) This is not gcc related, but the syntax is identical, and it contains useful and concise info on the constraintsa
+* [Fedora Inline assembly list of constraints](https://dmalcolm.fedorapeople.org/gcc/2015-08-31/rst-experiment/how-to-use-inline-assembly-language-in-c-code.html#simple-constraints)
+
 ## Nasm
 
 * Nasm Struct Section: [https://www.nasm.us/xdoc/2.15/html/nasmdoc5.html#section-5.9.1](https://www.nasm.us/xdoc/2.15/html/nasmdoc5.html#section-5.9.1)

99_Appendices/J_Updates.md

@@ -45,4 +45,5 @@ Fourth book release
 
 * Typo fixes
 * Expand Syscall example chapter
+* Expand ELF chapter, and fixing code in one of examples
 

README.md

@@ -71,7 +71,7 @@ The [latest-master](https://github.com/dreamportdev/Osdev-Notes/releases/tag/lat
     * [The Tar File System](08_VirtualFileSystem/03_TarFileSystem.md)
 * [Part 9: Loading & Executing ELFs](09_Loading_Elf/README.md)
     * [Theory](09_Loading_Elf/01_Elf_Theory.md)
-    * [Loading and Running](02_Loading_Elf/03_Loading_And_Running.md)
+    * [Loading and Running](09_Loading_Elf/03_Loading_And_Running.md)
 * [Part 10: Going Beyond](10_Going_Beyond/README.md)
 * [Extras: Appendices](99_Appendices/README.md)
     * [General Troubleshooting](99_Appendices/A_Troubleshooting.md)