Friday, November 4, 2016

Alive and kicking!

Hey everyone, Fanatik is back!

Tuesday, March 24, 2015

Awesome presentation on good API design video

Go watch the video How To Design A Good API and Why it Matters. It's awesome. Well worth the 1 hour of your time. Boy that guy is good. Also, he must be reading my mind or something.

Monday, November 12, 2012

Modules in C/C++?

It looks like there is again a proposal to standardize modules in C++. This would be very nice if successful. While I don't care that much about C++, it has been the trend lately that ISO C picks up useful C++ features (e.g. threads). So who knows, maybe, maybe we could finally get modules in C, after 40 years? Pretty please?

Thursday, May 17, 2012

On Limits

Past experience has shown that for any number N, and for almost any object O, the statement "we'll never need more than N of O" is invariably untrue.
Casper Dik

Thursday, May 10, 2012

Assessment of Stepan Henek's thesis Security containers and access rights in HelenOS

  • no justification why kernel must be modified to cache the tickets being used by a task
  • does not properly analyse UNIX file permission model and how it allows delegation of administration - no discussion of who and when can change owner and mode, s{u|g}id, sticky bit
  • interestingly there is actually no proposal for security containers in HelenOS
  • many types of tickets - it's not clear whether they are useful for anything and how one would choose among them
  • no real analysis/discussion of how the file permissions should be implemented and how it would (dis)allow common tasks such as sharing files, giving away files, (not) enforce users to follow some administrator-given rules for setting file permissions, etc.
  • it claims administration can be delegated thanks to the permissions on the individual RBAC virtual folders, but that's not true, these are too low-level and any useful permission given away will necessarily lead to privilege escalation (or at least no (counter)example is presented)
  • in the implementation, environment variables are introduced and used (without thought) for the sake of determining the default OGID for newly created files
some more thoughts/ideas:
  • not only that the almighty administrator cannot delegate his privileges, an ordinary user cannot delegate his privileges either (just like in UNIX) - no hierarchical principals
  • no way to enforce or even suggest permissions for files/directories under a subtree (cf. default ACLs)
  • single OGID for a file might be inflexible, especially if object groups can only be created/permissions set by the almighty administrator
In summary, the proposal:
  • might make it slishtly easier for an admin to assign permissions to a user
  • does not seem to allow any better delegation than the standard UNIX model
  • does not make proper analysis of what the model actually allows/ensures w.r.t operations on files and directories
  • introduces a new type of kernel resource with no obvious return value
  • makes it necessary to make a system call which queries the tickets (i.e. communicates with) a foreign task for any authorization operation, making it a communication-intesive operation (despite that IPC as such is not used)
Back to the drawing board, I say!

Sunday, January 29, 2012

Wednesday, November 23, 2011

TCP... the truth will be revealed

I have long before recognized that the current network stack in HelenOS is messed up beyond repair and trying to fix it anymore is a waste of time. Since it's been two years after the master thesis was defended and we still do not have something that would work, it might not be well received by others if I threw everything out and started from zero, though.

So I started with a complete rewrite of TCP. This is arguably the only more complex / non-trivial module in the stack and the part that is obviously most broken.

Despite lack of spare time I have now a new TCP module that is not 100% complete, but complete enough so that it could be test-run against itself over the wire. I implemented it as a completely independent server that has nothing in common with the current networking stack. I tested the functionality using internal loopback in the TCP module and internal clients.

Yesterday I started hooking it into the current network stack, the idea is to create a minimal connector between the two components. After three hours of work there is still some way to go before I can successfully send/receive PDUs to/from IP (I haven't started with the socket interface yet).

During this work I had the chance to fully 'appreciate' the quirks and complexities of the network stack. IP understands sockets and TCP pseudo headers. TCP knows about IP headers and network devices. But who cares about layers or separation of concerns, right?

Since quite a few people claimed that the remainder of the network stack actually works -- to some degree -- I wonder whether I get something at least remotely useful when I plug my TCP implementation into the stack. The truth will be revealed. And then I can maybe throw the rest of the rubbish out.