Hey Ed,
Yes, as you said, we've descended into design review again. ;) I guess
it's because these fast changes/features in Xorg were not foreseeable
during the initial design.
Your philosophy of more simple interface between the application and
the kernel is what I have been seeking.
Here is some of my primary thoughts on what you pointed out. Please advise.
1) The HID streams switch ioctls are still needed, even though within
the kernel.
If the kernel knows which hid device is related to which VT, it (console)
still need to tell the hid driver to switch streams when necessary.
2) The following is the current architecture digram.
Letting console know about the information in hid level sounds bad to me.
The other option is to let conskbd maintain the info of which hid device
is related to which VT. This would result in conskbd knowing about
console/VT details. Still not good.
+---------+ | |
| console | | |
+----+----+ | |
| | |
| | |
+-+-------+--+ |
| conskbd | |
+--------+---+ |
| |
| |
+-+---------+--+
| hid |
+--------------+
3) Say Xorg registers which input device it's using during start up to
the kernel, and upon receiving that ioctl, the kernel (either console
or conskbd) set up a list of input devices for each VT. What if
Xorg gets killed and does not have the chance to issue the ioctl to
inform the kernel to free the list?
Yes, every opened file would be closed, it could be the hid driver
tell the list maintainer to update, would it involve complex interfaces
between the 3 components -- console/conskbd/hid?
Regards,
Aaron
On 06/05/09 10:20, Edward Pilatowicz wrote:
> ok. we've descended into design review here, so i'll toss in my $0.02.
>
> wrt the comments below, i think that having the X server close and
> re-open devices during VT switches is a bad idea. too much complexity
> and lots of opportunites for ugly failures.
>
> i understand that the HIDIOCKM?DIRECT ioctls are modeled after the
> KIOC?DIRECT, but imho, the suggested ioctls also suffer from some ugly
> potential failure modes as well. for example, what does the X server do
> if this ioctl call fails. will the VT we switch to work? or if the X
> server never issues these ioctls (because it's hung or for some other
> reason), will we switch to a VT that can't get any input?
>
> hence, if at all possible, i'd like the kernel to handle all these
> plumbing changes automatically rather than requiring additional X server
> interactions whenever a VT switch occurs.
>
> so would it be possible to introduce a new ioctl that the X server could
> use that would tell the kernel that a given device stream (hid, or
> /dev/mouse, /dev/kbd, etc) is associated with a specific VT? if we had
> such an ioctl then when the X server opened an input device it would
> immediatly issue the ioctl to associate the device with the VT it's
> using. (if the X server isn't using a VT but is instead running on a
> dedicated framebuffer, it wouldn't issue the ioctl.) that way, the
> kernel could keep track of input device stream to VT bindings, and when
> switching between VTs it could automatically redirect device streams as
> necessary without requiring any interractions from the X server.
>
> thoughts?
> ed
>
> On Wed, Jun 03, 2009 at 10:20:38AM +0800, Aaron Zang wrote:
>> I'd like to summarize the request or benefit of this pair of ioctls.
>>
>> 1. Switching from Xorg to console while Xorg is running as a non-root
>> user. Of course we can seteuid() to root, close the input devices
>> and reopen them with root euid again while switching back to Xorg.
>> The thing is the handling of VT switching in xfree86 level of Xorg
>> (not down to Solaris level yet) *disables* the input devices instead
>> of closing them. If we were to adopt the close/reopen way, we need
>> to add Solaris specific code to the xfree86 level which seems ugly
>> to me and does not align with the handling of other OSes. Since
>> the upstream is the Xorg community, the better we make our changes
>> in Solaris specific level the better.
>> Plus, not setting euid to root again reduces the risk of potential
>> security attacks.
>>
>> 2. When we are back on console, Xorg is still listening to HAL.
>> If a keyboard is hooked up, Xorg will get the hotplug inform
>> from HAL and thus will open the keyboard via its hid nodes.
>> This would cause the input routed to the external stream even
>> if we are on the console now. Without the ioctl, the keyboard
>> will not be usable until we switch to Xorg. It could be reproduced
>> on my prototype of Xorg vt support.
>> Maybe the Xorg can ignore the input device hotplugging information
>> while on console, and query the info again upon switching back.
>> But this would involve deciding which input devices are old and
>> which are newly plugged. Complex.
>>
>> 3. hid device driver maintains 2 streams, ioctls to control the
>> routing of input between these 2 streams seems to be a natural
>> thing. If we can save the above complexities with these 2 simple
>> ioctls and accomplish a desirable clear architecture, why not?
>>
>>
>> The above are what I could think of till now.
>>
>> Regards,
>> Aaron
>>
>>
>> On 06/03/09 08:46, Aaron Zang wrote:
>>> Actually this case is not with the intention to fix the hotplugged
>>> devices bug.
>>> Yes, Xorg needs to seteuid(0) back to open the newly plugged devices.
>>> But for the existing devices which are already opened, would it be
>>> easier and
>>> better to just send down a ioctl to switch streams than closing them on
>>> switching
>>> away and opening them upon switching back with seteuid(0)?
>>>
>>> I was just following the idea of KIOCSDIRECT ioctl, and at least to me, the
>>> shorter of time an application is running with euid 0 the better.
>>>
>>>
>>> Regards,
>>> Aaron
>>>
>>>
>>> On 06/03/09 08:28, Alan Coopersmith wrote:
>>>> James Carlson wrote:
>>>>> Alan Coopersmith writes:
>>>>>> That's a bug that was just reported to me in private e-mail while
>>>>>> I was out on
>>>>>> vacation last week. We need to fix Xorg to setuid back to root
>>>>>> before opening
>>>>>> hotplugged devices.
>>>>> So ... with that bug fixed, does the need for this special ioctl
>>>>> remain? Doesn't closing the descriptor and reopening it when needed
>>>>> fix the problem?
>>>> Now that I've had a chance to look at it and not just read the
>>>> e-mail, I'm
>>>> trying to determine if that is the correct fix or if the bug is in
>>>> the kernel
>>>> side. The devices are owned by the uid Xorg is running as, due to
>>>> logindevperms, but it seems additional privileges are being required
>>>> by the
>>>> kernel drivers (PRIV_SYS_DEVICES) - if it's correct for them to
>>>> require that,
>>>> then I'll work on fixing Xorg to seteuid(0) there. (Xorg has not
>>>> been made
>>>> privilege aware so far since the two states it has needed in the past
>>>> are "all privileges" during server/device initialization, and the
>>>> basic set
>>>> provided by seteuid to a non-root user during most of runtime, so
>>>> there was no
>>>> benefit in adding privilege awareness to the code.)
>>>>
>>>> I was not involved in the decision to create this ioctl, so I can't
>>>> answer
>>>> their motivations or why the project team decided creating an ioctl was
>>>> better than adding an additional spot for Xorg to return to uid 0.
>>>>
>> --
>> You know some birds are not meant to be caged, their feathers are just too
>> bright.
>> ????????????????????????
--
You know some birds are not meant to be caged, their feathers are just too
bright.
????????????????????????
