Update docs (microsoft#665)

* Update docs

Fixes microsoft#651
Fixes microsoft#655

Signed-off-by: Dave Thaler <dthaler@microsoft.com>

* Fix xdp_hook_t documentation

Signed-off-by: Dave Thaler <dthaler@microsoft.com>

* Address CR comment

Signed-off-by: Dave Thaler <dthaler@microsoft.com>

Co-authored-by: Alan Jowett <alanjo@microsoft.com>

README.md

@@ -17,26 +17,22 @@ The following diagram shows the architecture of this project and related compone
 ![Architectural Overview](docs/ArchitectureDiagram.png)
 
 As shown in the diagram, existing eBPF toolchains (clang, etc.) can be used to generate eBPF bytecode from
-source code in various languages.  Bytecode can be consumed by any application, or via the Netsh command line tool, which use a shared library
+source code in various languages.  Bytecode can be consumed by any application, or via bpftool or the Netsh command line tool, which use a shared library
 that exposes [Libbpf APIs](https://github.com/libbpf/libbpf),
 though this is still in progress.
 
 The eBPF bytecode is sent to a static verifier (the [PREVAIL verifier](https://github.com/vbpf/ebpf-verifier))
-that is hosted in a user-mode [protected process](https://docs.microsoft.com/en-us/windows/win32/services/protecting-anti-malware-services-#system-protected-process)
-(a Windows security environment that allows a kernel component to trust a user-mode daemon signed by
-a key that it trusts).  If the bytecode passes all the verifier checks, it can be either loaded into
+that is hosted in a secure user-mode environment such as a system service (which is the case at present),
+enclave, or trusted VM.
+If the bytecode passes all the verifier checks, it can be either loaded into
 an interpreter (from [uBPF](https://github.com/iovisor/ubpf) in the kernel-mode execution context), or
 JIT compiled (via the [uBPF](https://github.com/iovisor/ubpf) JIT compiler) and have native code load
 into the kernel-mode execution context (but see the FAQ at bottom about HVCI).
 
-*Temporary Note: some parts are still under development and may not appear
-when building the master branch, but the end-to-end functionality can still be tested immediately
-while the security hardening is still in progress.*
-
 eBPF programs installed into the kernel-mode execution context can attach to various hooks (currently
-two hooks so far: an XDP-like hook that is based on the Windows Filtering Platform (WFP) [layer 2 filtering](https://docs.microsoft.com/en-us/windows-hardware/drivers/network/using-layer-2-filtering), and a socket bind hook) and call various helper APIs exposed by the eBPF shim,
+two hooks so far: an XDP hook that integrates with the Windows Filtering Platform (WFP) [layer 2 filtering](https://docs.microsoft.com/en-us/windows-hardware/drivers/network/using-layer-2-filtering), and a socket bind hook) and call various helper APIs exposed by the eBPF shim,
 which internally wraps public Windows kernel APIs, allowing the use of eBPF on existing versions of Windows.
-More hooks and helpers will be added over time.
+Many helpers already exist, and more hooks and helpers will be added over time.
 
 ## Getting Started