author | Eric Anholt <eric@anholt.net> | |
Wed, 4 Jan 2012 20:31:40 +0000 (12:31 -0800) | ||
committer | Eric Anholt <eric@anholt.net> | |
Fri, 27 Jan 2012 21:21:19 +0000 (13:21 -0800) | ||
commit | 028715ee7074691895051296105e8b4cbbfaabb8 | |
tree | 8400a293600aabf1feb16203a13cf600e42cf9b4 | tree | snapshot (tar.xz tar.gz zip) |
parent | c1d2946da8f13ea8cbda1e33aeccee4d06015fea | commit | diff |
intel: Avoid the need for most overflow checks by using a scratch page.
The overflow checks were all thoroughly untested, and a bunch of the
ones I'm deleting were pretty broken. Now, in the case of overflow,
you just decode data of 0xd0d0d0d0, and instr_out prints the warning
message instead. Note that this still has the same issue of being
under-tested, but at least it's one place instead of per-packet.
A couple of BUFFER_FAIL uses are left where the length to be decoded
could be (significantly) larger than a page, and the decode didn't
just call instr_out (which doesn't dereference data itself unless it's
safe).
The overflow checks were all thoroughly untested, and a bunch of the
ones I'm deleting were pretty broken. Now, in the case of overflow,
you just decode data of 0xd0d0d0d0, and instr_out prints the warning
message instead. Note that this still has the same issue of being
under-tested, but at least it's one place instead of per-packet.
A couple of BUFFER_FAIL uses are left where the length to be decoded
could be (significantly) larger than a page, and the decode didn't
just call instr_out (which doesn't dereference data itself unless it's
safe).
intel/intel_decode.c | diff | blob | history |