| 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
| ||
|
Message-Id: <78DBB3F7-A3E8-431F-B8E2-AE54D24F9D00@konsulko.com>
Date: Wed, 16 Sep 2015 22:08:08 +0300
From: Pantelis Antoniou <pantelis.antoniou@...sulko.com>
To: Rob Herring <robherring2@...il.com>
Cc: Frank Rowand <frowand.list@...il.com>,
Matt Porter <mporter@...sulko.com>,
Koen Kooi <koen@...inion.thruhere.net>,
Guenter Roeck <linux@...ck-us.net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>
Subject: Re: [PATCH v5 3/4] of: overlay: add per overlay sysfs attributes
Hi Rob,
> On Sep 16, 2015, at 19:45 , Rob Herring <robherring2@...il.com> wrote:
>
> On Wed, Sep 16, 2015 at 11:09 AM, Pantelis Antoniou
> <pantelis.antoniou@...sulko.com> wrote:
>> The two default overlay attributes are:
>>
>> * A targets sysfs attribute listing the targets of the installed
>> overlay. The targets list the path on the kernel's device tree
>> where each overlay fragment is applied to
>>
>> * A per overlay can_remove sysfs attribute that reports whether
>> the overlay can be removed or not due to another overlapping overlay.
>>
>> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@...sulko.com>
>> ---
>
> How about an answer to my v4 questions?
>
Q. "What will a user do with this information? Can this just be debugfs?
Don't we already have the targets in the overlay itself? If we are
going to provide some overlay info, shouldn't we provide all of it
(i.e. the FDT). For example, what do we do on a kexec?”
A. The user can easily tell whether an overlay is removable using the can_remove
attribute. This can be used by higher layer to inform users whether it’s safe to
remove an overlay or not (perhaps light up a BUSY led)
The targets attribute can let the user figure out what devices (as evident by the
nodes they point to) are affected by the overlay. This was actually used by me
to figure out the TI LCDC DRM driver use of overlays by looking at the targets
pointing there.
Debugfs is a bad fit since these are per-overlay attributes that a user-space application
can use to present some kind of meaningful information to the user.
Providing the FDT of the overlay is only possible when the overlay origin is indeed a
DT blob, which is not always the case. The overlay API only uses unflattened trees.
The DT blob can be provided only by the caller, which has access to the blob.
To hang the FDT blob to overlay kobj we need to extend the overlay API to
return the kobj of the overlay (which I intent to do in the near future).
Kexec is really tricky. I purposefully didn’t try to address it since in the
previous discussion with Grant we couldn’t get to an agreed default. It seems it is
a per-platform/per-policy decision, and we lack the users to tell us which is the most
prominent.
We have two ways to handle it: a) Leave the kernel tree as it is, flatten it and
kexec with it. That would remove the overlays but the state of the the devices would persist.
b) Remove the overlays in the proper sequence and kexec with the clean kernel tree. That
would necessitate the re-application of the overlays to get to the same device tree state.
> Rob
>
Regards
— Pantelis
>> drivers/of/overlay.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 53 insertions(+)
>>
>> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
>> index 62cfb99..cff3c05 100644
>> --- a/drivers/of/overlay.c
>> +++ b/drivers/of/overlay.c
>> @@ -373,8 +373,61 @@ static const struct attribute *overlay_global_attrs[] = {
>> NULL
>> };
>>
>> +static ssize_t can_remove_show(struct kobject *kobj,
>> + struct kobj_attribute *attr, char *buf)
>> +{
>> + struct of_overlay *ov = kobj_to_overlay(kobj);
>> +
>> + return snprintf(buf, PAGE_SIZE, "%d\n", overlay_removal_is_ok(ov));
>> +}
>> +
>> +static ssize_t targets_show(struct kobject *kobj,
>> + struct kobj_attribute *attr, char *buf)
>> +{
>> + struct of_overlay *ov = kobj_to_overlay(kobj);
>> + struct of_overlay_info *ovinfo;
>> + char *s, *e;
>> + ssize_t ret;
>> + int i, len;
>> +
>> + s = buf;
>> + e = buf + PAGE_SIZE;
>> +
>> + mutex_lock(&of_mutex);
>> +
>> + /* targets */
>> + for (i = 0; i < ov->count; i++) {
>> + ovinfo = &ov->ovinfo_tab[i];
>> +
>> + len = snprintf(s, e - s, "%s\n",
>> + of_node_full_name(ovinfo->target));
>> + if (len == 0) {
>> + ret = -ENOSPC;
>> + goto err;
>> + }
>> + s += len;
>> + }
>> +
>> + /* the buffer is zero terminated */
>> + ret = s - buf;
>> +err:
>> + mutex_unlock(&of_mutex);
>> + return ret;
>> +}
>> +
>> +static struct kobj_attribute can_remove_attr = __ATTR_RO(can_remove);
>> +static struct kobj_attribute targets_attr = __ATTR_RO(targets);
>> +
>> +static struct attribute *overlay_attrs[] = {
>> + &can_remove_attr.attr,
>> + &targets_attr.attr,
>> + NULL
>> +};
>> +
>> static struct kobj_type of_overlay_ktype = {
>> .release = of_overlay_release,
>> + .sysfs_ops = &kobj_sysfs_ops, /* default kobj sysfs ops */
>> + .default_attrs = overlay_attrs,
>> };
>>
>> static struct kset *ov_kset;
>> --
>> 1.7.12
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists