mirror of
https://github.com/Qyriad/fusee-launcher.git
synced 2024-11-11 00:05:06 +01:00
Remove trailing whitespace
This commit is contained in:
parent
afe5aa04ac
commit
21a30bbf41
@ -434,7 +434,7 @@ print("Found a Tegra with Device ID: {}".format(device_id))
|
||||
# Prefix the image with an RCM command, so it winds up loaded into memory
|
||||
# at the right location (0x40010000).
|
||||
|
||||
# Use the maximum length accepted by RCM, so we can transmit as much payload as
|
||||
# Use the maximum length accepted by RCM, so we can transmit as much payload as
|
||||
# we want; we'll take over before we get to the end.
|
||||
length = 0x30298
|
||||
payload = length.to_bytes(4, byteorder='little')
|
||||
|
@ -139,7 +139,7 @@ while (1) {
|
||||
|
||||
// Handle the received and validated command.
|
||||
// For a "load miniloader" command, this sanity checks the (validated)
|
||||
// miniloader image and takes steps to prevent re-use of signed data not
|
||||
// miniloader image and takes steps to prevent re-use of signed data not
|
||||
// intended to be used as an RCM command.
|
||||
rcm_handle_command_complete(...);
|
||||
}
|
||||
@ -199,7 +199,7 @@ while (total_rxd < total_to_rx) {
|
||||
}
|
||||
}
|
||||
|
||||
/* copy any data _past_ the command into a separate payload
|
||||
/* copy any data _past_ the command into a separate payload
|
||||
buffer at 0x40010000 */
|
||||
/* -code omitted for brevity - */
|
||||
|
||||
@ -244,7 +244,7 @@ data that should be included in the response. Per the specification, the device
|
||||
should respond with either the *amount of data specified* or the *amount of data
|
||||
available*, whichever is less.
|
||||
|
||||
The bootloader's implementation of this behavior is conceptually implemented as
|
||||
The bootloader's implementation of this behavior is conceptually implemented as
|
||||
follows:
|
||||
|
||||
```C
|
||||
@ -298,7 +298,7 @@ respond_to_control_request(dma_buffer, length_to_send);
|
||||
|
||||
In most cases, the handler correctly limits the length of the transmitted
|
||||
responses to the amount it has available, per the USB specification. However,
|
||||
in a few notable cases, the length is *incorrectly always set to the amount
|
||||
in a few notable cases, the length is *incorrectly always set to the amount
|
||||
requested* by the host:
|
||||
* When issuing a `GET_CONFIGURATION` request with a `DEVICE` recipient.
|
||||
* When issuing a `GET_INTERFACE` request with a `INTERFACE` recipient.
|
||||
@ -408,7 +408,7 @@ careful sequence of interactions:
|
||||
6. If the next write would target the lower DMA buffer, issue another write
|
||||
of a full 0x1000 bytes to move the target to the upper DMA buffer, reducing
|
||||
the total amount of data to be copied.
|
||||
7. Trigger the vulnerable memcpy by sending a `GET_STATUS` `IN` control
|
||||
7. Trigger the vulnerable memcpy by sending a `GET_STATUS` `IN` control
|
||||
request with an `ENDPOINT` recipient, and a length long enough to smash the
|
||||
desired stack region, and preferably not longer than required.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user