[M3devel] Socket error hacks for Ultrix and OSF?

[Daniel Alejandro Benavides D.]

Hi all:
Jay I deliberately want to quote you this text for your better understanding [1] (I hope it to be so):
"...
Software Security Explained
The concepts behind secure software are often simple but rarely considered by most programmers in the design and implementation of their programs.
The following are prime tenets in writing secure software:
Give your software the least privileges it needs.
Check all return codes religiously.
..."

http://books.google.com.co/books?id=uGiOR1mrxggC&dq=inauthor%3A%22Jeff+Schmidt%22&q=%22software+security%22#search_anchor

And specifically for ther matter of "assumptions" and pointer initialization:

http://www.drdobbs.com/security/safe-programming-with-modula-3/184408858

note that if you guarantee "assumptions" or " absence of unchecked run-time errors" you can argue that still you export the interface as safe. in SPwM3 [2] p.45

"...
2.5.7 Safety
...
An interface is 'intrinsically safe' if there is no way to produce an unchecked runtime error by using the interface in a safe module.
..."

Now if you say, the VAX9000 or Alpha had probably errors more than any other computer in the era, it could mean that the VAX9000 or Alpha had runtime unchecked errors (probably by that much as any other but let's read this $1.4.5 Safety paragraph) : SPwM3 p. 7
"...
 1.4.5 Safety
 ...
Unfortunately, it is generally impossible to program the lowest levels of a system with complete safety. Neither the compiler nor the runtime system can check the validity of a bus address for an I/O controller, nor can they limit the ensuing havoc if it is invalid. This presents the language designer with a dilemma. Of he holds out for safety, then low level code will have to be programmed in another language. But if he adopts unsafe features his safety guarantee becomes void everywhere
..."

Now, in every definition of safety of a language there must be the unchecked runtime errors (errors than can occur without isolation guarantee), you must define them explicitly as a subset of all untrapped errors. I think one of them is the mentioned above, if we could agree on this errors by platform we can say our language implementation is safe in this proportions due machine restrictions. In case of VAX9000 architecture segments were defined for separated testing of multichip Modules, you could argue you can still work in a isolated machine and guarantee each piece of Hardware satisfies certain properties, so you could think in a top-down fashion how would you build and test your machine for errors that are HW failures and in some cases avoid running the program in those conditions by using fault tolerance.
There was a VAXft9000 and Alpha's versions of itself, of course this costs lot more to work in that way, so in general you can't do that as SPwM3 says, but if you want we can do it.

Thanks in advance

[1] J. Schmidt, Microsoft Windows 2000 security handbook. Que, 2000.
[2] C. G. Nelson, Systems programming with Modula-3. Prentice Hall, 1991.

--- El lun, 4/2/13, Jay K <jay.krell at cornell.edu> escribió:

De: Jay K <jay.krell at cornell.edu>
Asunto: [M3devel] Socket error hacks for Ultrix and OSF?
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: lunes, 4 de febrero, 2013 02:14



We have:

      WITH errno = GetError() DO
        IF errno = EINVAL THEN
          (* hack to try to get real errno, hidden due to NBIO bug in connect *)
          RefetchError (t.fd);
        ELSIF errno = EBADF THEN
          (* we'll try the same for EBADF, which we've seen on Alpha *)
          RefetchError (t.fd);
        END;
      END;


PROCEDURE RefetchError(fd: INTEGER) =
(* Awful hack to retrieve a meaningful error from a TCP accept
   socket.  Only works on Ultrix and OSF.  Leaves result
   in GetError().  *)
  VAR optbuf: int := 0;   optlen: socklen_t := BYTESIZE(optbuf);
  BEGIN
    IF SocketPosix_IsUltrixOrOSF.Value THEN
      EVAL getsockopt (fd, IPPROTO_TCP, TCP_NODELAY,
                       ADR(optbuf), ADR(optlen));
    END;
  END RefetchError;


does anyone know or believe this is useful code?
Does anyone object to removing it?
I don't believe we'll ever run on Ultrix.
OSF/Tru64 is of very marginal interest.
Posix doesn't bless this code.
It seems ok without this -- it is a subtle matter of precisely which error is raised.
Portable code can't depend on the supposedly better Ultrix/OSF behavior, unless they are substandard and return EINVAL/EBADF when other systems return something more specific.
If I could find this workaround in any half way recently maintained C or C++ (Perl? Python?) I'd feel a lot better. I guess I'll look.



More generally I'd like to see the essentially 4 socket libraries we have (libm3/posix, libm3/win32, m3-comm/win32, m3-comm/posix) merged into one portable C file, and support IPv6...


 - Jay


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130206/dc0d0b49/attachment-0002.html>