Curated

76 Articles

Hackaday’s finest original content articles curated by the Hackaday editors

Henrietta Lacks And Immortal Cell Lines

January 9, 2018 by 80 Comments

In early 1951, a woman named Henrietta Lacks visited the “colored ward” at Johns Hopkins hospital for a painful lump she found on her cervix. She was seen by Dr. Howard W. Jones, who indeed found a tumor growing on the surface of her cervix. He took a tissue sample, which confirmed Henrietta’s worst fears: She had cancer.

The treatment at the time was to irradiate the tumor with radium tubes placed in and around the cervix. The hope was that this would kill the cancerous cells while preserving the healthy tissue. Unbeknownst to Henrietta, a biopsy was taken during her radium procedure. Slivers of her tumor and of healthy cervix cells were cut away. The cancer cells were used as part of a research project. Then something amazing happened: the cancerous cells grew and continued to grow outside of her body.

As Henrietta herself lay dying, the HeLa immortal cell line was born. This cell line has been used in nearly every aspect of medical research since the polio vaccine. Millions owe their lives to it. Yet, Henrietta and her family never gave consent for any of this. Her family was not informed or compensated. In fact, until recently, they didn’t fully grasp exactly how Henrietta’s cells were being used.

Continue reading “Henrietta Lacks And Immortal Cell Lines” →

Entropy And The Arduino: When Clock Jitter Is Useful

January 8, 2018 by 37 Comments

What do you do, when you need a random number in your programming? The chances are that you reach for your environment’s function to do the job, usually something like rand() or similar. This returns the required number, and you go happily on your way.

A shift register configured as a pseudo-random number generator.
A shift register configured as a pseudo-random
number generator. [by KCAuXy4p CC0 1.0]
Except of course the reality isn’t quite that simple, and as many of you will know it all comes down to the level of randomness that you require. The simplest way to generate a random number in software is through a pseudo-random number generator, or PRNG. If you prefer to think in hardware terms, the most elementary PRNG is a shift register with a feedback loop from two of its cells through an XOR gate. While it provides a steady stream of bits it suffers from the fatal flaw that the stream is an endlessly repeating sequence rather than truly random. A PRNG is random enough to provide a level of chance in a computer game, but that predictability would make it entirely unsuitable to be used in cryptographic security for a financial transaction.

There is a handy way to deal with the PRNG predictability problem, and it lies in ensuring that its random number generation starts at a random point. Imagine the  shift register in the previous paragraph being initialised with a random number rather than a string of zeros. This random point is referred to as the seed, and if a PRNG algorithm can be started with a seed derived from a truly unpredictable source, then its output becomes no longer predictable.

Selecting Unpredictable Seeds

Computer systems that use a PRNG will therefore often have some form of seed() function alongside their rand() function. Sometimes this will take a number as an argument allowing the user to provide their own random number, at other times they will take a random number from some source of their own. The Sinclair 8-bit home computers for example took their seed from a count of the number of TV frames since switch-on.

The not-very-random result of a thousand analogRead() calls.
The not-very-random result of a thousand analogRead() calls.

The Arduino Uno has a random() function that returns a random number from a PRNG, and as you might expect it also has a randomSeed() function to ensure that the PRNG is seeded with something that will underpin its randomness. All well and good, you might think, but sadly the Atmel processor on which it depends has no hardware entropy source from which to derive that seed. The user is left to search for a random number of their own, and sadly as we were alerted by a Twitter conversation between @scanlime and @cybergibbons, this is the point at which matters start to go awry. The documentation for randomSeed() suggests reading the random noise on an unused pin via analogRead(), and using that figure does not return anything like the required level of entropy. A very quick test using the Arduino Graph example yields a stream of readings from a pin, and aggregating several thousand of them into a spreadsheet shows an extremely narrow distribution. Clearly a better source is called for.

Noisy Hardware or a Jittery Clock

As a slightly old-school electronic engineer, my thoughts turn straight to a piece of hardware. Source a nice and noisy germanium diode, give it a couple of op-amps to amplify and filter the noise before feeding it to that Arduino pin. Maybe you were thinking about radioactive decay and Geiger counters at that point, or even bouncing balls. Unfortunately though, even if they scratch the urge to make an interesting piece of engineering, these pieces of hardware run the risk of becoming overcomplex and perhaps a bit messy.

The significantly more random result of a thousand Arduino Entropy Library calls.
The significantly more random result of a thousand Arduino Entropy Library calls.

The best of the suggestions in the Twitter thread brings us to the Arduino Entropy Library, which uses jitter in the microcontroller clock to generate truly random numbers that can be used as seeds. Lifting code from the library’s random number example gave us a continuous stream of numbers, and taking a thousand of them for the same spreadsheet treatment shows a much more even distribution. The library performs as it should, though it should be noted that it’s not a particularly fast way to generate a random number.

So should you ever need a truly random number in your Arduino sketch rather than one that appears random enough for some purposes, you now know that you can safely disregard the documentation for a random seed and use the entropy library instead. Of course this comes at the expense of adding an extra library to the overhead of your sketch, but if space is at a premium you still have the option of some form of hardware noise generator. Meanwhile perhaps it is time for the Arduino folks to re-appraise their documentation.

The subject of entropy and generating random numbers is one that has appeared on these pages many times. [Voja Antonic] made a in-depth study using uninitialized RAM as an entropy source for microcontrollers. If you have an insatiable appetite for understanding Linux entropy, we point you at [Elliot Williams]’ comprehensive examination of the subject.

[Arduino image: DustyDingo Public domain]

First Light: The Story Of The Laser

January 8, 2018 by 36 Comments

Lasers are such a fundamental piece of technology today that we hardly notice them. So cheap that they can be given away as toys and so versatile that they make everything from DVD players to corneal surgery a reality, lasers are one of the building blocks of the modern world. Yet lasers were once the exclusive province of physicists, laboring over expansive and expensive experimental setups that seemed more the stuff of science fiction than workhouse tool of communications and so many other fields. The laser has been wildly successful, and the story of its development is an intriguing tale of observation, perseverance, and the importance of keeping good notes.

Continue reading “First Light: The Story Of The Laser” →

Let’s Talk Intel, Meltdown, And Spectre

January 5, 2018 by 150 Comments

This week we’ve seen a tsunami of news stories about a vulnerability in Intel processors. We’re certain that by now you’ve heard of (and are maybe tired of hearing about) Meltdown and Spectre. However, as a Hackaday reader, you are likely the person who others turn to when they need to get the gist of news like this. Since this has bubbled up in watered-down versions to the highest levels of mass media, let’s take a look at what Meltdown and Spectre are, and also see what’s happening in the other two rings of this three-ring circus.

Meltdown and Spectre in a Nutshell

These two attacks are similar. Meltdown is specific to Intel processors and kernel fixes (basically workarounds implemented by operating systems) will result in a 5%-30% speed penalty depending on how the CPU is being used. Spectre is not limited to Intel, but also affects AMD and ARM processors and kernel fixes are not expected to come with a speed penalty.

Friend of Hackaday and security researcher extraordinaire Joe Fitz has written a superb layman’s explanation of these types of attacks. His use of the term “layman” may be a little more high level than normal — this is something you need to read.

The attack exploits something called branch prediction. To boost speed, these processors keep a cache of past branch behavior in memory and use that to predict future branching operations. Branch predictors load data into memory before checking to see if you have permissions to access that data. Obviously you don’t, so that memory will not be made available for you to read. The exploit uses a clever guessing game to look at other files also returned by the predictor to which you do have access. If you’re clever enough, you can reconstruct the restricted data by iterating on this trick many many times.

For the most comprehensive info, you can read the PDF whitepapers on Meltdown and Spectre.

Update: Check Alan Hightower’s explanation of the Meltdown exploit left as a comment below. Quite good for helping deliver better understanding of how this works.

Frustration from Kernel Developers

These vulnerabilities are in silicon — they can’t be easily fixed with a microcode update which is how CPU manufacturers usually workaround silicon errata (although this appears to be an architectural flaw and not errata per se). An Intel “fix” would amount to a product recall. They’ve already said they won’t be doing a recall, but how would that work anyway? What’s the lead time on spinning up the fabs to replace all the Intel chips in use — yikes!

So the fixes fall on the operating systems at the kernel level. Intel should be (and probably is behind the scenes) bowing down to the kernel developers who are saving their bacon. It is understandably frustrating to have to spend time and resources patching these vulnerabilities, which displaces planned feature updates and improvements. Linus Torvalds has been throwing shade at Intel — anecdotal evidence of this frustration:

“I think somebody inside of Intel needs to really take a long hard look at their CPU’s, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.”

That’s the tamest part of his message posted on the Linux Kernel Mailing List.

Stock Sales Kerfuffle is Just a Distraction

The first thing I did on hearing about these vulnerabilities on Tuesday was to check Intel’s stock price and I was surprised it hadn’t fallen much. In fact, peak to peak it’s only seen about an 8% drop this week and has recovered some from that low.

Of course, it came out that back in November Intel’s CEO Bryan Krzanich sold off his Intel stock to the tune of $24 Million, bringing him down to his contractual minimum of shares. He likely knew about Meltdown when arranging that sale. Resist the urge to flame on this decision. Whether it’s legal or not, hating on this guy is just a distraction.

What’s more interesting to me is this: Intel is too big to fail. What are we all going to do, stop using Intel and start using something else? You can’t just pull the chip and put a new one in, in the case of desktop computers you need a new motherboard plus all the supporting stuff like memory. For servers, laptops, and mobile devices you need to replace the entire piece of equipment. Intel has a huge market share, and silicon has a long production cycle. Branch prediction has been commonplace in consumer CPUs going back to 1995 when the Pentium Pro brought it to the x86 architecture. This is a piece of the foundation that will be yanked out and replaced with new designs that provide the same speed benefits without the same risks — but that will take time to make it into the real world.

CPUs are infrastructure and this is the loudest bell to date tolling to signal how important their design is to society. It’s time to take a hard look at what open silicon design would bring to the table. You can’t say this would have been prevented with Open design. You can say that the path to new processors without these issues would be a shorter one if there were more than two companies producing all of the world’s processors — both of which have been affected by these vulnerabilities.

Teaching Alexa To 3D Print

January 5, 2018 by 21 Comments

Sometimes a gadget like Alexa or Google Home is a solution looking for a problem. Then the problem you’ve been looking for hits you square in the face. I’ve confessed before that I have an oscilloscope problem. I also have a microcontroller development board habit. It appears now I have too many 3D printers. I recently finished building my latest one, an Anet A8 I picked up on Black Friday. While calibrating it, I found myself juggling a screwdriver, a pair of pliers, and trying to operate the thing all at one time. I realized I had to come up with a better way.

I don’t know if it qualifies as an addiction yet, but I also have an Alexa in every room (although I call it “Computer” because I’m a Star Trek fan) and a Google Home device almost everywhere. Why can’t I get one of these assistants to operate my printer for me? What are assistants for, after all, other than telling Dad jokes?

You’d think adding voice control to a 3D printer would a bit difficult. With the right tools, it is actually pretty easy. Luckily those tools aren’t anything special… if you want a set up like mine, where Alexa controls your 3D printer, read on.

Continue reading “Teaching Alexa To 3D Print” →

Finding Your Motorbike Using Wi-Fi

January 5, 2018 by 18 Comments

An urban planner once told me that every car requires at least four times as much space as they actually occupy. Each needs a spot on the roads, and three available parking spaces: one at home, one at work, and one to shop. Motorcycles are much smaller, but they still spend most of their time parked.

Motorcycles are the primary means of transport in Southeast Asia, and learning to safely drive one is an essential part of adapting to life here. Assuming it’s not pouring rain and you’re not flooded past your ankles, it’s actually quite a pleasant experience… until you have to park.

Unlike the parking lots you may be familiar with, there’s no expectation that your bike won’t be moved. In fact, it might very well end up on another floor, in another parking lot, or behind hundreds of impassable parked bikes on the roof. In the latter case, the attendant will shrug and suggest you come back in a few hours. Eventually, this won’t even register as a frustration – you will simply reason that there are plenty of other things that are more convenient here, like the weather (recent typhoon aside) or unlimited symmetrical fiber to the home for USD 5 a month.

That being said, with a little technology the problem could be lessened a bit while waiting for automated parking lots to become commonplace. On rare occasions I see people with little radio emitters that make their headlights flash, but they’re not terribly common here and require carrying yet another thing on my already full key chain (homes here typically use several different locks). It seemed pretty easy to pull off something similar using my smart phone with an ESP8266 running NodeMCU. I had been meaning to try out the sleep modes to save battery power anyway, so off I went.

Continue reading “Finding Your Motorbike Using Wi-Fi” →

Guide: Why Etch A PCB When You Can Mill?

January 4, 2018 by 83 Comments

I recall the point I started taking electronics seriously, although excited, a sense of dread followed upon the thought of facing the two main obstacles faced by hobbyists and even professionals: Fabricating you own PCB’s and fiddling with the ever decreasing surface mount footprints. Any resistance to the latter proves futile, expensive, and frankly a bit silly in retrospect. Cheap SMD tools have made it extremely easy to store, place, and solder all things SMD.

Once you’ve restricted all your hobbyist designs/experiments to SMD, how do you go about producing the PCBs needed for prototyping? Personally, I dread the thought of etching my own boards. The process is laborious and involves messy chemicals and specially sensitized PCB’s — none of which interest me. I’ve only ever done it a few times, and have promised myself never to do it again. Professional but cheap PCB manufacturing is more like it board pooling services such as OSH park have made this both easy and affordable — if you can wait for the turnaround.

So what are the alternatives? If you are really serious about swift prototyping from your own Lab, I put forth the case of milling your own PCB’s. Read on as I take you through the typical workflow from design to prototype and convince you to put up with the relatively high start up cost of purchasing a PCB mill.

Continue reading “Guide: Why Etch A PCB When You Can Mill?” →