1918 Reform Act: It Wasn’t Just Women

 Politics  No Responses »
Feb 062018
 

About 100 years ago (being somewhat pessimistic about how long it will take me to write this), the Representation of the People Act was passed. Understandably enough, there’s been a whole bunch of comments regarding women getting the vote; and it was certainly a significant reform because of that.

But you have to hunt long and hard to realise that it also enshrined the one man, at least one vote principle (some University graduates could vote twice). Due to the previous property qualification, before 1918 only 60% of men could vote.

Which is almost as significant as giving women the vote.

Women got the same rights as men 10 years later in the 1928 Representation of the People Act.

The Bare Family

Mounting Filesystems “Late”

 Computing, Linux  No Responses »
Feb 022018
 

On occasions, I have run into issues where mounting a filesystem from /etc/fstab fails on a reboot because it depends on something else happening first. The easiest example to recall is when mounting a conventional filesystem constructed from a ZPool block device – the block device isn’t ready until ZFS has finished starting which often occurs after the filesystem mounts are attempted.

The fix is dead simple; just add the option “_netdev” to the options field in /etc/fstab and the problem is sorted :-

/dev/zvol/pool1/vol-splunk      /opt/splunk     ext2    noatime,_netdev         0 2

Yes the reason I am using a block device is that Splunk doesn’t support being installed on a ZFS filesystem.

Python: Not As Simple As BASIC?

 Computing  No Responses »
Jan 292018
 

I recently dived into the rabbit hole of educational computers and came across a site which made a big song and dance about how Python is a great deal more complicated than BASIC. Well that is perhaps arguably correct, but the comparison they made was grossly unfair :-

#!/usr/bin/env python
#-*- coding: UTF-8 -*-

from random import randint
from time import sleep
import sys

string = "Hello World!"
while true:
  attr = str(randint(30,48))
  out = "\x1b[%sm%s\x1b[0m" % (attr, string)
  sys.stdout.write(out)
  sys.stdout.flush()

  sleep(1)

Now for the criticisms :-

  1. The first line (“#!/usr/bin/env …”) is nothing to do with Python; and in fact a BASIC program should also include this if it wants to run in the same way as a Python program under Linux. The “#!” is in fact a directive to the Linux kernel to tell it what script to pass the rest of the file through.
  2. The second line (“# -*-…”) also has nothing to do with Python; it is a directive to an editor to tell it to use the UTF-8 character set. Why doesn’t the basic equivalent also include this?
  3. Now onto the Python itself … first of all there are a whole bunch of imports which are done in the verbose way just so that you can call sleep rather than time.sleep; I generally prefer the later (which would result in the import time rather than from time import sleep). But yes, in Python you have to import lots of stuff to get anything done, and it would be helpful for quick and dirty scripts if you could just import lots to get a fair amount of ordinary stuff loaded.
  4. The rest of the code is … um … obviously designed to make Python look bad and glossing over the fact that Python runs in the Linux runtime environment whereas the BASIC equivalent does not – it has a BASIC runtime environment.

That last point is worth going into more detail on – the BASIC code was written for a BASIC runtime environment, and one method of sending output to the screen. Linux has many ways of writing to the screen, and the chosen method above is perhaps historically the worst (it only works for devices that understand the escape sequences; there is a curses library for doing this properly).

So is Python unsuited to a quick and easy learning environment? A quick hackers language? As it is, perhaps not, but that is not quite what Python is designed to be. And with a suitable set of modules, Python could be suitable :-

import lots

white True:
  screen.ink(random.choice(inkcolours))
  screen.paper(random.choice(papercolours))
  screen.print("Hello World!")

  time.sleep(1)

(That’s entirely hypothetical of course as there is no “screen” module)

I’m not qualified to judge whether BASIC or Python are better languages for beginners – I’ve been programming for around 35 years, and the BASIC I remember was very primitive. But at least when you compare the two languages, make the comparison a fair one.

All Your Processors Belong To Us: Meltdown and Spectre

 Computing, Security  No Responses »
Jan 042018
 

Well, there’s another big and bad security vulnerability; actually there are three. These are known as Meltdown and Spectre (two different Spectres). There are all sorts of bits of information and misinformation out there at the moment and this posting will be no different.

In short, nobody but those involved in the vulnerability research or implementing work-arounds within the wel-known operating systems really knows these vulnerabilities well enough to say anything about them with complete accuracy.

The problem is that both vulnerabilities are exceptionally technical and require detailed knowledge of technicalities that most people are not familiar with. Even people who work in the IT industry.

Having said that I’m not likely to be 100% accurate, let’s dive in …

What Is Vulnerable?

For Meltdown, every modern Intel processor is vulnerable; in fact the only processors from Intel that are not vulnerable are only likely to be encountered in retro-computing. Processors from AMD and ARM are probably not vulnerable, although it is possible to configure at least one AMD processor in such a way that it becomes vulnerable.

It appears that that more processors are likely to be vulnerable to the Spectre vulnerabilities. Exactly what is vulnerable is a bit of work to assess, and people are concentrating on the Meltdown vulnerability as it is more serious (although Spectre is itself serious enough to qualify for a catchy code name).

What Is The Fix?

Replace the processor. But wait until fixed ones have been produced.

However there is a work-around for the Meltdown vulnerability, which is an operating system patch (to fix the operating system) and a firmware patch (to fix the UEFI environment). All of the patches “fix” the problem by removing kernel memory from the user memory map, which stops user processes exploiting Meltdown to read kernel memory.

Unfortunately there is a performance hit with this fix; every time you call the operating system (actually the kernel) to perform something, the memory map needs to be loaded with the kernel maps and re-loaded with the old map when the routine exits.

This “costs” between 5% and 30% when performing system calls. With very modern processors the performance hit will be consistently 5% and with older processors the hit will be consistently 30%.

Having said that, this only happens when calling the operating system kernel, and many applications may very well make relatively few kernel operating system calls in which case the performance hit will be barely noticeable. Nobody is entirely sure what the performance hit will be for real world use, but the best guesses say that most desktop applications will be fine with occasional exceptions (and the web browser is likely to be one); the big performance hit will be on the server.

How Serious Are They?

Meltdown is very serious not only because it allows a user process to read privileged data, but because it allows an attacker to effectively remove a standard attack mitigation which makes many older-style attacks impracticable. Essentially it make older-style attacks practicable again.

Although Spectre is still serious, it may be less so than Meltdown because an attacker needs to be able to control some data that the victim process uses to indulge in some speculative execution. In the case of browsers (for example) this is relatively easy, but in general it is not so easy.

It is also easier to fix and/or protect against on an individual application basis – expect browser patches shortly.

Some Technicalities

Within this section I will attempt to explain some of the technical aspects of the vulnerabilities. By all means skip to the summary if you wish.

The Processor?

Normally security vulnerabilities are found within software – the operating system, or a ‘layered product’ – something installed on top of the operating system such as an application, a helper application, or a run-time environment.

Less often we hear of vulnerabilities that involve hardware in some sense – requiring firmware updates to either the system itself, graphics cards, or network cards.

Similar to firmware updates, it is possible for microcode updates to fix problems with the processor’s instructions.

Unfortunately these vulnerabilities are not found within the processor instructions, but in the way that the processor executes those instructions. And no microcode update can fix this problem (although it is possible to weaken the side-channel attack by making the cache instructions execute in a fixed time).

Essentially the processor hardware needs to be re-designed and new processors released to fix this problem – you need a new processor. The patches for Meltdown and Spectre – both the ones available today, and those available in the future – are strictly speaking workarounds.

The Kernel and Address Space

Meldown specifically targets the kernel and the kernel’s memory. But what is the kernel?

It is a quite common term in the Linux community, but every single mainstream has the same split between kernel mode and user mode. Kernel mode has privileged access to the hardware whereas user mode is prevented from accessing the hardware and indeed the memory of any other user process running. It would be easy to think of this as the operating system and user applications, but that would be technically incorrect.

Whilst the kernel is the operating system, plenty of software that runs in user mode is also part of the operating system. But the over-simplification will do because it contains a useful element of the truth.

Amongst other things the kernel address space contains many secrets that user mode software should not have access to. So why is the kernel mode address space overlaid upon the user mode address space?

One of the jobs that the kernel does when it starts a user mode process, is give to that process a virtual view of the processor’s memory that entirely fills the processor’s memory addressing capability – even if that it is more memory than the machine contains. The reasons for this can be ignored for the moment.

If real memory is allocated to a user process, it can be seen and used by that process and no other.

For performance reasons, the kernel includes it’s own memory within each user process (but protected). It isn’t necessary, but re-programming the memory management unit to map the kernel memory for each system call is slower than not. And after all, memory protection should stop user processes reading kernel memory directly.

That is of course unless memory protection is broken …

Speculative Execution

Computer memory is much slower than modern processors which is why we have cache memory – indeed multiple levels of cache memory. To improve performance processors have long been doing things that come under the umbrella of ‘speculative execution’.

If for example we have the following sample of pseudo-code :-

load variable A from memory location A-in-memory

if A is zero

then

  do one thing

else

  do another

endif


Because memory is so slow, a processor running this code could stop whilst it is waiting for the memory location to be read. This is how processors of old worked, and is often how processor execution is taught - the next step starts getting really weird.


However it could also execute the code assuming that A will be zero (or not, or even both), so it has the results ready for once the memory has been read. Now there are some obvious limitations to this - the processor can't turn your screen green assuming that A is zero, but it can sometimes get some useful work done.


The problem (with both Meltdown and Spectre) is that speculative execution seems to bypass the various forms of memory protection. Now whilst the speculative results are ignored once the memory is properly read, and the memory protection kicks in, there is a side-channel attack that allows some of the details of the speculative results to be sniffed by an attacker.


 


Summary


    

  1. Don't panic! These attacks are not currently in use and because of the complexity it will take some time for the attacks to appear in the wild.
    2. 

  2. Intel processors are vulnerable to Meltdown, and will need a patch to apply a work-around. Apply the patch as soon as it comes out even if it hurts performance.
    3. 

  3. The performance hit is likely to be significant only on a small set of applications, and in general only significant on a macro-scale - if you run as many servers as Google, you will have to buy more servers soon.
    4. 

  4. Things are a little more vague with Spectre, but it seems likely that individual applications will need to be patched to remove their vulnerability. Expect more patches.
    5. 



Tunnel To The Old Town


 


 

The US and The UN: The Vote Against The US

 Politics  No Responses »
Dec 242017
 

The behaviour of the US during the last week has been exceptionally dysfunctional and indeed puts it alongside rogue states. For those tuning in late, the US has recently announced that it is moving its embassy to Israel from Tel Aviv to Jerusalem. Now there are all sorts of reasons why this is a dumb move and incredibly provocative in a part of the world that does not need any more provocation.

But here we are looking at the US and the UN rather than the move itself (however dumb it was).

The UN decided to call for a resolution that in effect says “We think this is a dumb move.” and the US reaction has been more or less along the lines of what you would expect a spoiled brat and a bully to react like.

Before the vote, the US spokesperson was grumbling about how its friends shouldn’t countenance such a resolution, that those who receive US aid should be careful, and how dare the UN put forward such a resolution when the US pays for the UN (hint: it doesn’t).

And afterwards, the US announces a party for its friends, and that nobody who voted in favour of the resolution was invited. So there!

Just like a spoiled child.

First of all, organisations like the UN need to be funded or they don’t exist. And the way that the UN is funded is based on every member’s ability to pay except that there is a ceiling on each individual’s level because the US threw a tantrum a while back. The US pays approximately 22% of the UN’s budget, so about $2 billion which is considerably less than the cumulative total of the countries that make up the EU (a roughly comparably sized block) which pays approximately 27% of the budget ($2.5 billion).

And a big chunk of that UN budget is spent within the US because the UN headquarters are in New York.

Frankly some of us are a little tired of hearing the US whinging about how much it pays.

Secondly the UN is there to do lots of things, but one of the most important is to allow countries collectively and formally tell another country that it is doing something dumb – and if a resolution passes with 129 countries voting for it, you can be pretty sure you’ve done something dumb. Sure that you are right despite that many votes against you? That’s a sign of overweening arrogance.

Threatening (“We’ll remember who are friends are”) people to vote in your favour is dangerous in the extreme. People remember bullies and the stench of it remains for a very long time.

 Older Entries  Newer Entries