linux-kernel - Re: [PATCH v2] kobject: add kernel/uevent

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:   Fri, 7 Dec 2018 13:01:23 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Peter Rajnoha <prajnoha@...hat.com>
Cc:     linux-kernel@...r.kernel.org, msekleta@...hat.com
Subject: Re: [PATCH v2] kobject: add kernel/uevent_features sysfs file

On Fri, Dec 07, 2018 at 12:46:07PM +0100, Peter Rajnoha wrote:
> We can use extended format when writing /sys/.../uevent files to
> generate synthetic uevents, introduced with commit f36776fafbaa
> ("kobject: support passing in variables for synthetic uevents").
> 
> Before using this extended format, we need to know if it's supported
> and kernel version check may not be appropriate in all cases - there
> are possible differences from upstream kernel in distributions with
> backports.
> 
> This patch adds /sys/kernel/uevent_features file which currently lists
> 'synthargs' string to denote that the kernel is able to recognize the
> extended synthetic uevent arguments. Userspace can easily check for
> the feature then.

So this is just to try to have userspace detect what type of feature the
kernel has?  Why can't you just go off of the other sysfs file itself?
You shouldn't need a "this is a feature list" for the kernel, otherwise
we would be on a huge slippery slope trying to document everything.

Who is going to use this thing?  And what else would go into it?

Isn't there some other way you can detect this from userspace (like
writing to the file and it fails?)

thanks,

greg k-h