Archive for the ‘Computers’ Category

Weather Underground’s security issue

May 1, 2016
Malware download page

Image of the malware download page

I will often use the Weather Underground website to check the forecast, but I may start using the National Weather Service’s site instead. If I leave a tab on my web browser at work on the Weather Underground site, the image in this post will eventually result. The browser is an up-to-date Firefox without Adobe Flash running on Windows 7. It gets redirected to another website, always with a different domain name, and always with two seemingly random numbers in the path (visible in the image when large enough). The page looks like it is for downloading Adobe Flash, but isn’t on Adobe’s website. It sure stinks of malware. It may be coming from something like an advertisement that can sneak a redirection into the web page rather than content generated by Weather Underground, or maybe they have a more direct breach of security. Either way, I’m sure Weather Underground wouldn’t do this, but it is still annoying.

The issue has occurred five times over more than a month, maybe two, on the same computer. I did attempt to inform them of the issue, but I haven’t seen any indication that anyone took it seriously. It has happened twice since then.

At home, I run Firefox on Linux and do have Flash installed, although I usually have it disabled. The issue never happens there. I haven’t yet tried on another system without Flash, but suspect that may trigger the redirection.

What this doesn’t answer is what happens when this malware could redirect a browser, but finds one with Flash installed and enabled instead. I also didn’t accept this download. I’m not employed to do security research, and the IT department is quite distant.

Boost C++ library and the end of the world

November 8, 2015

While working on some C++ code, I made a mistake and got this error:

ERROR: Throw location unknown (consider using BOOST_THROW_EXCEPTION)
Dynamic exception type: boost::exception_detail::clone_impl
<boost::exception_detail::error_info_injector<boost::gregorian::bad_year> >
std::exception::what: Year is out of valid range: 1400..10000

I find two things rather interesting here. The first is that the Boost date_time library isn’t using the Boost exception library. The second is that the date_time library has defined the year 10000 as the last in the Gregorian calendar.

Based on this, I predict that the end of the year 10000 will be the end of the world. Using the Boost libraries to make end-of-the-world predictions should work about as well as using the Bible, right? The end is nigh!

XPS 13 Developer Edition (2015): Rushed

July 29, 2015

Dell’s XPS 13 Developer Edition from 2015 has some nice hardware, but it was rushed to market. The machine isn’t usable as delivered. Either no QA testing was done, or an impossible deadline was imposed. I’m pretty sure it was a deadline. It took the managers a while to realize this is a problem, but they finally decided to act by no longer selling it until they fix it. Someone with basic Linux sysadmin skills and some time to install the various fixes can get it working quite well so long as they aren’t a fast typist; key repeats are only mostly fixed as of now. With the fixes, I find it can still fail to resume from suspend, but it doesn’t happen often and leaves nothing logged to indicate the problem. Overall, I like the machine more than I should.

I went for a model with the 1920×1080 display and no touchscreen because I don’t like glossy displays. I do like resolution, and this is plenty for the small size. I’ll be using font anti-aliasing for a while longer; probably could turn that off with the higher resolution model.

Dell shipped it in a cardboard shipping box that distinguished itself by including a plastic handle so it can be carried around like a briefcase. Inside that is the power supply and cable, and a black box. A very nice looking black box. Inside that is the XPS 13 with foam above and a plastic tray below that is very well fitted. Clearly a lot of though went into this, more than I have managed to convey. Underneath the computer is a folded paper on using MS Windows. I know the Developer Edition uses the same hardware as the XPS 13 with Windows pre-installed, but I didn’t expect it would include the same, but useless, documentation. Not a big deal, but maybe a harbinger.

When turned on, the XPS 13 quickly boots and brings up a legal document. Fun stuff. After a short delay, although long enough that I thought it would let me read the document, a video starts playing full-screen. The video cannot be stopped, and trying to switch away doesn’t work. Alt-tab brings up the window switching menu, but it doesn’t switch. I also couldn’t mute the audio or change the volume; I’m used to pressing two keys to get the functions like volume control, but only one was required. I eventually figured that out, but it did make the compulsory video rather annoying. What made it obnoxious was that it was just an animation of logos zooming about put to music that meant nothing.

With the video done, I got back to reading the legalese. I needed to scroll the text, so I got to use the mouse. It occasionally quit working for two seconds or so before accepting more input. There is a fix for this from Dell, but not on the part of their website for supporting purchased products. That is, if you were to purchase a XPS 13 Developer Edition, log into your account on Dell’s site, find the item you bought, and try to download fixes, then you won’t find them. The fixes are on Dell’s website, just not there. It is apparently reserved for Windows related fixes and system firmware, aka BIOS. A search engine is the best way to find the Developer Edition fixes. Once applied, the mouse no longer ignores input, but occasionally when trying to scroll with it, the system will respond like alt-tab is down and cycles through the windows super fast. I have no idea how to reproduce the issue. It hasn’t happened in the last couple of weeks, but I’m not sure it won’t happen again.

Soon after that, I got to try typing. It regularly repeated key inputs until another key was pressed. This didn’t take fast typing to observe. A BIOS update mostly corrects it, but people who type really fast report that the change only mitigates the problem. The issue affects Windows as well. Considering that keyboards are common computer hardware that have generally worked well for decades, and that Dell botched it in 2015, it is amazing the rest of the hardware came out as well as it did. The group within Dell that put Ubuntu Linux on the XPS 13 clearly had a hard time dealing with this hardware.

After this, it was time to update the installed software. The Ubuntu Software Updater ran until it got to grub, then seemed to hang on the update while still responding to user input. After waiting half an hour, I killed it and what seemed to be a related process that was eating processor time. Then I used apt-get from a shell and ran whatever command it told me to run when it complained about some problem. Since then, updates have worked correctly. I have to wonder if an uncorrected hung update would render the system unbootable.

Following that, the system needed updates for the graphics to resume reliably from suspend. I still have an occasional issue with it, but matters greatly improved. A remaining issue is how the screen brightness automatically adjusts: it darkens for a mostly dark frame, brightens for a bright frame, and offers no user configurability at all. I was worried this would be an issue for working with photographs, but the screen’s limited color gamut, at least compared to another display I have, has proven a much bigger issue. I just have to learn to avoid over saturating the color.

Other than that is an occasional crash for no apparent reason. I’ve had it happen shortly after booting the computer and starting to browse the web. It was occurring twice a week, but hasn’t happened in a couple weeks or so; maybe something was fixed.

The XPS 13 Developer Edition was in no condition to ship. Asus did a much better job with their Eee PC line; they might have been limited by their Linux distribution, but they worked fine right out of the box. Still, I’d rather not buy a computer with Windows pre-installed, and I like that Dell is going through some effort to support Linux, including getting patches into the mainline kernel to improve hardware support. I’m guessing the XPS 13 issues were unexpectedly time consuming to fix and management didn’t want to wait.

Long commands on Windows with SCons

January 15, 2015

At my job, where one of my tasks is to handle builds for Windows software using SCons, I recently moved from using SCons 1.2 with some custom modifications to an unmodified SCons 2.3.4. The change comes along with a move to using a newer Visual Studio while still supporting builds with an older one. The newer SCons has trouble with issuing some commands, just like the older version. Neither version can run programs that have whitespace in their path if the entire command is longer than some threshold. The custom modifications I made were to correct the problem, but this time I wanted something less custom and easier to support. Here is a link to the solution I developed; read on for the details.

With shorter commands, SCons issues the commands about the same way it does on Linux, and it works fine. Longer commands run into trouble on Windows; I’m told it has to do with the C runtime libraries. SCons works around this by placing most of a long command into a temporary file and then passing the name of the file preceded by a ‘@’ character as the first command line argument. Microsoft’s compiler and linker will read the temporary file for their arguments.

The implementation of this has a flaw that makes it useless using default installations of Visual Studio. SCons first puts together the command line as though no special long command handling is required. If the result is too long, the command is modified to use a temporary file but is parsed incorrectly; the program to run is taken to be all the characters up to the first whitespace. This makes the command to run “C:\Program”, which isn’t a program, or even an existent path. Everything after the first whitespace is put into the temporary file. It may start with “Files (x86)\Microsoft Visual Studio 10.0\VC\bin\cl.exe”, for example.

I found an attempt at getting SCons to use long commands written by Phil Martin. He provided SCons with a different way to spawn processes. Unfortunately, it doesn’t handle the whitespace issue. By the time the spawn function is called, SCons has already modified the command to use the temporary file. Nevertheless, his implementation was a good place to start. Like his implementation, mine also requires PyWin32.

I modified it to detect the use of a temporary file. When used, the spawn function opens and reads the temporary file to rebuild the complete command line. Then it figures out the whole path to the program, including whitespace, and separates that from the arguments. I also made a modification to produce better error messages from CreateProcess().

Finding the path to the program works best when there is some delimiter in the program path. It is common on Windows to enclose paths that have whitespace with double quotes. The command constructed by SCons using the default program paths lack this delimiter. I solved this by supplying new complete paths for all programs used in Microsoft’s toolchain. It is quite a bother, but I did it the best and most complete way I could figure. This includes creating some build configuration options for several paths, and making two build environments: one for x86 targets and another for amd64 targets.

Hopefully this will help someone else. I really don’t understand why this bug has been around for so long considering that whitespace in paths on Windows is very common.

Personal Cloud

July 13, 2014

dearazure_banner_evel_728x90_V2

A cloud so personal, it senselessly gathers your intimate details that it doesn’t need.

Replacement I2C kernel module for Raspbian

January 8, 2014

A while ago, I got I2C repeated starts and SMBus support to work from the Linux kernel on a Raspberry Pi. I recently built a new 3.10.25 kernel from the foundation’s kernel fork on Github and updated my own fork of their fork with just the I2C update in a new branch. In the process, I managed to misuse git so that commits now attempt to go to the Raspberry Pi Foundation’s kernel fork rather than my own. I tested the module on the copy of Raspbian that I have. It is running the 3.10.24 kernel, but is quite happy with the new kernel module (or for 3.10.37, or 3.12.24) and my MLX90614 test program. I also built the kernel module for the BMP085, but it looks like that requires more than just a kernel module file to get it working. No big deal for me; I’ll just replace the whole kernel.  I just wanted to see if I could make it really easy for someone else.

To use the updated I2C module, first download it. The file will need to replace the one in /lib/modules/<kernel version>/kernel/drivers/i2c/busses. You may want to keep a copy of what is already there. After copying it, check to see if the i2c-bcm2708 module is loaded. If not, load it up and have fun! If it is, you can either reboot or unload the i2c-bcm2708 kernel module. Before unloading will work, any dependent modules must first be unloaded. It wasn’t loaded for me right after boot, so it hopefully won’t be any trouble.

Update: I finally got the code up on Github. I hope the kernel module has been working out for anyone who has tried it. Please do leave a comment about any success or failures with it. I have yet to get any feedback, so I only have my own test case to claim that it works.

Adafruit’s Puft Cloud

September 9, 2013

There is a nice post on the Adafruit blog about the networks of stuff. It features this wonderful picture:

Adafruit's Puft Cloud

Adafruit’s puft cloud grabs hold of everything

A very happy looking cloud is grabbing everything in sight. It seems like the artist tried to think of the most harmless thing; something that could never possibly destroy us. The post is a short summary of a way to tame the puft cloud put forth by Limor Fried. There is also a Google+ page for it. The basic notion is to keep things open so that what is collected is known and how it is used can be limited and controlled by users. Given how companies love to keep everything proprietary, we may be doomed. But, maybe after a few more incidents like the Samsung Smartly-taking-away-your-privacy-through-security-flaws TV, companies might finally get the idea when users demand security they can verify. If no one outside the originating company can verify their device’s security, it is only a short matter of time until someone outside that company verifies the device’s lack of security. Such lacking security of a device used in the presumed  privacy of one’s home is a problem most people would rather not have, but a few will want to profit from.

I2C repeated starts implemented on the Raspberry Pi

July 13, 2013

Update: If you just want a kernel module for something close to kernel version 3.10.25, look here.

I’m working on a project that uses the Raspberry Pi and various sensors. One sensor is a MLX90614 IR thermometer; this communicates using SMBus. One of my goals is to avoid making the project specific to the target hardware, the hardware that actually runs my code. I want the code that communicates with the sensors to be Linux specific but not Raspberry Pi specific.

Communication with a MLX90614

Communication with a MLX90614

One of the problems a lot of people have had with the Raspberry Pi is with getting SMBus communication to work. SMBus is built on I2C, a way of managing serial communication between many devices with only two wires: clock and data. I2C is more flexible, while SMBus is made to be more reliable. As part of guaranteeing reliability, mostly in a multi-master setup, SMBus requires the use of I2C’s repeated starts for read operations. The I2C master driver for Linux on the Raspberry Pi does not support this, and I have been unable to find a patch or custom version anywhere that adds support. Most people have solved the problem by using code that directly interfaces with the Raspberry Pi’s hardware, ignoring the Linux kernel support altogether. This solution not only fails to meet my goal of avoiding code specific to the target hardware, it also won’t work well if more than one process on the same host attempts to use the I2c master hardware.

I decided to solve the problem by modifying the Linux kernel’s support for the I2C master of the Raspberry Pi. I succeeded. My implementation may not be the best or bug free (works for me is a weak guarantee), but it does allow for communication with a MLX90614 using the user-space (unprivileged code outside the kernel) SMBus interface provided by Linux. Since examples with SMBus are more difficult to find than I2C, here is my test code. I also tested with a BMP085 sensor using the support for it already in Linux. This sensor uses I2C rather than SMBus, and it also functions correctly. It doesn’t need a repeated start, but it gets one anyway.

To avoid causing extra trouble, I implemented repeated starts for a subset of conditions under which they could be valid. I focused on SMBus communication. With I2C, a slew of messages going back and forth can be requested, all with repeated starts, but this isn’t normally done or required.  Also, the hardware requires that once the first message has begun transmission, the second message be setup in the registers ahead of the stop condition. To make matters worse, there is no interrupt condition for this, so polling in a busy wait is required. I stuck all this inside the bcm2708_i2c_master_xfer() function of i2c-bcm2708.c so it isn’t in the interrupt handler. After the second message is configured, the interrupt handler is used to receive the data. That avoids additional polling at the cost of not allowing additional repeated starts.

If you’d rather see the kernel change in source control, I stuck it on Github. It is a 3.6.11 kernel, but not the latest revision out there. I’m still using it for now. There is no kernel or kernel module for download here because I’m running Gentoo on my Raspberry Pi and I build my own kernels. If I gave you my kernel, you may well find that something doesn’t work anymore.

Raspberry Pi + Linux Interrupt Latency: 10μs

March 1, 2013

I decided I wanted to use a capacitive relative humidity sensor in a project with a Raspberry Pi, but that meant timing the charing or discharging of the sensor in an RC circuit. These things don’t have much capacitance, and the data sheet suggests it might not give good results under 1kHz. That makes it look like it’ll need microsecond timing at least to provide usable data.

I first tried making two consecutive calls to clock_gettime() and found that it takes between 2 to 5μs to complete one call on an otherwise idle Raspberry Pi. This wasn’t good enough, so I figured I’d dip into the kernel to see what could be done. The impact of scheduling processes and context switches should be minimized by solving the problem in the kernel. Thus far, this is the most involved attempt I’ve made at messing with the Linux kernel. The result was a bit messy, but I got it working. If you want a peek, its on Github.

I modified the code in bcm2708_gpio.c to record the time from a free-running timer whenever the output of a GPIO was changed, or an input state change triggered an interrupt. After managing to get the code to do about what I intended (sysfs has an extra directory level that I haven’t figured out), I connected two GPIO lines together, set one to be an input and one an output, and set the edge of the input to falling. There is nothing special about the falling edge for this test, but the edge had to be set to trigger the interrupt. Then I set the output to one, then zero, and checked the results.

I found that the timing showed 10 to 11μs would elapse between the output state change and running the GPIO interrupt handler when an X server is also running. Without X, I saw a latency of just under 9μs. The timer was configured to increment once every 4ns, so its precision should be more than adequate for these results. I suppose I could have added a significant digit. I’m surprised the times were so high; given the times on the consecutive calls to clock_gettime(), I was hoping for something better.

I know there are people who will blame Linux for the poor result, but this result is the system timing itself; it includes the hardware. What I saw in the BCM2835 documentation seemed to suggest the processor has an interrupt vector table with one entry, just like Microchip’s PIC16F84, an old 8-bit microcontroller. If so, that would suggest something else causes so much latency that there wasn’t a point in having a larger interrupt table. Even some of Atmel’s AVR 8-bit microcontrollers, like the ATtiny25, have several entries, so it isn’t expensive to do.

While BCM2835 offers poor interrupt response times, it does have nice graphics, runs Linux, and can run all the development tools needed for all this messing around in the kernel. No microcontroller is going to do that, unless it is part of a Rube Goldberg machine. I did build the kernel on my AMD64 deskunder computer, though. It’s much faster.

My biggest surprise doing all this is that it is possible to cause a segmentation fault in the kernel and not crash a single process. Do it a few times, though, and it might crash something. It logged me out once.

Programming Mistakes: The “OnOff” Flag

December 10, 2012

Lets suppose that you’re writing a program that controls whether something is either on or off. You’ve got a boolean variable or a bit flag value to control the state of this gizmo. You might be tempted to call it something like “gizmoOnOff”. Don’t do that; it’ll make your code look stupid.

For an example as to why you shouldn’t, I’m going to use C for the programming language and define a bit flag. Also, I’ll be using English as the human language. All of this still holds true for other combinations.

Here is a hypothetical data structure where the problem starts:

struct ControlFlags {
   int gizmoOnOff : 1;
   // other flags, too, but only one for this example
};

Later, that data structure will be used. This is where the name is all wrong:

struct ControlFlags cf;
// assume the above is now useful . . .
if (cf.gizmoOnOff)
   // . . .

One part of writing good code is attempting to write it in a self-explanitory way. The more naturally the code reads, the better. In the example, the program seems to be checking if the gizmo is in the “OnOff” state. Is it on-off? What does that mean? That the gizmo is either on or off? If so, what state can it have that is neither on nor off? Is it Schrödinger’s Gizmo?

cf.gizmoOnOff = 0;  // gizmo in a superposition state? or not?

Almost certainly a superposition state is not what was meant, but what state is meant by a cleared flag? Is it on or off? With both in the name, the code does not provide an answer. If the programmer meant for a set flag to indicate that the gizmo is on, then the name should be “gizmoOn”:

if (cf.gizmoOn)
   // . . .

This code is very clear about what it is checking because it is much more self-explanitory. It reads almost like it is written in English; it clearly checks for the on state. Anyone reading that code will not have to make assumptions about how the value of gizmoOn is used to understand the code. Such assumptions are not always correct, and they should be avoided in anything as technical as a computer program. Take for example flags for buttons:

struct Buttons {
   int aUpDown : 1;
   int bUpDown : 1;
};

You might assume that if aUpDown is set that the button is pressed; that seems to be the common assumption among people who work on software. Or you may figure that since up comes before down in the name that a set flag indicates the button is up. There is software out there that indicates a pressed button with a set flag, but hardware often indicates that same state with a cleared flag. For instance, read out the data from an old NES or Playstation controller when no buttons are pressed and all the button flags will be set. In this case, naming a button flag something like “aUp” makes this clear and helps prevent others looking at the code from making the wrong assumption.

Naming the flag with only one state will also prevent someone from making fun of you by asking something like “Why is this check here since the button cannot be up-down?” or “So I set this flag to turn the gizmo on-off, and clear it to turn it . . . into a unicorn?” I suppose that is better than transforming the gizmo into Unicron.


False Steps

The Space Race as it might have been

keithlugcom.wordpress.com/

You Control The Action!

High Frontier

the space colony simulation game

Simple Climate

Straightforwardly explaining climate change, so you can read, react and then get on with your life.