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, 12 Sep 2018 11:15:55 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     johannes@...solutions.net
Cc:     linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        mkubecek@...e.cz, johannes.berg@...el.com
Subject: Re: [RFC v2 1/2] netlink: add NLA_REJECT policy type

From: Johannes Berg <johannes@...solutions.net>
Date: Wed, 12 Sep 2018 10:36:09 +0200

> From: Johannes Berg <johannes.berg@...el.com>
> 
> In some situations some netlink attributes may be used for output
> only (kernel->userspace) or may be reserved for future use. It's
> then helpful to be able to prevent userspace from using them in
> messages sent to the kernel, since they'd otherwise be ignored and
> any future will become impossible if this happens.
> 
> Add NLA_REJECT to the policy which does nothing but reject (with
> EINVAL) validation of any messages containing this attribute.
> Allow for returning a specific extended ACK error message in the
> validation_data pointer.
> 
> While at it fix the indentation of NLA_BITFIELD32 and describe the
> validation_data pointer for it.
> 
> The specific case I have in mind now is a shared nested attribute
> containing request/response data, and it would be pointless and
> potentially confusing to have userspace include response data in
> the messages that actually contain a request.
> 
> Signed-off-by: Johannes Berg <johannes.berg@...el.com>

This looks great, no objections to this idea or the facility.

It does, however, remind me about about the classic problem of how bad
we are at feature support detection because unrecognized attributes are
ignored.

I do really hope we can fully solve that problem some day.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ