linux-kernel - Re: [PATCH v2] proc: add byteorder file

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: <Y2EfK2CnHLq5HF9B@kroah.com>
Date:   Tue, 1 Nov 2022 14:29:15 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Thomas Weißschuh <linux@...ssschuh.net>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Karel Zak <kzak@...hat.com>,
        Masatake YAMATO <yamato@...hat.com>, linux-api@...r.kernel.org
Subject: Re: [PATCH v2] proc: add byteorder file

On Tue, Nov 01, 2022 at 02:04:01PM +0100, Thomas Weißschuh wrote:
> Certain files in procfs are formatted in byteorder dependent ways. For
> example the IP addresses in /proc/net/udp.
> 
> Assuming the byteorder of the userspace program is not guaranteed to be
> correct in the face of emulation as for example with qemu-user.
> 
> Also this makes it easier for non-compiled applications like
> shellscripts to discover the byteorder.

Your subject says "proc" :(

Also you do not list the new file name here in the changelog text, why
not?

> 
> Signed-off-by: Thomas Weißschuh <linux@...ssschuh.net>
> 
> ---
> 
> Development of userspace part: https://github.com/util-linux/util-linux/pull/1872
> 
> v1: https://lore.kernel.org/lkml/20221101005043.1791-1-linux@weissschuh.net/
> v1->v2:
>   * Move file to /sys/kernel/byteorder
> ---
>  .../ABI/testing/sysfs-kernel-byteorder         | 12 ++++++++++++
>  kernel/ksysfs.c                                | 18 ++++++++++++++++++
>  2 files changed, 30 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-kernel-byteorder
> 
> diff --git a/Documentation/ABI/testing/sysfs-kernel-byteorder b/Documentation/ABI/testing/sysfs-kernel-byteorder
> new file mode 100644
> index 000000000000..4c45016d78ae
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-kernel-byteorder
> @@ -0,0 +1,12 @@
> +What:		/sys/kernel/byteorder
> +Date:		February 2023
> +KernelVersion:	6.2
> +Contact:	linux-fsdevel@...r.kernel.org

Why is this a filesystem thing?  I don't see how that is true.

> +Description:
> +		The current endianness of the running kernel.
> +
> +		Access: Read
> +
> +		Valid values:
> +			"little", "big"
> +Users:		util-linux
> diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> index 65dba9076f31..7c7cb2c96ac0 100644
> --- a/kernel/ksysfs.c
> +++ b/kernel/ksysfs.c
> @@ -6,6 +6,7 @@
>   * Copyright (C) 2004 Kay Sievers <kay.sievers@...y.org>
>   */
>  
> +#include <asm/byteorder.h>
>  #include <linux/kobject.h>
>  #include <linux/string.h>
>  #include <linux/sysfs.h>
> @@ -20,6 +21,14 @@
>  
>  #include <linux/rcupdate.h>	/* rcu_expedited and rcu_normal */
>  
> +#if defined(__LITTLE_ENDIAN)
> +#define BYTEORDER_STRING	"little"
> +#elif defined(__BIG_ENDIAN)
> +#define BYTEORDER_STRING	"big"
> +#else
> +#error Unknown byteorder
> +#endif
> +
>  #define KERNEL_ATTR_RO(_name) \
>  static struct kobj_attribute _name##_attr = __ATTR_RO(_name)
>  
> @@ -34,6 +43,14 @@ static ssize_t uevent_seqnum_show(struct kobject *kobj,
>  }
>  KERNEL_ATTR_RO(uevent_seqnum);
>  
> +/* kernel byteorder */
> +static ssize_t byteorder_show(struct kobject *kobj,
> +			      struct kobj_attribute *attr, char *buf)
> +{
> +	return sprintf(buf, "%s\n", BYTEORDER_STRING);

sysfs_emit() please.

And this really is CPU byteorder, right?  We have processors that have
devices running in different byteorder than the CPU.  userspace usually
doesn't need to know about that, but it might be good to be specific.

thanks,

greg k-h