Re: New tools proposal: ioctlname and ioctldecode

2020-04-02 Thread Christos Zoulas
In article <2096.1585816...@jinx.noi.kre.to>,
Robert Elz   wrote:
>Date:Thu, 2 Apr 2020 04:11:17 +0200
>From:Kamil Rytarowski 
>Message-ID:  
>
>  | This is partially enforceable. As once we generate catchall switch like:
>  |
>  | case FOO_OP:
>  | ...
>  | case BAR_OP:
>  | ...
>  |
>  | a compiler will report error whenever FOO_OP = BAR_OP.
>
>That makes it easy to detect, not enforce.   Once detected that way,
>what happens next?  Neither will (or can really) change as they both
>have existing applications compiled that use them - in the worse case
>the conflicts come from attempting to implement compat mode for someone
>else's binaries, and support their existing ioctl's (which we obviously
>cannot alter) - and do that for two different systems at once.
>
>This is the same reason we cannot fix the few duplicates that exist in
>our code - we want to retain backward binary compatibility, which means
>supporting ancient binaries that happen to use those ioctl values.
>
>Avoiding conflicts is (always has been) the aim - it allows drivers to
>detect attempts to use an ioctl intended for some different device, rather
>than believing it was intended for them, but there simply isn't, and can't
>really be, any way to enforce that.
>
>kre
>
>ps: don't forget all the sockioctl()s which also need decoding.   Perhaps
>even more than device ioctls.

We already have a lot of dups. See the mkioctls script.

christos



Re: New tools proposal: ioctlname and ioctldecode

2020-04-02 Thread Robert Elz
Date:Thu, 2 Apr 2020 04:11:17 +0200
From:Kamil Rytarowski 
Message-ID:  

  | This is partially enforceable. As once we generate catchall switch like:
  |
  | case FOO_OP:
  | ...
  | case BAR_OP:
  | ...
  |
  | a compiler will report error whenever FOO_OP = BAR_OP.

That makes it easy to detect, not enforce.   Once detected that way,
what happens next?  Neither will (or can really) change as they both
have existing applications compiled that use them - in the worse case
the conflicts come from attempting to implement compat mode for someone
else's binaries, and support their existing ioctl's (which we obviously
cannot alter) - and do that for two different systems at once.

This is the same reason we cannot fix the few duplicates that exist in
our code - we want to retain backward binary compatibility, which means
supporting ancient binaries that happen to use those ioctl values.

Avoiding conflicts is (always has been) the aim - it allows drivers to
detect attempts to use an ioctl intended for some different device, rather
than believing it was intended for them, but there simply isn't, and can't
really be, any way to enforce that.

kre

ps: don't forget all the sockioctl()s which also need decoding.   Perhaps
even more than device ioctls.



Re: New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Kamil Rytarowski
On 02.04.2020 04:06, Mouse wrote:
>> We should maintain a contract that all new ioctl operations are
>> system wide unique.
>
> That is, unfortunately, unenforceable in the presence of a user base
> that writes and shares code.  If I #define IOCNEWTHING _IO('?',7) and
> someone else #defines IOCOTHERTHING _IO('?',7), there really isn't any
> way to prevent that, nor to prevent them from conflicting when - and
> eventually it will happen - someone wants to run a system with both new
> thing and other thing.
>

This is partially enforceable. As once we generate catchall switch like:

case FOO_OP:
...
case BAR_OP:
...

a compiler will report error whenever FOO_OP = BAR_OP.



Re: New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Mouse
> We should maintain a contract that all new ioctl operations are
> system wide unique.

That is, unfortunately, unenforceable in the presence of a user base
that writes and shares code.  If I #define IOCNEWTHING _IO('?',7) and
someone else #defines IOCOTHERTHING _IO('?',7), there really isn't any
way to prevent that, nor to prevent them from conflicting when - and
eventually it will happen - someone wants to run a system with both new
thing and other thing.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Re: New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Kamil Rytarowski
On 02.04.2020 03:33, Mouse wrote:
 $ ioctlname 2148554498
 WSKBDIO_COMPLEXBELL
>>> Where would you get the mapping between the ioctl value and the
>>> name?  [...]
>> Everything is already done in kdump and reused in other tools like
>> ktruss.
>
> So, the big switch() method.
>

Yes.

We should maintain a contract that all new ioctl operations are system
wide unique.

>>> What about collisions, two ioctls having the same numeric value?
>> There are some collisions, but not that many of them.  In these cases
>> we try to pick the more interesting device.
>
> For kdump, that makes some sense.  For this tool, I think it would make
> the most sense to report them all.  (Arguably, kdump should too...)
>
> Of course, that would mean changing things at least slightly from the
> current kdump approach.  I'm not sure that would necessarily be a bad
> thing, especially if we could somehow (major handwave here) tell which
> ioctls go together, in which case kdump could do heuristics along the
> lines of "this fd accepted FOO_IOC_A, so we're going to decode this one
> as FOO_IOC_B rather than BAR_IOC_C".
>

This would be ideal... however it's not that simple and I would
recommend to go with the path of removing the conflicts entirely for the
general benefit.

For the time being we just live with conflicts and ignore a subset of
operations.

From a quick look there are conflicts e.g. due to chio(1) a SCSI charger
added in NetBSD 1.3 for and.com. Are there still any users?


Re: New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Mouse
>>> $ ioctlname 2148554498
>>> WSKBDIO_COMPLEXBELL
>> Where would you get the mapping between the ioctl value and the
>> name?  [...]
> Everything is already done in kdump and reused in other tools like
> ktruss.

So, the big switch() method.

>> What about collisions, two ioctls having the same numeric value?
> There are some collisions, but not that many of them.  In these cases
> we try to pick the more interesting device.

For kdump, that makes some sense.  For this tool, I think it would make
the most sense to report them all.  (Arguably, kdump should too...)

Of course, that would mean changing things at least slightly from the
current kdump approach.  I'm not sure that would necessarily be a bad
thing, especially if we could somehow (major handwave here) tell which
ioctls go together, in which case kdump could do heuristics along the
lines of "this fd accepted FOO_IOC_A, so we're going to decode this one
as FOO_IOC_B rather than BAR_IOC_C".

I suppose that's the hazard of catchall interfaces like ioctl(): they
are difficult to make usefully discoverable.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Re: New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Christos Zoulas


> On Apr 1, 2020, at 9:27 PM, Kamil Rytarowski  wrote:
> 
> I've implemented:
> 
> ioctlprint [-f format] [-e emul] arg...
> 
> $ ./ioctlprint   2148554498 2148554498
> WSKBDIO_COMPLEXBELL _IOW('W',0x2,0x10) 0x80105702
> WSKBDIO_COMPLEXBELL _IOW('W',0x2,0x10) 0x80105702
> 
> $ ./ioctlprint -f "%o %d %d %i %x %e %n\n"  2148554498
> 020004053402 2148554498 2148554498 2148554498 0x80105702
> _IOW('W',0x2,0x10) WSKBDIO_COMPLEXBELL
> 
> %n - name
> %e - expression
> %x - print HEX number
> %o - print OCT number
> %d %i - print DEC number
> 
> http://netbsd.org/~kamil/patch-00245-kdump-ioctlname.3.txt


You are fast! I'd write a man page and commit it.

christos


signature.asc
Description: Message signed with OpenPGP


Re: New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Kamil Rytarowski
On 02.04.2020 02:14, Christos Zoulas wrote:
> In article <0fd513f7-6f0c-6ed1-2119-6ce5313d4...@gmx.com>,
> Kamil Rytarowski   wrote:
>> I propose to add two new tools:
>>
>> - ioctlname
>> - ioctldecode
>
> I would call it ioctlprint and have:
>
> ioctlprint [-f ] || arg
>
> for the input arg can be:
> name = TIOCFOO
> expr = _IO?('x', y, z)
> value = 0xfoobee
>
> The format can be contain %e %n %v which expand to what you
> think and defaults to:
>
> "%n %e %v\n"
>
> christos
>

I've implemented:

ioctlprint [-f format] [-e emul] arg...

$ ./ioctlprint   2148554498 2148554498
WSKBDIO_COMPLEXBELL _IOW('W',0x2,0x10) 0x80105702
WSKBDIO_COMPLEXBELL _IOW('W',0x2,0x10) 0x80105702

$ ./ioctlprint -f "%o %d %d %i %x %e %n\n"  2148554498
020004053402 2148554498 2148554498 2148554498 0x80105702
_IOW('W',0x2,0x10) WSKBDIO_COMPLEXBELL

%n - name
%e - expression
%x - print HEX number
%o - print OCT number
%d %i - print DEC number

http://netbsd.org/~kamil/patch-00245-kdump-ioctlname.3.txt


Re: New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Kamil Rytarowski
On 02.04.2020 02:56, Mouse wrote:
>> $ ioctldecode 2148554498
>> _IOW('W',0x2,0x10)
>
>> $ ioctlname 2148554498
>> WSKBDIO_COMPLEXBELL
>
> Where would you get the mapping between the ioctl value and the name?
> Would this be just a huge switch statement (or compiled-in table), or
> would it search /usr/include/sys at runtime, or what?
>
> In particular, would any special action need to be taken upon adding a
> new ioctl for it to be recognized?
>

Everything is already done in kdump and reused in other tools like
ktruss. Please check: src/usr.bin/kdump/Makefile.ioctl-c.

> What about collisions, two ioctls having the same numeric value?  (I'm
> not aware of any offhand, but I'd be astonished if it never happened.)
>

There are some collisions, but not that many of them. In these cases we
try to pick the more interesting device.

In sanitizers there are around 2000 individual ioctls and 51 collisions.
Some of them are gone as we remove old unmaintained device drivers.


Re: New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Mouse
> $ ioctldecode 2148554498
> _IOW('W',0x2,0x10)

> $ ioctlname 2148554498
> WSKBDIO_COMPLEXBELL

Where would you get the mapping between the ioctl value and the name?
Would this be just a huge switch statement (or compiled-in table), or
would it search /usr/include/sys at runtime, or what?

In particular, would any special action need to be taken upon adding a
new ioctl for it to be recognized?

What about collisions, two ioctls having the same numeric value?  (I'm
not aware of any offhand, but I'd be astonished if it never happened.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Re: New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Christos Zoulas
In article <0fd513f7-6f0c-6ed1-2119-6ce5313d4...@gmx.com>,
Kamil Rytarowski   wrote:
>I propose to add two new tools:
>
> - ioctlname
> - ioctldecode

I would call it ioctlprint and have:

ioctlprint [-f ] || arg

for the input arg can be:
name = TIOCFOO
expr = _IO?('x', y, z)
value = 0xfoobee

The format can be contain %e %n %v which expand to what you
think and defaults to:

"%n %e %v\n"

christos



New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Kamil Rytarowski
I propose to add two new tools:

 - ioctlname
 - ioctldecode

Both of them are a special mode embedded into kdump(1).

>From time to time there is need to decode IOCTL codes and there is no
(as far as I am aware) easy tool to do so.

ioctlname is already invented and it calls the internal function
ioctldecode().

commit f551b480cd03a35cec2a4927270c00cfaa508a27
Author: christos 
Date:   Mon Apr 13 14:39:23 2009 +

Allow kdump to be used as an ioctl decoder if invoked as ioctlname.



Today the internal/hidden program ioctlname produces something like:
"_IOW('W',0x2,0x10)".

I propose to rename this program to ioctldecode and change ioctlname to
print a descriptive operation name as received by the ioctlname() function.

$ ioctldecode 2148554498
_IOW('W',0x2,0x10)

$ ioctlname 2148554498
WSKBDIO_COMPLEXBELL

I propose to install both programs and add appropriate man-pages.

A functional patch is here:

http://netbsd.org/~kamil/patch-00245-kdump-ioctlname.2.txt