From: Dmitry Vyukov <dvyukov@google.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: David Miller <davem@davemloft.net>,
Willem de Bruijn <willemb@google.com>,
Eric Dumazet <edumazet@google.com>,
netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
kasan-dev <kasan-dev@googlegroups.com>,
Cong Wang <xiyou.wangcong@gmail.com>,
andreyknvl <andreyknvl@google.com>
Subject: Re: KASAN poisoning for skb linear data
Date: Thu, 8 Mar 2018 16:59:39 +0100 [thread overview]
Message-ID: <CACT4Y+aDK5y0EoundSdKmWLT3uzG=kLj4cbdQsgsCAzsw-EzTw@mail.gmail.com> (raw)
In-Reply-To: <20180308074543.250898af@xeon-e3>
On Thu, Mar 8, 2018 at 4:45 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Mon, 15 Jan 2018 15:15:04 +0100
> Dmitry Vyukov <dvyukov@google.com> wrote:
>
>> Hi,
>>
>> As far as I understand pskb_may_pull() plays important role in packet
>> parsing for all protocols. And we did custom fragmentation of packets
>> emitted via tun (IFF_NAPI_FRAGS). However, it seems that it does not
>> give any results (bugs found), and I think the reason for this is that
>> linear data is rounded up and is usually quite large. So if a parsing
>> function does pskb_may_pull(1), or does not do it at all, it can
>> usually access more and it will go unnoticed. KASAN has an ability to
>> do custom poisoning: it can poison/unpoison any memory range, and then
>> detect any reads/writes to that range. What do you think about adding
>> custom KASAN poisoning to pskb_may_pull() and switching it to
>> non-eager mode (pull only what was requested) under KASAN? Do you
>> think it has potential for finding important bugs? What amount of work
>> is this?
>>
>> Thanks
>
> Also, kernel networking only deals with in-tree upstream code.
> Any problems with infrastructure for custom code are your problem
> to deal with, not our problem.
This is 100% about upstream code. The issue for me, it is not in
networking component.
I've filed an issue because kernel mailing lists are used mostly for
patches, everything else is immediately lost (e.g. like this one).
prev parent reply other threads:[~2018-03-08 16:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-15 14:15 KASAN poisoning for skb linear data Dmitry Vyukov
2018-03-08 9:20 ` Dmitry Vyukov
2018-03-08 15:43 ` Stephen Hemminger
2018-11-17 0:52 ` Dmitry Vyukov
2018-03-08 15:45 ` Stephen Hemminger
2018-03-08 15:59 ` Dmitry Vyukov [this message]
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='CACT4Y+aDK5y0EoundSdKmWLT3uzG=kLj4cbdQsgsCAzsw-EzTw@mail.gmail.com' \
--to=dvyukov@google.com \
--cc=andreyknvl@google.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
--cc=willemb@google.com \
--cc=xiyou.wangcong@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 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.