Henrietta Lacks And Immortal Cell Lines

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”

Improved Perfboard For Surface Mount Parts

Look through the last two decades of electronics project built on perfboard, and you’ll notice a trend. Perfboard is designed for through-hole parts, but ever more frequently, the parts we need are only available as surface mount devices. What does this mean for the future of all those protoboard, veroboard, and tagboard designs? It’s not good, but fortunately, there may be an answer. It’s perfboard designed for mounting SOICs, SOTs, and other surface mount devices.

Perfboard is an extremely simple concept. Most through-hole electronic components are built around 0.1″ or 2.54 mm spacing between pins. Yes, there are exceptions, but you can always bend the middle pin of a transistor and put it in a hole. SMT devices are different. You can’t really bend the pins, and the pin pitch is too small for the 0.1″ holes in traditional perfboard.

[electronic_eel] is changing that game up with his own design for perfboard. This perfboard has the traditional 0.1″ holes, but there are SMD pads sprinkled about between these holes. The result is being able to solder SOIC, SOT23-6, SOT23 and SOT363 devices directly to a board alongside 0603 and 0805 devices. Connect everything with a few beads of solder and you have a functional circuit made out of surface mount devices on something that’s still compatible with the old protoboard designs.

This isn’t the first time we’ve seen a new type of protoboard make it into production. A few years ago, Perf+, a bizarre ‘bus-based’ protoboard solution came onto the scene, although that wasn’t really designed for SMD parts. While [electronic_eel] doesn’t have any plans to sell his protoboard, the files are available, and you can easily design your own small piece of perfboard.

Speculative Execution Was A Troublemaker For Xbox 360

Part of why people can’t stop talking about Meltdown/Spectre is the fact that all the individual pieces have been sitting in plain sight for a long time. When everyone saw how it all came together last week, many people (and not even necessarily security focused people) smacked themselves on the forehead: “Why didn’t I see that earlier?” Speculative execution has caused headaches going way back. [Bruce Dawson] tells one such story he experienced back in 2005. (Warning: ads on page may autoplay video.)

It’s centered around Xbox 360’s custom PowerPC processor. Among the customization on this chip was the addition of an instruction designed to improve memory performance. This instruction was a hack that violated some memory consistency guarantees held by the basic design, so they knew up front it had to be used very carefully. Even worse: debugging problems in this area were a pain. When memory consistency goes wrong, the code visible in the debugger might not be the actual code that crashed.

Since we’re talking about the dark side of speculative execution, you can already guess how the story ends: no matter how carefully it was used, the special instruction continued to cause problems when speculatively executed outside the constrained conditions. Extensive testing proved that instructions that were not being executed were causing crashes. That feels more like superstition than engineering. As far as he can recall, it ended up being more trouble than it was worth and was never used in any shipped Xbox 360 titles.

[Main image source: AnandTech article on Xbox 360 hardware]

A Stepper Motor For Two Dimensions

We’ve all heard linear motors, like those propelling Maglev trains, described as “unrolled” versions of regular electric motors. The analogy is apt and helps to understand how a linear motor works, but it begs the question: what if we could unroll the stator in two dimensions instead of just one?

That’s the idea behind [BetaChecker’s] two-axis stepper motor, which looks like it has a lot of potential for some interesting applications. Build details are sparse, but from what we can gather from the videos and the Hackaday.io post, [BetaChecker] has created a platen of 288 hand-wound copper coils, each of which can be selectively controlled through a large number of L293 H-bridge chips and an Arduino Mega. A variety of sleds, each with neodymium magnets in the base, can be applied to the platen, and depending on how the coils are energized, the sled can move in either dimension. For vertical applications, it looks like some coils are used to hold the sled to the platen while others are used to propel it. There are RGB LEDs inside the bore of each coil, although their function beyond zazzle is unclear.

We’d love more details to gauge where this is going, but with better resolution, something like this could make a great 3D-printer bed. If one-dimensional movement is enough for you, though, check out this linear stepper motor that works on a similar principle.

Continue reading “A Stepper Motor For Two Dimensions”

First Light: The Story Of The Laser

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”

Go Retro To Build A Spectre And Meltdown-Proof X86 Desktop

[Yeo Kheng Meng] had a question: what is the oldest x86 processor that is still supported by a modern Linux kernel? Furthermore, is it actually possible to use modern software with this processor? It’s a question that surely involves experimentation, staring into the bluescreen abyss of BIOS configurations, and compiling your own kernel. Considering Linux dropped support for the 386 in 2012, the obvious answer is a 486. This supposition was tested, and the results are fantastic. You can, indeed, install a modern Linux on an ancient desktop.

This project got its start last month at a Super Silly Hackathon where [Yeo] and [Hui Jing] installed Damn Small Linux on an ancient IBM PS/1 desktop of 1993 vintage. The hardware consists of an AMD 486 clone running at 133MHz, 64 MB of RAM, a 48x IDE CDROM drive (wow!), a floppy emulator, a Sound Blaster, 10Mbps Ethernet card, and a CompactFlash to IDE adapter. By any account, this is a pimped-out rig for 1993 that would have cost more than a car at the time. The hardware works, but can you run a modern Linux kernel on it?

[Yeo] decided to install the Gentoo x86 minimal installation, but sanity and time constraints meant compiling a kernel on a 486 wasn’t happening. That was done on a modern Thinkpad after partitioning all the drives, verifying all the compilation parameters, and configuring the kernel itself. The bootloader is LILO (Grub2 didn’t work), but for the most part, this is entirely modern software running on a 25-year-old machine. The step-by-step instructions for becoming a /g/entooman on a 486 are available on GitHub.

The entire (boring) boot process can be seen in the video below. One interesting application of this build is that the 486 does not support out-of-order execution, making this completely safe from Meltdown and Spectre attacks. It’s an impressive retrocomputing achievement that right now could not be more timely.

Continue reading “Go Retro To Build A Spectre And Meltdown-Proof X86 Desktop”

Lowering JavaScript Timer Resolution Thwarts Meltdown And Spectre

The computer security vulnerabilities Meltdown and Spectre can infer protected information based on subtle differences in hardware behavior. It takes less time to access data that has been cached versus data that needs to be retrieved from memory, and precisely measuring time difference is a critical part of these attacks.

Our web browsers present a huge potential surface for attack as JavaScript is ubiquitous on the modern web. Executing JavaScript code will definitely involve the processor cache and a high-resolution timer is accessible via browser performance API.

Web browsers can’t change processor cache behavior, but they could take away malicious code’s ability to exploit them. Browser makers are intentionally degrading time measurement capability in the API to make attacks more difficult. These changes are being rolled out for Google Chrome, Mozilla Firefox, Microsoft Edge and Internet Explorer. Apple has announced Safari updates in the near future that is likely to follow suit.

After these changes, the time stamp returned by performance.now will be less precise due to lower resolution. Some browsers are going a step further and degrade the accuracy by adding a random jitter. There will also be degradation or outright disabling of other features that can be used to infer data, such as SharedArrayBuffer.

These changes will have no impact for vast majority of users. The performance API are used by developers to debug sluggish code, the actual run speed is unaffected. Other features like SharedArrayBuffer are relatively new and their absence would go largely unnoticed. Unfortunately, web developers will have a harder time tracking down slow code under these changes.

Browser makers are calling this a temporary measure for now, but we won’t be surprised if they become permanent. It is a relatively simple change that blunts the immediate impact of Meltdown/Spectre and it would also mitigate yet-to-be-discovered timing attacks of the future. If browser makers offer a “debug mode” to restore high precision timers, developers could activate it just for their performance tuning work and everyone should be happy.

This is just one part of the shock wave Meltdown/Spectre has sent through the computer industry. We have broader coverage of the issue here.