Update Readme.md

Readme.md

@@ -84,7 +84,7 @@ err = p.Cleanup()
 
 ## VM vs Emulator
 
-eBPF is no longer Linux specific([eBPF for windows](https://github.com/Microsoft/ebpf-for-windows)). Now the [eBPF instruction](https://www.kernel.org/doc/html/latest/bpf/instruction-set.html) set is well defined as must be constant across all platforms(perhaps with the exception of legacy cBPF instructions for packet access). However, the Linux eBPF subsystem makes use of a lot of maps, some if which are generic, but most of which are very specialized and aimed at Linux specific features like cGroups or LSM.
+eBPF is no longer Linux specific([eBPF for windows](https://github.com/Microsoft/ebpf-for-windows)). Now the [eBPF instruction]([https://www.kernel.org/doc/html/latest/bpf/standardization/instruction-set.html](https://www.kernel.org/doc/html/latest/bpf/standardization/instruction-set.html)) set is well defined as must be constant across all platforms(perhaps with the exception of legacy cBPF instructions for packet access). However, the Linux eBPF subsystem makes use of a lot of maps, some if which are generic, but most of which are very specialized and aimed at Linux specific features like cGroups or LSM.
 
 To be able to support all use cases and emulator multiple platforms/environments, Mimic splits functionality into two parts(reals). The "Virtual Machine" which is responsible for all generic features(Instructions, Registers, Memory, Processes). The "Emulator" is interchangeable and provides platform/environment specific features(Helper functions/Maps/Some other construct), besides a Linux emulator we can have a Windows emulator and users of Mimic might even implement their own emulator with custom helper functions specific to their needs.
 
@@ -527,4 +527,4 @@ Note: Marked list items were on the list, but have since been implemented.
 
 - [ ] (optional) real map backing. The idea being that instead of emulating a map, we can use actual BPF maps of the host. It may not be able to simulate all features, disabling syscall writes on a map would also block access for the eBPF program in this case. But baring some limitations, this could allow someone to share a map between the emulator and a loader program, or a real and emulated program. 
 - [ ] emulator helper customization. Allowing users to change or extend the existing Linux emulator. For example to replace the `bpf_probe_read` callback so the Host program can return its own custom memory objects, thus being able integrate the VM/Emulator with the rest of the host application.
-- [ ] high-security settings on the vm. There are moments when we reuse memory(deleting map keys, tailcalls, bpf-to-bpf calls), but don't zero it out before reuse. There might be use cases, especially when running foreign code in a multi tenant environment where this might lead to security issues. Zeroing out memory can be costly, especially if the security use-case doesn't apply, so being able to enable or disable this feature with a VM setting would be nice. (Note: we currently don't zero-memory at all). (Note2: zeroing out memory should also enforce correctness for programs)
+- [ ] high-security settings on the vm. There are moments when we reuse memory(deleting map keys, tailcalls, bpf-to-bpf calls), but don't zero it out before reuse. There might be use cases, especially when running foreign code in a multi tenant environment where this might lead to security issues. Zeroing out memory can be costly, especially if the security use-case doesn't apply, so being able to enable or disable this feature with a VM setting would be nice. (Note: we currently don't zero-memory at all). (Note2: zeroing out memory should also enforce correctness for programs)