qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Julia Suvorova <jusual@mail.ru>
To: Stefan Hajnoczi <stefanha@gmail.com>,
	sundeep subbaraya <sundeep.lkml@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Jim Mussared" <jim@groklearning.com>,
	"Steffen Görtz" <mail@steffen-goertz.de>,
	"Joel Stanley" <joel@jms.id.au>
Subject: Re: [Qemu-devel] [RFC 2/3] hw/char/nrf51_uart: Implement nRF51 SoC UART
Date: Fri, 1 Jun 2018 18:36:37 +0300	[thread overview]
Message-ID: <e74133a7-d5d3-f683-cf4b-f1478eaf6cc9@mail.ru> (raw)
In-Reply-To: <CAJSP0QV_wOv1bV-yB49T7YJA_kjRJb25NkTbt+y2uwzgk_ayGg@mail.gmail.com>

On 01.06.2018 13:44, Stefan Hajnoczi wrote:
> On Fri, Jun 1, 2018 at 11:41 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>> On Thu, May 31, 2018 at 2:58 PM, sundeep subbaraya
>> <sundeep.lkml@gmail.com> wrote:
>>> On Wed, May 30, 2018 at 3:33 AM, Julia Suvorova via Qemu-devel
>>> <qemu-devel@nongnu.org> wrote:
>>>> +static uint64_t uart_read(void *opaque, hwaddr addr, unsigned int size)
>>>> +{
>>>> +    Nrf51UART *s = NRF51_UART(opaque);
>>>> +    uint64_t r;
>>>> +
>>>> +    switch (addr) {
>>>> +    case A_RXD:
>>>> +        r = s->rx_fifo[s->rx_fifo_pos];
>>>> +        if (s->rx_fifo_len > 0) {
>>>> +            s->rx_fifo_pos = (s->rx_fifo_pos + 1) % UART_FIFO_LENGTH;
>>>> +            s->rx_fifo_len--;
>>>> +            qemu_chr_fe_accept_input(&s->chr);
>>>> +        }
>>>> +        break;
>>>> +
>>>> +    case A_INTENSET:
>>>> +    case A_INTENCLR:
>>>> +    case A_INTEN:
>>>> +        r = s->reg[A_INTEN];
>>>> +        break;
>>>> +    default:
>>>> +        r = s->reg[addr];
>>>
>>> You can use R_* macros for registers and access regs[ ] with addr/4 as index.
>>> It is better than using big regs[ ] array out of which most of
>>> locations go unused.
>>
>> Good point.  The bug is more severe than an inefficiency.
>> s->reg[addr] allows out-of-bounds accesses.  This is a security bug.
>>
>> The memory region is 0x1000 *bytes* long, but the array has 0x1000
>> 32-bit *elements*.  A read from address 0xfffc results in a memory
>> load from s->reg + 0xfffc * sizeof(s->reg[0]).  That's beyond the end
>> of the array!
> 
> Sorry, I was wrong.  The array is large enough after all.  It's just
> an inefficiency, but still worth fixing.  Similar issues could lead to
> out-of-bound accesses.

Even if I change the reg array to work with the R_* macros, it will
still be inefficient, since registers are not sequentially located.
I can define the registers in the Nrf51UART structure separately, but
this will increase the code size. Is there a proper way?

Best regards, Julia Suvorova.

  reply	other threads:[~2018-06-01 15:36 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-29 22:03 [Qemu-devel] [RFC 0/3] nRF51 SoC: Add UART support Julia Suvorova
2018-05-29 22:03 ` [Qemu-devel] [RFC 1/3] hw/arm/nrf51_soc: Fix compilation and memory regions Julia Suvorova
2018-05-31 10:30   ` Peter Maydell
2018-05-29 22:03 ` [Qemu-devel] [RFC 2/3] hw/char/nrf51_uart: Implement nRF51 SoC UART Julia Suvorova
2018-05-31  9:42   ` Stefan Hajnoczi
2018-06-01 15:21     ` Julia Suvorova
2018-06-01 15:58       ` Peter Maydell
2018-06-02  8:15         ` Stefan Hajnoczi
2018-05-31 12:28   ` Peter Maydell
2018-05-31 13:58   ` sundeep subbaraya
2018-06-01 10:41     ` Stefan Hajnoczi
2018-06-01 10:44       ` Stefan Hajnoczi
2018-06-01 15:36         ` Julia Suvorova [this message]
2018-05-29 22:03 ` [Qemu-devel] [RFC 3/3] tests/boot-serial-test: Add support for the microbit board Julia Suvorova
2018-05-31  9:43   ` Stefan Hajnoczi
2018-05-30  2:57 ` [Qemu-devel] [RFC 0/3] nRF51 SoC: Add UART support Philippe Mathieu-Daudé
2018-05-31  9:44   ` Stefan Hajnoczi

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=e74133a7-d5d3-f683-cf4b-f1478eaf6cc9@mail.ru \
    --to=jusual@mail.ru \
    --cc=jim@groklearning.com \
    --cc=joel@jms.id.au \
    --cc=mail@steffen-goertz.de \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=sundeep.lkml@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).