From: Bruno Piazera Larsen <bruno.larsen@eldorado.org.br>
To: Fabiano Rosas <farosas@linux.ibm.com>, qemu-devel@nongnu.org
Cc: richard.henderson@linaro.org, luis.pires@eldorado.org.br,
Greg Kurz <groug@kaod.org>,
lucas.araujo@eldorado.org.br, fernando.valle@eldorado.org.br,
qemu-ppc@nongnu.org, matheus.ferst@eldorado.org.br,
david@gibson.dropbear.id.au
Subject: Re: [RFC PATCH v2 2/2] target/ppc: make gdb able to translate priviledged addresses
Date: Tue, 15 Jun 2021 08:59:29 -0300 [thread overview]
Message-ID: <48dc679b-796c-68fc-b0fd-a73173dbc3cc@eldorado.org.br> (raw)
In-Reply-To: <87o8c8uoio.fsf@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 4087 bytes --]
On 14/06/2021 18:25, Fabiano Rosas wrote:
> "Bruno Larsen (billionai)" <bruno.larsen@eldorado.org.br> writes:
>
>> This patch changes ppc_cpu_get_phys_page_debug so that it is now
>> able to translate both, priviledged and real mode addresses
>> independently of whether the CPU executing it has those permissions
>>
>> This was mentioned by Fabiano as something that would be very useful to
>> help with debugging, but could possibly constitute a security issue if
>> that debug function can be called in some way by prodution code.
> Thinking a bit more about this, I think we just need to make sure that
> this is not called during the regular operation of the virtual
> machine. So not as much a security issue, more of a correctness one.
yeah, but it's an issue of correctness that can lead to a security
issue, so I think it's worth documenting at the very least
>
>> the
>> solution was implemented such that it would be trivial to wrap it around
>> ifdefs for building only with --enable-debug, for instance, but we are
>> not sure this is the best approach, hence why it is an RFC.
>>
>> Suggested-by: Fabiano Rosas <farosas@linux.ibm.com>
>> Signed-off-by: Bruno Larsen (billionai) <bruno.larsen@eldorado.org.br>
>> ---
>> target/ppc/mmu_helper.c | 23 +++++++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/target/ppc/mmu_helper.c b/target/ppc/mmu_helper.c
>> index 9dcdf88597..41c727c690 100644
>> --- a/target/ppc/mmu_helper.c
>> +++ b/target/ppc/mmu_helper.c
>> @@ -2947,6 +2947,29 @@ hwaddr ppc_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
>> cpu_mmu_index(&cpu->env, true), false)) {
>> return raddr & TARGET_PAGE_MASK;
>> }
>> +
>> + /*
>> + * This is a fallback, in case we're asking for priviledged memory to
>> + * be printed, but the PCU is not executing in a priviledged manner.
>> + *
>> + * The code could be considered a security vulnerability if
>> + * this function can be called in a scenario that does not involve
>> + * debugging.
>> + * Given the name and how useful using real addresses may be for
>> + * actually debugging, however, we decided to include it anyway and
>> + * discuss how to best avoid the possible security concerns.
>> + * The current plan is that, if there is a chance this code is called in
>> + * a production environment, we can surround it with ifdefs so that it
>> + * is only compiled with --enable-debug
>> + */
>> + /* attempt to translate first with virtual addresses */
>> + if (ppc_xlate(cpu, addr, MMU_DATA_LOAD, &raddr, &s, &p, 1, false) ||
>> + ppc_xlate(cpu, addr, MMU_INST_FETCH, &raddr, &s, &p, 1, false) ||
>> + /* if didn't work, attempt to translate with real addresses */
>> + ppc_xlate(cpu, addr, MMU_DATA_LOAD, &raddr, &s, &p, 3, false) ||
>> + ppc_xlate(cpu, addr, MMU_INST_FETCH, &raddr, &s, &p, 3, false)) {
>> + return raddr & TARGET_PAGE_MASK;
>> + }
> If this is only used during debug we could just give it the highest
> mmu_idx, no need for a fallback.
we actually don't want to set the HV bit, because gdb is using the
virtual hypervisor, so it'd trigger an assert that both HV and vhyp are
set.
>
> Now, it might be possible that people use GDB to debug some aspect of
> the MMU emulation, in which case it would be more useful to have the GDB
> access fail just as the CPU would. But from my perspective it would be
> better to have GDB access all of the guest memory without restriction.
Yeah, could also be a thing. I really don't know, though, because before
the mmu_idx was 0, so it wouldn't work even before this patch. Some more
discussion is appreciated for the people who implement MMUs :)
>
>> return -1;
>> }
--
Bruno Piazera Larsen
Instituto de Pesquisas ELDORADO
<https://www.eldorado.org.br/?utm_campaign=assinatura_de_e-mail&utm_medium=email&utm_source=RD+Station>
Departamento Computação Embarcada
Analista de Software Trainee
Aviso Legal - Disclaimer <https://www.eldorado.org.br/disclaimer.html>
[-- Attachment #2: Type: text/html, Size: 5518 bytes --]
next prev parent reply other threads:[~2021-06-15 12:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-14 19:16 [PATCH v2 1/2] target/ppc: fix address translation bug for radix mmus Bruno Larsen (billionai)
2021-06-14 19:16 ` [RFC PATCH v2 2/2] target/ppc: make gdb able to translate priviledged addresses Bruno Larsen (billionai)
2021-06-14 19:37 ` Philippe Mathieu-Daudé
2021-06-15 1:41 ` David Gibson
2021-06-15 12:12 ` Bruno Piazera Larsen
2021-06-14 21:25 ` Fabiano Rosas
2021-06-15 11:59 ` Bruno Piazera Larsen [this message]
2021-06-14 22:37 ` Richard Henderson
2021-06-15 11:32 ` Bruno Piazera Larsen
2021-06-15 20:00 ` Richard Henderson
2021-06-15 21:37 ` Fabiano Rosas
2021-06-16 12:07 ` Bruno Piazera Larsen
2021-06-16 6:18 ` David Gibson
2021-06-14 19:29 ` [PATCH v2 1/2] target/ppc: fix address translation bug for radix mmus Greg Kurz
2021-06-14 21:04 ` Fabiano Rosas
2021-06-15 1:18 ` David Gibson
2021-06-15 1:41 ` David Gibson
2021-06-15 3:20 ` Richard Henderson
2021-06-15 12:25 ` Bruno Piazera Larsen
2021-06-16 6:16 ` David Gibson
2021-06-15 13:57 ` Cédric Le Goater
2021-06-15 14:14 ` Philippe Mathieu-Daudé
2021-06-15 14:57 ` Bruno Piazera Larsen
2021-06-15 15:57 ` Cédric Le Goater
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48dc679b-796c-68fc-b0fd-a73173dbc3cc@eldorado.org.br \
--to=bruno.larsen@eldorado.org.br \
--cc=david@gibson.dropbear.id.au \
--cc=farosas@linux.ibm.com \
--cc=fernando.valle@eldorado.org.br \
--cc=groug@kaod.org \
--cc=lucas.araujo@eldorado.org.br \
--cc=luis.pires@eldorado.org.br \
--cc=matheus.ferst@eldorado.org.br \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.