diff --git a/codelab/README.md b/codelab/README.md index 5b49f6c53aa..be5691177f3 100644 --- a/codelab/README.md +++ b/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 diff --git a/micro_rpc/README.md b/micro_rpc/README.md index 5ef6e297665..11b276fc7d2 100644 --- a/micro_rpc/README.md +++ b/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. diff --git a/oak_attestation/README.md b/oak_attestation/README.md index 5d689679f78..6e85d8fe06f 100644 --- a/oak_attestation/README.md +++ b/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). diff --git a/oak_containers/app_base/README.md b/oak_containers/app_base/README.md index 582e51befff..05f84dbb1e5 100644 --- a/oak_containers/app_base/README.md +++ b/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 diff --git a/oak_containers/examples/micro_rpc_noise/README.md b/oak_containers/examples/micro_rpc_noise/README.md index e0d525eafd3..336ac4e1247 100644 --- a/oak_containers/examples/micro_rpc_noise/README.md +++ b/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 diff --git a/oak_containers/system_image/README.md b/oak_containers/system_image/README.md index fa07c327670..fe75a6b0a2f 100644 --- a/oak_containers/system_image/README.md +++ b/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`. diff --git a/oak_functions_abi/README.md b/oak_functions_abi/README.md index 35c7a9b4119..657e93d88a8 100644 --- a/oak_functions_abi/README.md +++ b/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. diff --git a/oak_functions_standalone/testdata/README.md b/oak_functions_standalone/testdata/README.md index d72029688a4..3dda676b852 100644 --- a/oak_functions_standalone/testdata/README.md +++ b/oak_functions_standalone/testdata/README.md @@ -2,7 +2,7 @@ Keys are specified in the form of `"(,)"` 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. diff --git a/oak_linux_boot_params/README.md b/oak_linux_boot_params/README.md index 05ade5ada6e..e01b139d72b 100644 --- a/oak_linux_boot_params/README.md +++ b/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: diff --git a/oak_private_memory/proto/README.md b/oak_private_memory/proto/README.md index e4f099a6e62..a50d97dd467 100644 --- a/oak_private_memory/proto/README.md +++ b/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. diff --git a/oak_proto_rust/README.md b/oak_proto_rust/README.md index 57af4679123..74443cd3c26 100644 --- a/oak_proto_rust/README.md +++ b/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 diff --git a/oak_session/README.md b/oak_session/README.md index 667d1469bae..b3c3d2d764f 100644 --- a/oak_session/README.md +++ b/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) diff --git a/oak_simple_io/README.md b/oak_simple_io/README.md index 3bdf7918cc2..62002aee4cb 100644 --- a/oak_simple_io/README.md +++ b/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.