linux-kernel - Re: [PATCH 14/15] rfkill: do not allow userspace to override ALL RADIOS OFF

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: <200805231615.33414.IvDoorn@gmail.com>
Date:	Fri, 23 May 2008 16:15:33 +0200
From:	Ivo van Doorn <ivdoorn@...il.com>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	linux-kernel@...r.kernel.org, Thomas Renninger <trenn@...e.de>,
	Dmitry Torokhov <dtor@...l.ru>
Subject: Re: [PATCH 14/15] rfkill: do not allow userspace to override ALL RADIOS OFF

On Thursday 22 May 2008, Henrique de Moraes Holschuh wrote:
> On Tue, 20 May 2008, Ivo van Doorn wrote:
> > On Sunday 18 May 2008, Henrique de Moraes Holschuh wrote:
> > > SW_RFKILL_ALL is the "emergency power-off all radios" input event.  It must
> > > be handled, and must always do the same thing as far as the rfkill system
> > > is concerned: all transmitters are to go *immediately* offline.
> > 
> > I don't quite agree here. The SW_RFKILL_ALL key is the one send by thinkpad-acpi,
> > what makes that key so special that is has to be handled differently then a key
> > that only controls a single radio type?
> 
> Well, first there is no KEY involved, it is a SWITCH :-)  But that's not
> the reason it is special.
> 
> What makes SW_RFKILL_ALL special, is that it is the kernel view of *The*
> RFKill Switch.  SW_RFKILL_ALL is the event you get when the user
> manipulates the very *thing* that created the "rfkill switch" term.

So do keys that are pressed that only send the KEY_WLAN, KEY_BLUETOOTH or
KEY_UWB signals. They all indicate the key has been pressed and the radios
should be turned on/off.

> You get that event when someone moves that slider switch in the side/top
> of a laptop which has to kill all RF output in hardware as far as safety
> regulations go.  Therefore, it refers to the only rfkill switch that has
> guidelines that say that it must always work, and that it must not be
> possible to override it in software.

That is a valid point, and rfkill is supposed to do that, but making
a difference between RFKILL_ALL and the individual types is wrong
because that won't result in a clearly defined expected behavior for all
rfkill keys.

> Too bad that doesn't apply to "removable" radio transmitters, like
> PCMCIA and ExpressCard WLAN cards, USB RF transmitters, and so on...
> probably, the user is expected to yank them off when he moves the switch
> to the "no radios working here!" position.  Well, we can do better.  We
> can make it apply to these other radio transmitters, too.

Through the write-only rfkill class right? ;)

> So yes, it *is* special when it is doing its "power DOWN the
> transmitters" function.  It is not special at all when it is in the
> "allow radios to function if they want to" position, which is why I
> special-cased only the "OFF" state.
> 
> IMHO, that makes it special enough to implement it in a different way
> that is not subject to, e.g., brain damage in userspace.
> 
> As for thinkpad-acpi being the only in-tree code issuing that event so
> far, well... I have seen laptops from many vendors with that switch, and
> it is likely that the firmware of at least some of these laptops let you
> know the state of the switch (like the thinkpad firmware does), so I'd
> expect more users of SW_RFKILL_ALL to show up soon.  I am just paving
> the way.
> 
> That, and as an user, I'd really like to be able to implement a
> KEY_RFKILL_ALL keycode to use when I don't have a proper SW_RFKILL_ALL
> in my laptop.  But one thing at a time.  Small steps.
> 
> > All keys should have the same rules when it is pressed, so either all keys should
> > force the change, or none of them should.
> 
> IMO, "kill ALL radios" events are is the only kind of rfkill input event
> that have to *always work*, even if something in userspace tried to
> configure it not to.

Well the definition of "ALL radios" is the part that is the question, when the KEY_WLAN is
pressed it would be "ALL WLAN radios" and should still have the same rules for allowing
or disallowing userspace to overwrite the status.

Ivo
--
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/