loaded_image: make load options API safer #375
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The spec describes
LoadOptions
as "A pointer to the image’s binaryload options. See the OptionalData parameter in [section 3.1.3 Load
Options] of the Boot Manager chapter for information on the source of
the LoadOptions data." The
OptionalData
field is described as "Theremaining bytes in the load option descriptor are a binary data buffer
that is passed to the loaded image."
So there's no guarantee made about the contents of
LoadOptions
; it'sarbitrary binary data as far as the UEFI spec is concerned. So it's not
necessarily safe to treat the load_options as a
Char16
pointer, sinceit might not be aligned and might not be null-terminated. That said, the
data is usually a null-terminated UCS-2 string. The UEFI Shell spec
specifies that command-line parameters are passed that way.
To safely support both cases, change the
load_options
field to au8
pointer, drop the
load_options
method that converts the data to a&str
, and add two new methods:load_options_as_bytes
andload_options_as_cstr16
. Theset_load_options
has also been changedto take a
u8
pointer instead of aChar16
pointer.#73