docs: fix misspellings in README files

codelab/README.md

@@ -1,6 +1,6 @@
 # Getting Started
 
-This directory contains a minimal template for writting enclave apps with `oak`.
+This directory contains a minimal template for writing enclave apps with `oak`.
 
 ## Usage
 

micro_rpc/README.md

@@ -19,7 +19,7 @@ The client and server objects can connect to each other over a transport. A
 transport consists of a single method, usually called `invoke`, which represents
 an atomic invocation, sending a sequence of bytes and receiving a sequence of
 bytes. microRPC takes care of translating a call on the client object to a
-request messsage, serialize that to bytes, then on the server side deserialize
+request message, serialize that to bytes, then on the server side deserialize
 the bytes into the request message, and dispatching the user request to the
 correct method on the server object, and similarly for the response path back to
 the client.

oak_attestation/README.md

@@ -11,7 +11,7 @@ This library provides an implementation of the
 underlying details of the TEE platform (e.g.,
 [AMD SEV-SNP](https://www.amd.com/en/developer/sev.html) or
 [Intel TDX](https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/overview.html))
-and provides a unified inferface for generating the
+and provides a unified interface for generating the
 [`Evidence`](../proto/attestation/evidence.proto) message needed for
 [Remote Attestation](../docs/remote-attestation.md).
 

oak_containers/app_base/README.md

@@ -106,7 +106,7 @@ runtime unpack them before running them.
 
 While this is definitely feasible, we've decided against it, for a few reasons:
 
-1. Additional logic and maintance overhead in the Oak Containers Orchestrator.
+1. Additional logic and maintenance overhead in the Oak Containers Orchestrator.
 2. Additional overhead when loading an image - now the runtime will have to
    unpack it, adding even more time to the container startup.
 3. Fewer transformations of the measured runtime bundle. We are unpacking your

oak_containers/examples/micro_rpc_noise/README.md

@@ -6,7 +6,7 @@ handle encryption.
 
 - `application` contains the actual application business logic that the rest of
   the demo exposes.
-- `proto` contains the proto messages and service defintions
+- `proto` contains the proto messages and service definitions
 - `service` contains the implementation of the microRPC service
 - `tests` shows a simple end-to-end example
 

oak_containers/system_image/README.md

@@ -9,7 +9,7 @@
 We use this Docker image to build the base system image for Oak Containers.
 
 The bazel-built system image rules layer in freshly-built Oak Containers
-binaries onto a pre-created base image. The base iamge is not re-generated on
+binaries onto a pre-created base image. The base image is not re-generated on
 every run, since it changes very infrequently.
 
 For more information on updating the base image, see `base/README.md`.

oak_functions_abi/README.md

@@ -10,7 +10,7 @@ The Oak Functions WebAssembly module
 - [imports functions](#imported-functions) from the Oak Functions runtime.
 
 The Oak Functions WebAssembly ABI is quite low-level, and it is mostly a way to
-allow building a more expressive API based on an invocation-bsaed
+allow building a more expressive API based on an invocation-based
 [microRPC](/micro_rpc/) transport on top of it.
 
 Oak Functions WebAssembly modules will typically use more convenient (and safer)
@@ -69,7 +69,7 @@ providing the following functions as
   little-endian u32).
 - `result[0]: i32`: numeric
   [`StatusCode`](https://github.com/grpc/grpc/blob/master/doc/statuscodes.md#status-codes-and-their-use-in-grpc)
-  reprsenting the result of the invocation. Note that this is in addition to any
+  representing the result of the invocation. Note that this is in addition to any
   status code that the API implementation may return; it only represents the
   success or failure of the Wasm invocation itself as a transport.
 

oak_functions_standalone/testdata/README.md

@@ -2,7 +2,7 @@
 
 Keys are specified in the form of `"(<lat>,<long>)"` where lat and long have two
 points of precision after the decimal. The values are the temperatures in
-Celsius of those corrdinates. Both the keys and values are UTF-8 encoded.
+Celsius of those coordinates. Both the keys and values are UTF-8 encoded.
 
 The data is for testing only and is not based on real temperature data.
 

oak_linux_boot_params/README.md

@@ -2,7 +2,7 @@
 
 This crate contains (a subset of) the data structures needed to boot the Linux
 kernel, which are of interest to someone who wants to implement a bootloader (or
-a kernel compatbile with the Linux boot protocol).
+a kernel compatible with the Linux boot protocol).
 
 The data structures themselves were first generated with `bindgen` as follows:
 

oak_private_memory/proto/README.md

@@ -1,3 +1,3 @@
 # Private memory service definition
 
-The proto file for the `Invokation Layer` message for private memory service.
+The proto file for the `Invocation Layer` message for private memory service.

oak_proto_rust/README.md

@@ -8,7 +8,7 @@ build.rs file (and update the dependencies for the build script target as
 needed.)
 
 This library is imported into some environments where Prost and/or build scripts
-are not available. To support building our Rust targets in these environmnets,
+are not available. To support building our Rust targets in these environments,
 we also include pre-generated Prost Rust code in the `generated` directory.
 
 The bazel `write_source_files` helps us with this. It creates a rule for copying
@@ -34,7 +34,7 @@ When adding items to `oak_grpc` or `oak_micro_rpc`, ensure that no `message`
 via the `oak_proto_rust` crate.
 
 This can be achieved by ensuring that `ExternPath` items are included in the
-`oak_proto_utils::CodegenOptions` provided to gRPC copmilation calls or
+`oak_proto_utils::CodegenOptions` provided to gRPC compilation calls or
 `micro_rpc_build::CompileOptions` provided to microRPC compilation calls. When
 you provide an `ExternPath` mapping, then whenever a proto message in a package
 starting with the specified proto is encountered, rather than having Prost
@@ -43,7 +43,7 @@ Rust crate path, with the assumption that the messages have been compiled in
 another crate.
 
 For example, if you include an extern path mapping like `.oak` =>
-`::oak_proto_rust::oak`, then whnever the compiler encounters a proto message
+`::oak_proto_rust::oak`, then whenever the compiler encounters a proto message
 with a fully qualified name starting with `.oak`, it won't generate any code for
 that message, instead it will transform the proto package into a Rust crate name
 (essentially, it turns the `.` into `::`), and then it will replace the

oak_session/README.md

@@ -402,7 +402,7 @@ sequenceDiagram
     CH->>+CSV: verify_binding (server_binding)
     CSV-->>-CH: result
 
-    CH->>+CSB: bind(hanshake_hash)
+    CH->>+CSB: bind(handshake_hash)
     CSB-->>-CH: client_binding
     CH--)SH: followup request (client_binding)
 

oak_simple_io/README.md

@@ -12,7 +12,7 @@ address. The first port contains the most significant 4 bytes, and the second
 contains the least significant 4 bytes.
 
 The current implementation assumes an identity mapping for the memory so that
-guest-phsyical and guest-virtual addresses are the same.
+guest-physical and guest-virtual addresses are the same.
 
 The guest uses an additional pre-agreed 32-bit I/O port for each channel to
 represent the length of each message.
@@ -24,6 +24,6 @@ blocks until the hypervisor has copied the message out of the buffer.
 
 The guest reads from the length I/O port for the input channel. The hypervisor
 I/O handler implementation for this port writes a message to the input buffer
-(if one is availble) and returns the actual message length via the port. The
+(if one is available) and returns the actual message length via the port. The
 returned length must not exceed the length of the input buffer. If there aren't
 any messages, the hypervisor must return a length of 0.