Yeay - after a long while without any content on IT-insecurity.com I've just now restored the content in the newly installed OpenCms instance.
File systems nowadays support transactional writes, databases have transactions, entireprise software employs transactions - why aren't transactions embedded deeper in the computing systems? Operating systems could offer transactions for processes and network protocols could also use transactions for ensuring consistent communication states.
What am I trying to say? -I think that if we were to provide support for transactional aspects (commits, rollbacks, checkpoints, ...) at lower levels in the computing stack everyone else could use and build upon these mechanisms instead of having to make up their own at the higher levels.
For processes, it might work like checkpointing at a certain state and having the option to roll-back to the latest checkpoint (or to commit that one) - including the reversal of all modifications that have been done since the last checkpoint. This is why transactional support would need to be "everywhere" - because rolling back a process to a checkpoint might require the communications that have been sent out over the network to be also marked as reverted - here the network protocols would need to tie into the operating systems view of transactions.
Again, keep in mind that this is an idea - a place to start from, not a full concept. I might explore this further another time (or I might completely forget about it).
OK, so one point I realized after reading my entry just now is that my explanation of the string types wasn't all that clear, so here goes my second attempt (click here for the first segment).
Let's define that our imaginary CPU has 3 string types: one for strings up to 256 bytes (str1), one for strings up to 4096 bytes (str2)and one for strings up to 16MB (str3) - again, no real reason for these specific numbers. Instances of str1 would end-align on 256 byte memory boundaries; the last byte of a string of such type would always fall on an address with the last 8 bit being all set:
Unless there are designated memory regions for each string type, the correct interpretation of the strings data depends on the use of the correct/corresponding string type's processing instruction; if there were seperate memory regions, one could just simply use a single set of string instructions and the microcode would "know" what type of string it would operate on by looking the the memory location contained in the register for the instruction (all this assumes a register based cpu, unlike cpus that operate on data items on the stack). But, all this is fairly irrelevant as I am just trying to present an idea here and not a fully implementable system. I will address these issues in a future entry - so stay tuned.
Now, I know that strings are rather complex for CPUs to handle - it's that they aren't fixatable in terms of memory requirements and that just ruins it for chip makers. All native CPU datatypes (if you wanna call them that) have a well-known size - for example: the %ah and %al registers on IA32 are 8bit each, the %ax is 16bit (it's actually %ah and %al combined) and %eax is 32bit and a pointer into memory is also 32bit. Now, strings are variable in size, meaning that their memory requirements depend on their actual value (on their length) and this is a stark contrast to those other types. Currently, (all the) CPUs (I know of) use C-style strings in that the CPU offers certain instructions that operate on a register which points to a memory location which in turn is interpreted as the start of the destined string. The CPU processes whatever string instruction by interpreting the memory node's content (node == byte for this matter) and either processes it and continues with the next memory node or it has determined that this must be the end-marker of the string (if the value of the memory node is 0).
Now, there are these problems with this approach:
The idea that crossed my mind recently was to essentially keep the idea of having a register whose content identifies the location of the string in memory, but to add information about the length of the string and the (newly created) string type to the mix. The first idea is that since values on CPUs have a bounding limits (ie: 8bit = 256, 16bit=65536, ...) in term of how many values they can represent (nonwithstanding signed/unsigned interpretations), why shouldn't the same concept apply to strings. Make a string "type" that can contain a maximum length of let's say 256 bytes (just pulling this number out of thin air) and other types for strings up lengths of 4M and 4G or whatever. The benefit of this approach is that one can definitely determine the memory size that each type needs and therefore the runtime of processing instructions for these types have a well-known upper bound.
You may ask now that there's no way just yet to actually determine the length of any instance of such a string - here's the clever part: let the strings be "end"-adjusted and let the register point to the memory address where the first byte of the string is. To give an example:
Hmm, I am getting distracted with work - so I will continues to write about this some other time.
Update: here's the second part
Ich würde als Session eine "freie" Runde über Computersicherheit leiten. Thema und Art der Session können vollkommen frei von den Anwesenden bestimmt werden - ich werde dann entsprechend auf die Fragen/Themen eingehen. Ziel soll sein, dass die Anwesenden Fragen zu Themen stellen können, die Sie bzgl. IT-Sicherheit haben (und so hoffe ich, dann auch eine qualifizierte und verständliche Antwort bekommen).
Welche Aspekte angesprochen werden ist von meiner Seite aus nicht vorgegeben. Meine Schwerpunkte liegen in der technischen Sicherheit, eher weniger in der "formalen" Sicherheit. Will sagen: ich kenne weder die SOX Regulierungen noch ISO27001 auswendig (kenne diese aber auch), dafür kann ich aber ad-hoc tiefgreifend auf verschiedenste technische Themen eingehen.
Mögliche Themen könnten also sein (nur um ein paar Themen genannt zu haben):
