The full 66 bytes of the EDD 3.x buffer were already filled, but the size field wasn't updated so that we would return that only the first 30 bytes of it are valid (like for 2.x). Fix the size field.
Signed-off-by: Kevin Wolf kwolf@redhat.com --- src/block.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/src/block.c b/src/block.c index 7892be5..46afca0 100644 --- a/src/block.c +++ b/src/block.c @@ -339,6 +339,7 @@ fill_generic_edd(u16 seg, struct int13dpt_s *param_far, struct drive_s *drive_gf return DISK_RET_SUCCESS;
// EDD 3.x + SET_FARVAR(seg, param_far->size, 66); SET_FARVAR(seg, param_far->key, 0xbedd); SET_FARVAR(seg, param_far->dpi_length, t13 ? 44 : 36); SET_FARVAR(seg, param_far->reserved1, 0);
On Thu, Nov 06, 2014 at 10:41:35PM +0100, Kevin Wolf wrote:
The full 66 bytes of the EDD 3.x buffer were already filled, but the size field wasn't updated so that we would return that only the first 30 bytes of it are valid (like for 2.x). Fix the size field.
SeaBIOS has never set the size above 30, and looking at the EDD3 spec I think the current behavior is correct:
The caller sets this value to the maximum buffer size. If the length of this buffer is less than 30 bytes, this function does not return the pointer to DPT extension. If the buffer size is 30 or greater on entry, it shall be set to 30 on exit. If the buffer size is between 26 and 29, it shall be set to 26 on exit. If the buffer size is less than 26 on entry an error is returned.
-Kevin
Am 07.11.2014 um 01:19 hat Kevin O'Connor geschrieben:
On Thu, Nov 06, 2014 at 10:41:35PM +0100, Kevin Wolf wrote:
The full 66 bytes of the EDD 3.x buffer were already filled, but the size field wasn't updated so that we would return that only the first 30 bytes of it are valid (like for 2.x). Fix the size field.
SeaBIOS has never set the size above 30, and looking at the EDD3 spec I think the current behavior is correct:
The caller sets this value to the maximum buffer size. If the length of this buffer is less than 30 bytes, this function does not return the pointer to DPT extension. If the buffer size is 30 or greater on entry, it shall be set to 30 on exit. If the buffer size is between 26 and 29, it shall be set to 26 on exit. If the buffer size is less than 26 on entry an error is returned.
Indeed, I should have checked more closely when the "bug" was reported to me. It just looked plausible enough that when there's a size field at offset 0, it should always have a meaning... Sorry for the noise.
So then the only correct way for a caller to determine whether the 3.x fields are present is clearing the word for param_far->key before the call and checking it afterwards?
Kevin
On Fri, Nov 07, 2014 at 09:16:46AM +0100, Kevin Wolf wrote:
Am 07.11.2014 um 01:19 hat Kevin O'Connor geschrieben:
On Thu, Nov 06, 2014 at 10:41:35PM +0100, Kevin Wolf wrote:
The full 66 bytes of the EDD 3.x buffer were already filled, but the size field wasn't updated so that we would return that only the first 30 bytes of it are valid (like for 2.x). Fix the size field.
SeaBIOS has never set the size above 30, and looking at the EDD3 spec I think the current behavior is correct:
The caller sets this value to the maximum buffer size. If the length of this buffer is less than 30 bytes, this function does not return the pointer to DPT extension. If the buffer size is 30 or greater on entry, it shall be set to 30 on exit. If the buffer size is between 26 and 29, it shall be set to 26 on exit. If the buffer size is less than 26 on entry an error is returned.
Indeed, I should have checked more closely when the "bug" was reported to me. It just looked plausible enough that when there's a size field at offset 0, it should always have a meaning... Sorry for the noise.
So then the only correct way for a caller to determine whether the 3.x fields are present is clearing the word for param_far->key before the call and checking it afterwards?
That's what I would do. (Along with checking dpi_length and the second checksum.)
-Kevin
-
Kevin O'Connor -
Kevin Wolf