Thursday, April 25, 2019

I've been out of date with my reading ...

... but here's a little snapshot, anyway.

  • How the Boeing 737 Max Disaster Looks to a Software Developer (Free registration required)
    The flight management computer is a computer. What that means is that it’s not full of aluminum bits, cables, fuel lines, or all the other accoutrements of aviation. It’s full of lines of code. And that’s where things get dangerous.

    Those lines of code were no doubt created by people at the direction of managers. Neither such coders nor their managers are as in touch with the particular culture and mores of the aviation world as much as the people who are down on the factory floor, riveting wings on, designing control yokes, and fitting landing gears. Those people have decades of institutional memory about what has worked in the past and what has not worked. Software people do not.

    In the 737 Max, only one of the flight management computers is active at a time—either the pilot’s computer or the copilot’s computer. And the active computer takes inputs only from the sensors on its own side of the aircraft.

    When the two computers disagree, the solution for the humans in the cockpit is to look across the control panel to see what the other instruments are saying and then sort it out. In the Boeing system, the flight management computer does not “look across” at the other instruments. It believes only the instruments on its side. It doesn’t go old-school. It’s modern. It’s software.

  • TRITON Actor TTP Profile, Custom Attack Tools, Detections, and ATT&CK Mapping
    The TRITON intrusion is shrouded in mystery. There has been some public discussion surrounding the TRITON framework and its impact at the target site, yet little to no information has been shared on the tactics, techniques, and procedures (TTPs) related to the intrusion lifecycle, or how the attack made it deep enough to impact the industrial processes. The TRITON framework itself and the intrusion tools the actor used were built and deployed by humans, all of whom had observable human strategies, preferences, and conventions for the custom tooling of the intrusion operation. It is our goal to discuss these adversary methods and highlight exactly how the developer(s), operator(s) and others involved used custom tools in the intrusion.

    In this report we continue our research of the actor’s operations with a specific focus on a selection of custom information technology (IT) tools and tactics the threat actor leveraged during the early stages of the targeted attack lifecycle (Figure 1). The information in this report is derived from multiple TRITON-related incident responses carried out by FireEye Mandiant.

    Using the methodologies described in this post, FireEye Mandiant incident responders have uncovered additional intrusion activity from this threat actor – including new custom tool sets – at a second critical infrastructure facility. As such, we strongly encourage industrial control system (ICS) asset owners to leverage the indicators, TTPs, and detections included in this post to improve their defenses and hunt for related activity in their networks.

  • RIP Joe Armstrong (See also this twitter thread)

    (Yes, he was the man who invented Erlang. And did a surprising amount of other stuff that you never knew about.)

  • France’s Yellow Vests Challenge
    Over lunch at an Avenue Matignon café in Paris, I asked a literate media entrepreneur and political expert to explain the Yellow Vests mystery. Who are they, what do they want, who leads them? He started by offering a metaphor. The interior of France, some call it La France Profonde (think of Red States), is like a forest that has been progressively desiccated by climate change. Then gasoline was poured on the trees. Sooner or later a spark would set it ablaze.

    I’ve seen the desiccation, the emptying of France. In an October 2017 Monday Note titled The Compostelle Walk Into Another France, I recounted how, with daughter Marie, we walked through empty villages, no café, no bakery, no garage. Barking dogs roamed the streets during the day, the inhabitants having rushed to their distant jobs. I had had a similar impression years before, driving small country roads in Northern Burgundy, but walking the Compostelle (Camino de Santiago) made it more vivid.

    Over the past three or fours decades, La France Profonde has been slowly hollowed out as jobs moved out of the country or to larger urban areas. This desiccation isn’t unique to France, but gasoline was poured on the forest in the form of an accumulation of laws and regulations that exasperated the remaining France Profonde population, creating a schism between “real people” and “those people in Paris”.

  • Google I/O 2019
    This year’s developer festival will be held May 7-9 at the Shoreline Amphitheatre in Mountain View, CA
  • How Common Are Data Center Meltdowns?
    We all know about catastrophic headline-generating failures like AWS East-1 region falling apart or a major provider being down for a day or two. Then there are failures known only to those who care, like losing a major exchange point. However, I’m becoming more and more certain that the known failures are not even the tip of the iceberg - they seem to be the climber at the iceberg summit.
  • “Users want control” is a shoulder shrug
    There are some cases when a person really does want control. If the person wants to determine their own path, if having choice is itself a personal goal, then you need control. That’s a goal about who you are not just what you get. It’s worth identifying moments when this is important. But if a person does not pay attention to something then that person probably does not identify with the topic and is not seeking control over it. “Privacy advocates” pay attention to privacy, and attain a sense of identity from the very act of being mindful of their own privacy. Everyone else does not.
  • Tesla Full Self Driving ASIC
    Overall, it’s a nice design. They have adopted a conservative process node and frequency. They have taken a pretty much standard approach to inference by mostly leaning on a fairly large multiple/add array. In this case a 96×96 unit. What’s particularly interesting to me what’s around the multiply/add array and their approach to extracting good performance from a conventional low-cost memory subsystem. I was also interested in their use of two redundant inference chips per car with each exchanging results each iteration to detect errors before passing the final plan (the actuator instructions) to a safety system for validation before the commands are sent to the actuators. Performance and price/performance look quite good.
  • Highlights from Git 2.21
    An important optimization for Git servers is that the format for transmitted objects is the same as the heavily-compressed on-disk packfiles. That means that in many cases, Git can serve repositories to clients by simply copying bytes off disk without having to inflate individual objects.

    But sometimes this assumption breaks down. Objects on disk may be stored as “deltas” against one another. When two versions of a file have similar content, we might store the full contents of one version (the “base”), but only the differences against the base for the other version. This creates a complication when serving a fetch. If object A is stored as a delta against object B, we can only send the client our on-disk version of A if we are also sending them B (or if we know they already have B). Otherwise, we have to reconstruct the full contents of A and re-compress it.

    This happens rarely in many repositories where clients clone all of the objects stored by the server. But it can be quite common when multiple distinct but overlapping sets of objects are stored in the same packfile (for example, due to repository forks or unmerged pull requests). Git may store a delta between objects found only in two different forks. When someone clones one of the forks, they want only one of the objects, and we have to discard the delta.

    Git 2.20 solves this by introducing the concept of “delta islands“. Repository administrators can partition the ref namespace into distinct “islands”, and Git will avoid making deltas between islands. The end result is a repository which is slightly larger on disk but is still able to serve client fetches much more cheaply.

No comments:

Post a Comment