lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 28 Jul 2021 09:25:16 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Xianting Tian <xianting.tian@...ux.alibaba.com>
Cc:     Arnd Bergmann <arnd@...db.de>, Amit Shah <amit@...nel.org>,
        gregkh <gregkh@...uxfoundation.org>,
        Omar Sandoval <osandov@...com>,
        "open list:DRM DRIVER FOR QEMU'S CIRRUS DEVICE" 
        <virtualization@...ts.linux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] virtio-console: avoid DMA from vmalloc area

On Wed, Jul 28, 2021 at 4:59 AM Xianting Tian
<xianting.tian@...ux.alibaba.com> wrote:
>
> Arnd, thanks for your quick reply,
>
> As we know put_chars() of virtio-console is registered to hvc framework.
> I go throughed the code, actually there are totally three places that
> put_chars() is called in hvc driver,  but only 1 has issue which is
> fixed by commit c4baad5029.

Ah, good. Knowing what the callers are definitely helps. ;-)

> So I think the scenario that the buf is from "ioremap(), kmap_atomic() ,
> fixmap, loadable module" doesn't exist for virtio-console.
> If there is something wrong about above description, please correct me,
> thanks.

The description is good then.

> Three places that put_chars() is called in hvc driver:
> 1, it is on stack buf,  it is not ok for dma
>      hvc_console_print():
>          char c[N_OUTBUF] __ALIGNED__;
>          cons_ops[index]->put_chars(vtermnos[index], c, i);
>
> 2, just one byte, no issue for dma
>      static void hvc_poll_put_char(struct tty_driver *driver, int line,
> char ch)
>      {
>          struct tty_struct *tty = driver->ttys[0];
>          struct hvc_struct *hp = tty->driver_data;
>          int n;
>
>          do {
>              n = hp->ops->put_chars(hp->vtermno, &ch, 1);
>          } while (n <= 0);
>      }

This is actually the same as the first, taking the address of a
function argument forces it onto the stack.

> 3,  hp->outbuf is allocated in hvc_alloc() via kzalloc(), no issue for dma
>      static int hvc_push(struct hvc_struct *hp)
>      {
>          int n;
>
>          n = hp->ops->put_chars(hp->vtermno, hp->outbuf, hp->n_outbuf);
>          …
>      }

ok.

I have a new question then: are there any other hvc backends that do
DMA, or is the virtio-console driver the only one? If there are any others,
I think this should better be fixed in the hvc framework, by changing it
to never pass stack data into the put_chars() function in the first place.

It may be possible to just use the 'hp->n_outbuf' buffer in all three cases.

       Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ