[Qemu-commits] [qemu/qemu] b449ca: target-arm: crypto: fix BE host support

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: b449ca3c1874418d948878d5417a32fc0dbf9fea
      
https://github.com/qemu/qemu/commit/b449ca3c1874418d948878d5417a32fc0dbf9fea
  Author: Ard Biesheuvel <address@hidden>
  Date:   2015-01-16 (Fri, 16 Jan 2015)

  Changed paths:
    M target-arm/crypto_helper.c

  Log Message:
  -----------
  target-arm: crypto: fix BE host support

The crypto emulation code in target-arm/crypto_helper.c never worked
correctly on big endian hosts, due to the fact that it uses a union
of array types to convert between the native VFP register size (64
bits) and the types used in the algorithms (bytes and 32 bit words)

We cannot just swab between LE and BE when reading and writing the
registers, as the SHA code performs word additions, so instead, add
array accessors for the CRYPTO_STATE type whose LE and BE specific
implementations ensure that the correct array elements are referenced.

Signed-off-by: Ard Biesheuvel <address@hidden>
Acked-by: Laszlo Ersek <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 36b62ae6a58f9a588fd33be9386e18a2b90103f5
      
https://github.com/qemu/qemu/commit/36b62ae6a58f9a588fd33be9386e18a2b90103f5
  Author: Laszlo Ersek <address@hidden>
  Date:   2015-01-16 (Fri, 16 Jan 2015)

  Changed paths:
    M hw/nvram/fw_cfg.c

  Log Message:
  -----------
  fw_cfg: fix endianness in fw_cfg_data_mem_read() / _write()

(1) Let's contemplate what device endianness means, for a memory mapped
device register (independently of QEMU -- that is, on physical hardware).

It determines the byte order that the device will put on the data bus when
the device is producing a *numerical value* for the CPU. This byte order
may differ from the CPU's own byte order, therefore when software wants to
consume the *numerical value*, it may have to swap the byte order first.

For example, suppose we have a device that exposes in a 2-byte register
the number of sheep we have to count before falling asleep. If the value
is decimal 37 (0x0025), then a big endian register will produce [0x00,
0x25], while a little endian register will produce [0x25, 0x00].

If the device register is big endian, but the CPU is little endian, the
numerical value will read as 0x2500 (decimal 9472), which software has to
byte swap before use.

However... if we ask the device about who stole our herd of sheep, and it
answers "XY", then the byte representation coming out of the register must
be [0x58, 0x59], regardless of the device register's endianness for
numeric values. And, software needs to copy these bytes into a string
field regardless of the CPU's own endianness.

(2) QEMU's device register accessor functions work with *numerical values*
exclusively, not strings:

The emulated register's read accessor function returns the numerical value
(eg. 37 decimal, 0x0025) as a *host-encoded* uint64_t. QEMU translates
this value for the guest to the endianness of the emulated device register
(which is recorded in MemoryRegionOps.endianness). Then guest code must
translate the numerical value from device register to guest CPU
endianness, before including it in any computation (see (1)).

(3) However, the data register of the fw_cfg device shall transfer strings
*only* -- that is, opaque blobs. Interpretation of any given blob is
subject to further agreement -- it can be an integer in an independently
determined byte order, or a genuine string, or an array of structs of
integers (in some byte order) and fixed size strings, and so on.

Because register emulation in QEMU is integer-preserving, not
string-preserving (see (2)), we have to jump through a few hoops.

(3a) We defined the memory mapped fw_cfg data register as
DEVICE_BIG_ENDIAN.

The particular choice is not really relevant -- we picked BE only for
consistency with the control register, which *does* transfer integers --
but our choice affects how we must host-encode values from fw_cfg strings.

(3b) Since we want the fw_cfg string "XY" to appear as the [0x58, 0x59]
array on the data register, *and* we picked DEVICE_BIG_ENDIAN, we must
compose the host (== C language) value 0x5859 in the read accessor
function.

(3c) When the guest performs the read access, the immediate uint16_t value
will be 0x5958 (in LE guests) and 0x5859 (in BE guests). However, the
uint16_t value does not matter. The only thing that matters is the byte
pattern [0x58, 0x59], which the guest code must copy into the target
string *without* any byte-swapping.

(4) Now I get to explain where I screwed up. :(

When we decided for big endian *integer* representation in the MMIO data
register -- see (3a) --, I mindlessly added an indiscriminate
byte-swizzling step to the (little endian) guest firmware.

This was a grave error -- it violates (3c) --, but I didn't realize it. I
only saw that the code I otherwise intended for fw_cfg_data_mem_read():

    value = 0;
    for (i = 0; i < size; ++i) {
  value = (value << 8) | fw_cfg_read(s);
    }

didn't produce the expected result in the guest.

In true facepalm style, instead of blaming my guest code (which violated
(3c)), I blamed my host code (which was correct). Ultimately, I coded
ldX_he_p() into fw_cfg_data_mem_read(), because that happened to work.

Obviously (...in retrospect) that was wrong. Only because my host happened
to be LE, ldX_he_p() composed the (otherwise incorrect) host value 0x5958
from the fw_cfg string "XY". And that happened to compensate for the bogus
indiscriminate byte-swizzling in my guest code.

Clearly the current code leaks the host endianness through to the guest,
which is wrong. Any device should work the same regardless of host
endianness.

The solution is to compose the host-endian representation (2) of the big
endian interpretation (3a, 3b) of the fw_cfg string, and to drop the wrong
byte-swizzling in the guest (3c).

Brown paper bag time for me.

Signed-off-by: Laszlo Ersek <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 1e42c353469cb58ca4f3b450eea4211af7d0b147
      
https://github.com/qemu/qemu/commit/1e42c353469cb58ca4f3b450eea4211af7d0b147
  Author: Peter Maydell <address@hidden>
  Date:   2015-01-16 (Fri, 16 Jan 2015)

  Changed paths:
    M hw/nvram/fw_cfg.c
    M target-arm/crypto_helper.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20150116' 
into staging

target-arm queue:
 * fix endianness handling in fwcfg wide registers
 * fix broken crypto insn emulation on big endian hosts

# gpg: Signature made Fri 16 Jan 2015 12:04:08 GMT using RSA key ID 14360CDE
# gpg: Good signature from "Peter Maydell <address@hidden>"

* remotes/pmaydell/tags/pull-target-arm-20150116:
  fw_cfg: fix endianness in fw_cfg_data_mem_read() / _write()
  target-arm: crypto: fix BE host support

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/e68cba36360a...1e42c353469c