linux-hardening - Re: rcar-dmac.c: race condition regarding cookie handling?

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: Mon, 29 Jan 2024 20:08:28 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Kees Cook <keescook@...omium.org>
Cc: "Behme Dirk (CM/ESO2)" <dirk.behme@...bosch.com>, 
	Linux-Renesas <linux-renesas-soc@...r.kernel.org>, 
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>, linux-hardening@...r.kernel.org
Subject: Re: rcar-dmac.c: race condition regarding cookie handling?

Hi Kees,

On Mon, Jan 29, 2024 at 6:38 PM Kees Cook <keescook@...omium.org> wrote>
> On Mon, Jan 29, 2024 at 10:57:40AM +0100, Geert Uytterhoeven wrote:
> > CC Kees (for the wrap-around in dma_cookie_assign() not handled in [A])
> > [...]
> > Was the system running for a very long time?
> > dma_cookie_assign() relies on 2-complement signed wrap-around:
> >
> >         cookie = chan->cookie + 1;
> >         if (cookie < DMA_MIN_COOKIE)
> >                 cookie = DMA_MIN_COOKIE;
> >
> > but given the kernel is compiled with -fno-strict-overflow (which
> > implies -fwrapv) that should work.
>
> For my own reference:
>
> typedef s32 dma_cookie_t;
> #define DMA_MIN_COOKIE  1
>
> struct dma_chan {
>         ...
>         dma_cookie_t cookie;
>
> Correct, as you say, with -fno-strict-overflow this is well defined, and
> will wrap the value around negative if chan->cookie was S32_MAX.
>
> In the future, when the signed integer wrap-around sanitizer works
> again, we'll want to change the math to something like:
>
>         cookie = add_wrap(typeof(cookie), chan->cookie, 1);
>
> But that will be an ongoing conversion once folks have agreed on the
> semantics of the wrapping helpers, which is not settled yet.
>
> If you want to handle this today without depending on wrap-around,
> it's a little bit more involved to do it open coded, but it's possible:
>
>         if (chan->cookie == type_max(typeof(chan->cookie)))
>                 cookie = DMA_MIN_COOKIE;
>         else
>                 cookie = chan->cookie + 1;
>
> the "type_max(...)" part could also just be written as S32_MAX.

It's actually more complicated: this code is also used to make sure
any other values outside the valid range (e.g. initial zero are
converted to DMA_MIN_COOKIE.  So the above would not be correct
replacements for the current logic.

DMA cookies can also contain negative error values, hence the signed
type. However, I don't think that can be the case for the chan->cookie
counter, only for cookies stored in descriptors.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds