linux-kernel - Re: [PATCH 4/8] rfkill: add read-write rfkill switch support

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: <20080414143603.GA31298@khazad-dum.debian.net>
Date:	Mon, 14 Apr 2008 11:36:03 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Ivo van Doorn <ivdoorn@...il.com>, linux-kernel@...r.kernel.org,
	"John W. Linville" <linville@...driver.com>
Subject: Re: [PATCH 4/8] rfkill: add read-write rfkill switch support

On Mon, 14 Apr 2008, Dmitry Torokhov wrote:
> What exactly breaks with user_claim? I think the general issue is that

The same thing that happens if userspace is in charge and doesn't
cooperate or if rfkill-input is not loaded:  the rfkill driver state is
never updated (remember, it is about the radio controller, not the input
device).

> rfkill was originally not supposed to be used with switches that can't
> be programmatically controlled. If we have a switch that mechanically

The input layer does not provide a way for userspace to get access to
the current state of any switches easily (or at all?).  It just exports
events reporting these states sometimes.

We could fix it in the input subsystem, instead.  How difficult (and
welcome a change?) would it be for the input device infrastructure to
provide pollable (for good measure!) "state" attributes for every EV_SW
event an input device registers in evbits+swbits ?

If the input subsystem exports that information, we can define that
slave read-only radio controllers must NOT be registered as rfkill
devices, and drop support for read-only rfkill devices, as all master
rfkill devices (which are input devices by definition) would get their
state exported to userspace through the input layer.

However, that DOES mean userspace would need to look for rfkill state in
two places.  Input layer, to get the current state of the rfkill input
devices, and rfkill class to get the current state of the rfkill
radio controllers.

> The input side (input polldev or other kind of button/switch/slider
> inmplementation) still can issue KEY_WLAN or something to indicate that
> user toggled the state and userspace or kernel may try to shut off the
> rest of RF transmitters in the box but as far as this particlular
> switch goes it is game over. I expected that here we'd just rely on
> netif_carrier_* to notify the network side of things about interface
> losing connection.

Yes.  And that's the plan, actually.  But it DOES NOT work at all with
the current mess, which used input events to keep the internal
rfkill->state state in sync with the hardware.

> Unfortunately (or may be fortunately, I am not quite sure yet) rfkill

Let's decide this NOW, then.  But if we decide to not do it in rfkill,
you will have to add attributes to every input device which has
registered itself as a source of EV_SW events.

> started to be used for mechanical type switches as well, disabling
> user_claim option, so now we do need the "read-only" kind of rfkill
> switch support that allows setting switch state directly from the
> driver.

We always had read/write rfkill controllers, they were just not properly
supported at all, and that is the root cause of the mess.

Anyway, do we fix read-only rfkill input device support in the input
layer (add access to their state using sysfs and make it clear they are
NOT to be registered with rfkill class) or in the rfkill class (add
read-only rfkill controller support)?

I better make it clear that I have NO idea how to properly implement the
required changes in the input layer if we go that way so if it is left
for me to do that work, it won't be ready anytime soon and it might be
supbar, so I'd appreciate lots of help in that case.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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/