The GBC experience

I just returned from the GBC 2008. Great fun and interesting stuff. Highly reinvigorating when you are in the midst of a lot of things. Some observations:

  • Matt Mullenweg rules!
  • So does Boris Veldhuijzen van Zanten, who by the way gave the most interesting presentation (Boris, Patrick thanks for the beers).
  • After all these years I finally met in person MarkP and GeorgeP. It is a pitty that we did not have much time to catch up. We will catch up next year.

There must be rivers of beer on Ios island…

Tribute to Honor Jim Gray

From DBWorld:

Tribute to Honor Jim Gray
May 31, 2008 @ UC Berkeley

http://www.eecs.berkeley.edu/IPRO/JimGrayTribute

Jim Gray’s family, friends and colleagues have arranged a public day of talks and reminiscences in his honor, to be held on May 31, 2008, at UC Berkeley. All are welcome.

Although Dr. Gray will be officially listed as missing until 2012, his family has asked that we have this Tribute now, to honor him before too much time has passed.

There are two parts to the Tribute. The General Session that begins the day is intended for the general public. The Technical Sessions will go through the afternoon, and are intended for a computer science audience. The organizers request that people wishing to attend the Technical Sessions register in advance on the web, to facilitate planning.

More information, including the program for the day, registration forms, and information on accommodations is available on the web at http://www.eecs.berkeley.edu/IPRO/JimGrayTribute. Questions about event logistics may be directed to jimgraytribute@eecs.berkeley.edu .

The search for Dr. Gray is detailed in Wired Magazine’s article: http://www.wired.com/techbiz/people/magazine/15-08/ff_jimgray

[via DBWorld @ 2007/12/4]

Η Java δεν είναι C…

– Στη Java πατάς την τελεία (.) και σου βγαίνουν οι επιλογές. Δεν είναι σαν τη C που πρέπει να τα γράφεις όλα με το χέρι.

Δεν κατακρίνω αυτόν που το είπε. Αυτοί που τον έμαθαν να σκέφτεται έτσι πρέπει να βρούν τρύπα να κρυφτούν.

The Power of 10: Rules for Developing Safety-Critical Code

Ο Gerard J. Holzmann του NASA/JPL δίνει 10 κανόνες, εύκολους να τους θυμάται κανείς, για τη συγγραφή safety critical code. Παρόλαυτά είναι καλό να τους θυμόμαστε και όταν γράφουμε “κανονικό” κώδικα. Κυρίως γιατί σε αντίθεση με άλλα standard, δεν είναι σελίδες επί σελίδων, άρα μπορούμε να τους θυμόμαστε εύκολα και δεν φτάνουν να κυβερνάνε ακόμα και την αισθητική του κώδικά μας (ή ακόμα και το πόσα “spaces” είναι το [TAB]). Οι 10 κανόνες είναι:

Adhering to a set of 10 verifiable coding rules can make the analysis of critical software components more reliable.

  1. Restrict all code to very simple control flow constructs—do not use goto statements, setjmp or longjmp constructs, or direct or indirect recursion.
  2. Give all loops a fixed upper bound. It must be trivially possible for a checking tool to prove statically that the loop cannot exceed a preset upper bound on the number of iterations. If a tool cannot prove the loop bound statically, the rule is considered violated.
  3. Do not use dynamic memory allocation after initialization.
  4. No function should be longer than what can be printed on a single sheet of paper in a standard format with one line per statement and one line per declaration. Typically, this means no more than about 60 lines of code per function.
  5. The code’s assertion density should average to minimally two assertions per function. Assertions must be used to check for anomalous conditions that should never happen in real-life executions. Assertions must be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken such as returning an error condition to the caller of the function that executes the failing assertion. Any assertion for which a static checking tool can prove that it can never fail or never hold violates this rule.
  6. Declare all data objects at the smallest possible level of scope.
  7. Each calling function must check the return value of nonvoid functions, and each called function must check the validity of all parameters provided by the caller.
  8. The use of the preprocessor must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed. All macros must expand into complete syntactic units. The use of conditional compilation directives must be kept to a minimum.
  9. The use of pointers must be restricted. Specifically, no more than one level of dereferencing should be used. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. Function pointers are not permitted.
  10. All code must be compiled, from the first day of development, with all compiler warnings enabled at the most pedantic setting available. All code must compile without warnings. All code must also be checked daily with at least one, but preferably more than one, strong static source code analyzer and should pass all analyses with zero warnings.

Όλο το άρθρο παρουσιάζει εξαιρετικό ενδιαφέρον και ειδικότερα η ανάλυση του σκεπτικού πίσω από τους εμπειρικούς αυτούς κανόνες.

[via The Power of 10: Rules for Developing Safety-Critical Code]

Μια ξεχασμένη(;) απόδειξη

Μετά από μια συζήτηση την Τρίτη για τους υπολογιστές και το δυαδικό σύστημα θυμήθηκα μια απόδειξη που μας είχαν κάνει στο ΕΜΠ για το ότι το δυαδικό δεν είναι το καλύτερο σύστημα αναπαράστασης της πληροφορίας και πως η επιλογή του ήταν περισσότερο τεχνοοικονομική. Ξέθαψα λοιπόν το βιβλίο της Αρχιτεκτονικής Υπολογιστών και να:

Έστω πως έχουμε ένα σύστημα που αναπαριστά την πληροφορία σε βάση R και με μέγεθος λέξης k. Τότε όλες οι δυνατές αναπαραστάσεις είναι Α = Rk, όπου για κάθε ψηφίο της λέξης υπάρχουν R σύμβολα.

Τότε λοιπόν χρειαζόμαστε Ε = kR σύμβολα για να αναπαραστήσουμε τα Rk string μήκους k. Για παράδειγμα για k = 8 και R = 2 χρειαζόμαστε Ε = 16 σύμβολα*, ενώ για k = 2 και R = 16 χρειαζόμαστε Ε = 32. (Παρατηρείστε πως στο παράδειγμα ισχύει πως 28 = 162 = 256).

Αναζητούμε λοιπόν τις συνθήκες εκείνες ώστε το kR να είναι minimum, ενώ ταυτόχρονα το Rk να είναι σταθερό:

Από το A = Rk έχουμε πως k = ln(A) / ln (R) το οποίο με βάση τη σχέση E = kR μας δίνει:

E = Rln(A) / ln(R)

Παραγωγίζοντας ως προς R βρίσκουμε πως το E ελαχιστοποιείται για R = e. Για να φανεί και οπτικά, για A = 28, 216 και 232:


[*] – Σκέψου τα σαν μαύρα και άσπρα πούλια του τάβλι. Χρειάζεσαι 8 μαύρα και 8 άσπρα για να μπορείς να παράγεις όλους τους συνδιασμούς.

Μια ευχάριστη έκπληξη

Πήγαμε με τη γυναίκα μου στο Ιασώ για μια εξέταση και ξαφνικά με την άκρη του ματιού μου είδα στην οθόνη της κοπέλας που συμπλήρωνε τα στοιχεία την εικόνα δεξιά:

Να μια συνέντευξη που πρέπει να κάνει κάποιος που θέλει να προάγει το ΕΛ/ΛΑΚ.

so long, and thanks for all the fish!

Two days ago Mark Crispin wrote in imap-protocol:

I was laid off today. Unfortunately, I didn’t get a change to push imap-2007b out the door in release status, but the development tarball there is pretty close to my final bits.

If you have support requests for UW imapd, please send them to the Alpine development team at UW, alpine-contact at u.washington.edu.

It has been a privilege to work with all of you for the past 20 years.

— Mark —

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Why on earth would anyone want to lay off Mark Crispin, is a mystery to me. As a long time user of the UW-IMAP toolkit I want to thank MRC for his work and software, which solved many of my problems and preserved much of my time.

cisco IOS rootkits

Στις παρουσιάσεις του EuSecWest βλέπω την ακόλουθη από τον Sebastian Muniz, exploit writer της Core Security Technologies:

“Killing the myth of Cisco IOS rootkits: DIK (Da Ios rootKit)

Public rootkit implementations for Cisco IOS have not been seen and system administrators tend to think that this is not possible or that even being possible, a generic method could not be created and that a skilled attacker is needed to target them. We will present DIK (Da Ios rootKit), a real multi-architecture rootkit to show that real threat exist and that advanced IOS forensics are probably not enought to detect it.

No public IOS rootkit implementation has been publicly presented before and the techniques employed here are generic and could be easiy usd to implement other closed-source OS rootkits.”

  1. Wow! Δεν είναι βέβαια η πρώτη φορά που το διαβάζει κανείς, π.χ. ήδη από το 2002 ο Rik Farrow έγραφε:

    “One rumor is that the source code for IOS, Cisco’s Internetworking Operating System, has been stolen. That rumor dovetails nicely with a second rumor, that a rootkit for Cisco routers is in the wild.
    :
    The notion of a Cisco rootkit disturbed me at first. I guess I just didn’t like to think of a router as something running a vulnerable OS with vulnerable services. But, of course, routers run operating systems. Cisco has written their own. Juniper Networks uses a modified version of BSD.”

    Έστω και μετά από τόσα χρόνια …wow!

  2. Ελπίζω να υπάρχει κανείς γνωστός που να του πλήρωσε ο εργοδότης τις £2100 (EuSecWest + The Exploit Laboratory) για να μεταφέρει αυτά που είδε.
  3. Θυμάμαι πως τον καιρό που δούλευα στο NTUA-NOC προσπαθούσα να βρω buffer overflow στον BGP listener των router. Ήταν φρέσκο το “Smashing the stack for fun and profit” τότε… Βέβαια εμένα με ενδιέφερε περισσότερο το denial of service (σαφώς πιο εύκολο) από το remote access ή ένα rootkit. Ο router-master υπολόγισε σωστά στον όγκο της καθημερινής εργασίας και αν και δεν ήθελε, μου έδωσε access για να “παίξω”. Χρειάζεται ελεύθερο χρόνο κανείς για να πειραματιστεί.
  4. Άντε να δούμε πότε θα αρχίσουμε να τρέχουμε third-party software στους router (online ή offline πάνω στο image δεν έχει σημασία)…

[via]

Workflow

Παρακολουθούσα μια διάλεξη για MIS όταν μου πέρασε από το μυαλό μου (όχι μια σφαίρα ρε!) η παρακάτω σκέψη:

“Workflow είναι η (ελλειπής) απεικόνιση της γραφειοκρατίας ενός οργανισμού σε ένα υπολογιστικό σύστημα”

Δεν ήμουνα σε φόρμα μάλλον…