Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp2971066pxv; Sun, 25 Jul 2021 11:49:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxwpvWt1x4gVd+eXiga9rrAPZmSfRhXCSCum9pJAFKi9RgV688MK+t6Ius342ylsfQMZuyD X-Received: by 2002:a05:6402:2213:: with SMTP id cq19mr17360423edb.320.1627238955969; Sun, 25 Jul 2021 11:49:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627238955; cv=none; d=google.com; s=arc-20160816; b=zJJmjfB0kpgBF2tkJBc0NBtBtJmHyIeG1EKS0Z3SIYCJKV9Lsh2hyjRfuUMkThqCF4 ZI3mIsUaPAz02cLV63Z+opjcJ3si7XX1aJ2k5QPLmGML+GwVbnpLSrK8RTZWleIQdivj PKCIklTQWjg5a2kT1kYaJbikebhW26wJYGgMsCf27QNQN7GRsRmZ9QEzu+qsjGd/LDO4 ywlG5DY/cMfYqPSCH54+nCIGA3joICwRdhD9D0ctz6iMFNQyUwJ7L3okUAVfWBitP9f3 bQFwPIILBTpGcQs6pKifxKKT4ylhzJzSPoNbQFHuKzUyQAGir+fbIAqtcJ43jN6cT7SG dItQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=dMobSfRHYbBWRl4NVdimPbb8fzSNZf3DH5Ga5CsdP9A=; b=hL2FJipxP0TNAoQsuACSvTTLKNz8AdoLVlo3DGyItoPpU2nOTVw/RFV04VPoN4Ju8f jAyD/NBXcF0K1Ofhq+NnpVIdbWoB2H9Z8VWnnj3ZXUeNJoT0FHpEW145V0iyne5wk2MF m2E1Udo6XfNWGQynDzANLu3+lhqOljjeji7hvOecPZIGszVeJ3ggrT/1tYcTd99ifhsu op4Iou5idtaCL6AdrG7Q7ieG+RwkZA1E43hlBtc1Ib67H+9iYe5HLEb48kWHBg+1E+lp XcolswFhuG0CK8hqRLOtf2beCk15E5qjf/XR0/nIe4t8x3OFp6OkZZMInCOZMKbPOliC aLJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=kofqxs3I; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z16si7322277edm.532.2021.07.25.11.48.51; Sun, 25 Jul 2021 11:49:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=kofqxs3I; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231215AbhGYSGn (ORCPT + 99 others); Sun, 25 Jul 2021 14:06:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47238 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230217AbhGYSGl (ORCPT ); Sun, 25 Jul 2021 14:06:41 -0400 Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4036FC061760 for ; Sun, 25 Jul 2021 11:47:10 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id l4so8504444ljq.4 for ; Sun, 25 Jul 2021 11:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dMobSfRHYbBWRl4NVdimPbb8fzSNZf3DH5Ga5CsdP9A=; b=kofqxs3IcH4r80Mh3VhgS17F6onJlEBLQsXvccZRkpAGoQj6UEXsEy2ywe5eGdREOy pavfTVf0qTu6CNMNihtymfWzlDuq60oLr4bb2l3p7cZojDlaafWY4Rz+X5qfYwy0IgaS +gRUnN+B3ArdxWFZxZQVwZY0bIRwaS6Al/gMdBw8RiQKA2lMVxta1lZhtAknSQFNUkYQ grej9h0SzYh5fntuFr/SZblKXy8ByyDlTqc1bUaOBFv0cCGmnAz81dAnY/zTBnT/WJX9 U1shyXqlXjgKNxGM232HJ1iQH6pJZONt3IMU+/kX59qkfX5zJmjj7nJstIG2sl2vPWDS wPqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dMobSfRHYbBWRl4NVdimPbb8fzSNZf3DH5Ga5CsdP9A=; b=J25C8+JiRwBYM8AuhtWYh0ohTivfGT3ZHopHF3+kLtHtpX1+A612qzbv/5+7svwHb2 GEMOQOpFrxnhKg4l+GZIU6R5FZnckbIo3Cpn8E/AsR97afHvKEFD20QnRRu0m5yMBwxh rTxRb3qFJDBSTUHcsF1E0/6TLoOonmii0pXEgAqVFn9axv48TBhkEsiaV8Jefnsadzde 1vJ+qlSTWNG4R6fQA8eFhitBbhg96ckVdUiNLQ9DD5Vk0RVOgv8e/OHfk4qK6rT880hP dICaCy4bP+/hrIz5l6Njz4VGnXKjDsWsNmapDs76PkyWe4JYyUk/lEKfjSy3HTYTv2mK wBjQ== X-Gm-Message-State: AOAM532mRvLbYbnJGwx4KIJwteaHvUJieqHGrMgQzrhhd1cgHBJLpKmI l/oHRtnVIeeEbDUEeGzm25GRBSw46nkHWBx3fQIwQA== X-Received: by 2002:a2e:8909:: with SMTP id d9mr9764014lji.65.1627238828055; Sun, 25 Jul 2021 11:47:08 -0700 (PDT) MIME-Version: 1.0 References: <20210723012835.1935471-1-rajatja@google.com> In-Reply-To: From: Rajat Jain Date: Sun, 25 Jul 2021 11:46:32 -0700 Message-ID: Subject: Re: [PATCH] thunderbolt: For dev authorization changes, include the actual event in udev change notification To: Greg KH , Andreas Noever , Michael Jamet , Mika Westerberg , Yehezkel Bernat , "open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:" , Linux Kernel Mailing List , Rajat Jain Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sorry, Had hit "Reply"" while responding, instead of "Reply All" - so it went only to Greg. Now added back everyone else. On Fri, Jul 23, 2021 at 4:43 PM Rajat Jain wrote: > > Hello, > > > On Fri, Jul 23, 2021 at 12:05 AM Greg KH wrote: > > > > On Thu, Jul 22, 2021 at 06:28:34PM -0700, Rajat Jain wrote: > > > For security, we would like to monitor and track when the > > > thunderbolt devices are authorized and deauthorized. Currently > > > the userspace gets a udev change notification when there is a > > > change, but the state may have changed (again) by the time we > > > look at the authorized attribute in sysfs. So an authorization > > > event may go unnoticed. Thus make it easier by informing the > > > actual change (authorized/deauthorized) in the udev change > > > notification. > > > > We do have 72 columns to work with... :) > > Sorry, fixed now. > > > > > > > > > Signed-off-by: Rajat Jain > > > --- > > > drivers/thunderbolt/switch.c | 8 ++++++-- > > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c > > > index 83b1ef3d5d03..5d3e9dcba44a 100644 > > > --- a/drivers/thunderbolt/switch.c > > > +++ b/drivers/thunderbolt/switch.c > > > @@ -1499,6 +1499,7 @@ static ssize_t authorized_show(struct device *dev, > > > static int disapprove_switch(struct device *dev, void *not_used) > > > { > > > struct tb_switch *sw; > > > + char *envp[] = { "AUTHORIZED=0", NULL }; > > > > > > sw = tb_to_switch(dev); > > > if (sw && sw->authorized) { > > > @@ -1514,7 +1515,7 @@ static int disapprove_switch(struct device *dev, void *not_used) > > > return ret; > > > > > > sw->authorized = 0; > > > - kobject_uevent(&sw->dev.kobj, KOBJ_CHANGE); > > > + kobject_uevent_env(&sw->dev.kobj, KOBJ_CHANGE, envp); > > > } > > > > > > return 0; > > > @@ -1523,6 +1524,8 @@ static int disapprove_switch(struct device *dev, void *not_used) > > > static int tb_switch_set_authorized(struct tb_switch *sw, unsigned int val) > > > { > > > int ret = -EINVAL; > > > + char envp_string[13]; > > > + char *envp[] = { envp_string, NULL }; > > > > > > if (!mutex_trylock(&sw->tb->lock)) > > > return restart_syscall(); > > > @@ -1560,7 +1563,8 @@ static int tb_switch_set_authorized(struct tb_switch *sw, unsigned int val) > > > if (!ret) { > > > sw->authorized = val; > > > /* Notify status change to the userspace */ > > > - kobject_uevent(&sw->dev.kobj, KOBJ_CHANGE); > > > + sprintf(envp_string, "AUTHORIZED=%u", val); > > > + kobject_uevent_env(&sw->dev.kobj, KOBJ_CHANGE, envp); > > > > So now "val" is a userspace visable value? Is that documented anywhere > > what it is and what are you going to do to ensure it never changes in > > the future? > > > > Also this new value "field" should be documented somewhere as well, > > otherwise how will any tool know it is there? > > Sorry I should have clarified and elaborated (now done in the new > commit log). The field / value being exposed is that of the existing > sysfs attribute "authorized" > (/sys/bus/thunderbolt/devices/.../authorized), which is already > documented. I made it clearer in the commit log now. I looked at other > uses of kobject_uevent_env() and couldn't find examples of documenting > the Udev environment in Documentation/. > > > > > And what userspace tool will be looking for this? > > It will likely be a udev rule which will trigger a script when it see > device authorization change event. Something like this: > SUBSYSTEM=="thunderbolt", ACTION=="change", ENV{AUTHORIZED}=="1", > RUN+="alert.sh" > > However, now that I say it, is it possible to check for such (kernel > supplied) udev event environment key value pair, using > udev_device_get_property_value()? If so, that makes it very easy for > us, and the tool to use it would be Chromeos daemon called > cros_healthd. > > Thanks, > > Rajat > > > > > thanks, > > > > greg k-h