netdev - Re: [PATCH v3 0/5] netlink extended ACK reporting

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, 10 Apr 2017 13:20:42 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Cc:     pablo@...filter.org, Jamal Hadi Salim <jhs@...atatu.com>,
        Jiri Benc <jbenc@...hat.com>,
        David Ahern <dsa@...ulusnetworks.com>, jiri@...nulli.us,
        David Miller <davem@...emloft.net>
Subject: Re: [PATCH v3 0/5] netlink extended ACK reporting

I thought a little bit more about the part of reporting the broken and
missing attributes, and I'm not sure I'm entirely happy with that part.

For reporting broken attributes, I think the pointer is really the best
thing we can do - adding the attribute number in addition to that would
seem to be easy to misuse in userspace, and there's no information
about nesting at that point and the "malformed attribute" ID will not
make any sense without knowing the nesting level. So I think we
shouldn't add the attribute ID there. The userspace app can disentangle
the nesting, or it can know that it never used nesting, for example.

Similarly, the "missing attribute" ID - which I did add an attribute
for but didn't use it yet - can result in similar interpretation
problems. I'm not really sure what to do with this one - technically
one could report back the entire nesting chain, but having that kind of
state might be really difficult.

Did anyone already have any plans for the "missing attribute"
functionality?

And another thought regarding the strict checking: we might also want
to extend that to strictly check the *size* of attributes as well. For
example, right now, if the kernel wants a u8 attribute but userspace
uses a u16 or u32, this will work on little-endian and be accepted but
wrongly be 0 on big endian.

johannes