qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [BUG??] ARM CP accesses rely on guest matching host data ty


From: Peter Crosthwaite
Subject: [Qemu-devel] [BUG??] ARM CP accesses rely on guest matching host data types
Date: Thu, 19 Dec 2013 15:17:49 +1000

Hi Peter,

I've been reviewing the ARM CP TCG handing code trying to get my head
around it, and I found this a little suspicious (translate.c):

6476 static int disas_coproc_insn(CPUARMState * env, DisasContext *s,
uint32_t insn)
6477 {
...
6502     is64 = (insn & (1 << 25)) == 0;
...
6552             if (is64) {
6553                 TCGv_i64 tmp64;
6554                 TCGv_i32 tmp;
6555                 if (ri->type & ARM_CP_CONST) {
...
6557                 } else if (ri->readfn) {
...
6564                 } else {
6565                     tmp64 = tcg_temp_new_i64();
6566                     tcg_gen_ld_i64(tmp64, cpu_env, ri->fieldoffset);
6567                 }
...
6577                 TCGv_i32 tmp;
6578                 if (ri->type & ARM_CP_CONST) {
...
6580                 } else if (ri->readfn) {
...
6587                 } else {
6588                     tmp = load_cpu_offset(ri->fieldoffset);
6589                 }

Depending on "is64" you will either get a tcg_gen_ld_i64 or gen_ld_i32
(via load_cpu_offset()) of fieldoffset. The values pointed to by
->fieldoffset are however a heterogenous collection of uint32_t and
uint64_t, which is not checked by this code. This means the guest
could do a 64bit read of a 32bit reg and we would leak nearby info
from the CPU env to the guest.

Should we be explicitly defining CPs as 32/64 in ri->type and
enforcing the correct tcg_gen_ldXX here accordingly?

Regards,
Peter



reply via email to

[Prev in Thread] Current Thread [Next in Thread]