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:   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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ