linux-kernel - Re: [PATCH net-next v2 1/4] vm_sockets: Include flags field in the vsock address data structure

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]

Message-ID: <20201207132908.130a5f24@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com>
Date:   Mon, 7 Dec 2020 13:29:08 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Andra Paraschiv <andraprs@...zon.com>
Cc:     netdev <netdev@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "David S . Miller" <davem@...emloft.net>,
        David Duncan <davdunc@...zon.com>,
        Dexuan Cui <decui@...rosoft.com>,
        Alexander Graf <graf@...zon.de>,
        Jorgen Hansen <jhansen@...are.com>,
        Stefano Garzarella <sgarzare@...hat.com>,
        Stefan Hajnoczi <stefanha@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>
Subject: Re: [PATCH net-next v2 1/4] vm_sockets: Include flags field in the
 vsock address data structure

On Fri, 4 Dec 2020 19:02:32 +0200 Andra Paraschiv wrote:
> diff --git a/include/uapi/linux/vm_sockets.h b/include/uapi/linux/vm_sockets.h
> index fd0ed7221645d..46735376a57a8 100644
> --- a/include/uapi/linux/vm_sockets.h
> +++ b/include/uapi/linux/vm_sockets.h
> @@ -145,7 +145,7 @@
>  
>  struct sockaddr_vm {
>  	__kernel_sa_family_t svm_family;
> -	unsigned short svm_reserved1;
> +	unsigned short svm_flags;
>  	unsigned int svm_port;
>  	unsigned int svm_cid;
>  	unsigned char svm_zero[sizeof(struct sockaddr) -

Since this is a uAPI header I gotta ask - are you 100% sure that it's
okay to rename this field?

I didn't grasp from just reading the patches whether this is a uAPI or
just internal kernel flag, seems like the former from the reading of
the comment in patch 2. In which case what guarantees that existing
users don't pass in garbage since the kernel doesn't check it was 0?