Al Hoang

Colin Percival had this to say on security:

Schneier suggests that this “particular way of looking at the world” is very difficult to train — far more difficult than the domain expertise relevant to security. I respectfully differ: In my opinion, this mindset is not particular to security professionals; and universities have been successfully training people to hold this mindset for centuries.

…

the entire mid-term examination consisted of writing proofs; and a proof isn’t correct unless it considers all possible cases. Forgot to prove that a limit exists before computing what it must be? Your proof is wrong. Assumed that your continuous function was uniformly continuous? Your proof is wrong. Jumped from having proven that a function is continuous to assuming that it is differentiable? Your proof is wrong. Made even the slightest unwarranted assumption, even if what you ended up thinking that you had proved was true? Sorry, your proof is wrong.

…

More importantly than this, however, is that the sort of edge cases which mathematicians are trained to think about in writing a proof are exactly the sort which cause most security issues

Colin’s view is that the security mindset is one where you should be thinking with a analytical (in a mathematical sense) mindset when truly considering security. This is not something that is that simple to do on a continuous basis.

My understanding that I took away from the article is that one should expend a lot of effort upfront building up a proof that the security of your system is secure and implement it following the proof. This is definitely an ideal that one should work towards when trying to apply security. However, I feel some things in the ‘real world’ are so fuzzy that this can’t apply to all facets of security evenly. What to do then?

When it comes to writing software this might be more tractable. However, at the systems level where it usually means integrating a set of systems together how does that work? I guess choose completely secure components and make sure they are configured to work in a secure manner when communicating with one another when you have the choice is a good one. How about when you don’t have that choice?

This is a question I was asking myself after looking at some tweaks to a mysql server. I guess the more appropriate question that I wanted to ask was

Does setting the innodb_log_file_size parameter larger affect runtime performance?

A quick google led to the well known Mysql Performance Blog (highly recommended for understanding mysql internals and optimizations) which had this to say

If you’re doing significant amount of writes to Innodb tables decent size of innodb_log_file_size is important for MySQL Performance. However setting it too large will increase recovery time, so in case of MySQL crash or power failure…

…

First let me explain what happens on recovery and why large innodb_log_file_size slows down recovery…

So in general, no it doesn’t HURT performance but recovery time will take longer which is something to consider when trying to bring up a database that has crashed or trying to restore a database from a LVM snapshot that has not had the luxury of being able to have it cleanly shutdown.