Re: NetBSD drivers on HURD?

[Jan Kratochvil]

Hi,

On Fri, 29 Jul 2005 23:02:52 +0900, Alfred M. Szmidt wrote:
> Please, lets not support binary drivers, they only remove our freedoms.

You already have no freedoms. I am considering these issues pretty seriously.
It is just not so simply black&white.

* The primary problem is 'closed' hardware itself - undocumented registers,
  no disclosal of any information by the hardware vendor.
  If you want to keep your freedoms you must never buy such hardware.
  In real I expect you will fail assemble fully documented PC these days.

* Reverse engineered reimplementations do not make sense.
  What is the difference between azt3328.c:
        *  Since Aztech does not provide any chipset documentation,
        *  I was forced to base this driver on reverse engineering
        #define DMA_PLAY_SOMETHING1           0x0002 /* \ alternated (toggled) 
*/
        #define DMA_PLAY_SOMETHING2           0x0004 /* / bits */
        #define DMA_RESUME                    0x0001 /* paused if cleared ? */
        #define SOMETHING_ALMOST_ALWAYS_SET   0x0008 /* ???; can be modified */
        #define DMA_EPILOGUE_SOMETHING        0x0010
        #define DMA_SOMETHING_ELSE            0x0020 /* ??? */
        outw(DMA_PLAY_SOMETHING1, chip->codec_port+IDX_IO_PLAY_FLAGS);
        outw(DMA_PLAY_SOMETHING1|DMA_PLAY_SOMETHING2, 
chip->codec_port+IDX_IO_PLAY_FLAGS);
        
outw(DMA_RESUME|SOMETHING_ALMOST_ALWAYS_SET|DMA_EPILOGUE_SOMETHING|DMA_SOMETHING_ELSE,
 chip->codec_port+IDX_IO_PLAY_FLAGS);
  and azt3328s.sys:
        128b:   8a 46 0e        mov     0xe(%esi),%al
        128e:   6a 02           push    $0x2
        1290:   50              push    %eax
        1291:   53              push    %ebx
        1292:   57              push    %edi
        1293:   e8 bc fb ff ff  call    0xe54
        1298:   8a 46 0e        mov     0xe(%esi),%al
        129b:   6a 06           push    $0x6
        129d:   50              push    %eax
        129e:   53              push    %ebx
        129f:   57              push    %edi
        12a0:   e8 af fb ff ff  call    0xe54
        12a5:   8a 46 0e        mov     0xe(%esi),%al
        12a8:   6a 39           push    $0x39
        12aa:   50              push    %eax
        12ab:   53              push    %ebx
        12ac:   57              push    %edi
        12ad:   e8 a2 fb ff ff  call    0xe54

  Do not be fooled this is just an exception. Reverse engineering IS a common
  "Free" drivers development method just the nobody can admit it as the drivers
  (or maybe just their development) would become in many countries illegal.

  How is the C re-coded way better that its original binary/disassembled form?
  I even no longer differentiate C and disassembly much, one gets used.
  By re-coding the driver (either hardware driver or ntfs.sys ->
  -> http://linux-ntfs.sf.net) you do not gain any new freedom, you just get
  exposed to the re-coding bugs (there WILL be) and when the vendor releases
  the new release of its binary driver with all the binary offsets different
  you have bad chance to diff(1) the new disassembly. Are you going to do the
  reverse engineering all again from scratch to find what the vendor got fixed
  there and re-code it to your "Free" C driver reimplementation?

  Re-coding is just about closing eyes before the reality, self-fooling.

  * You would loose trojan-insertion security if running the binary driver in
    privileged mode. Captive NTFS solves it by security sandboxing ntfs.sys
        http://www.jankratochvil.net/project/captive/doc/Details.html.pl#sandbox
    in a hacky mode, HURD has better dispositions for such security sandboxing.
    So there is no security loss this way.

* compatibility in general, in NTFS case:
  NTFS has no meaning as a standalone filesystem - there are better GPL high
  performance mature filesystems such as reiserfs or xfs.
  NTFS for Free OS has its only meaning as a temporary compatibility hack.

* system security: If you want NTFS support I bet you ran MS-Windows natively
  on your machine with unprotected/accessible GNU/Linux partition.
  MS-Windows could insert (=you must handle it as "inserted") trojan there so
  you already lose all your security.

  * general way: If you insert PCI card into your computer with that 1MB
    of proprietary firmware - what is your system security? It can directly
    access and crack any Free OS memory, insert trojans there etc.
    There is no longer real system security these days.

* why just computers?: OK, so you have your PC Free (I do not know how did you
  manage it, though). Do you have control over your mobile phone? Over your
  microwave? Over your car? I care much more if I get killed in my car due to
  the buggy brake_control() function there than for stolen mails from my PC.
  Stallman's idea of Free world was nice in 198x but today it is just utopia.

Just some thoughts.


Regards,
Lace