linux-kernel - Re: [PATCH net-next] net: tipc: fix FB

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] [day] [month] [year] [list]

Message-ID: <20210609105350.GA64468@www>
Date:   Wed, 9 Jun 2021 03:53:50 -0700
From:   Menglong Dong <menglong8.dong@...il.com>
To:     Jon Maloy <jmaloy@...hat.com>
Cc:     ying.xue@...driver.com, David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        tipc-discussion@...ts.sourceforge.net,
        Menglong Dong <dong.menglong@....com.cn>,
        Zeal Robot <zealci@....com.cn>
Subject: Re: [PATCH net-next] net: tipc: fix FB_MTU eat two pages

On Wed, Jun 09, 2021 at 03:34:33AM -0400, Jon Maloy wrote:
> 
> 
[...]
> It seems like I have been misleading you. It turns out that these messages
> *will* be sent out over the nework in some cases, i.e. at
> multicast/broadcast over an UDP bearer.
> So, what we need is two macros, one with the conditional crypto
> head/tailroom defined as you first suggested, and one that only use the
> non-crypto head/tailroom as we have been discussing now.
> The first one can be defined inside bcast.c, the latter  inside msg.c.
> It might also be a good idea to give the macros more descriptive names, such
> as ONEPAGE_MTU in the broadcast version, and ONEPAGE_SKB in the node local
> version.
> 
> Does that make sense?

I think it's another point which can be optimized. However, with
CONFIG_TIPC_CRYPTO=y, the BUF_HEADROOM used in tipc_buf_acquire() is
always the crypto version, so it donen't work to define FB_MTU with
non-crypto BUF_HEADROOM.

So the point is to make a non-crypto version tipc_buf_acquire(), which
is used to alloc data for non-crypto message with non-crypto
BUF_HEADROOM. And that require us to distinguish the message that don't
crypto. Is there simple way to achieve this goal?

(Btw, I resended the patches for the 'two pages' problems.)

Thanks!
Menglong Dong

> 
> >