Contra this assertion, drones are already frequently used around power lines, and as such, "finding hanging wires with a drone" is actually a very active field with fairly robust solutions. Not only are drones used for power line inspections (which are actually a somewhat easier variant of this problem, because the drone usually flies above or adjacent to the power lines in this scenario), but also for infrastructure inspections in direct adjacency to power lines. Power line detect-and-avoid is a headlining feature in one of DJI's newer enterprise platforms, the M400 (where it's based on LIDAR + mmWave Radar fusion).
Also of note, this isn't the first double-failure issue for the MK30 - they had an issue last year at their test facility where their LIDAR malfunctioned in the same way on two drones in the same weather condition (misting), the drones believed they were at 0.0AGL and powered down in flight.
mmWave is the usual solution for this; I know that Amazon were at least testing using mmWave but I'm not sure if it made it to their production drones.
A gist is such a weird way to run a project like this!
Basically what this seems to be about is adding full native acceleration support for Mac OS hosts to QEMU (audio, GL, etc.), to enable running a desktop Linux guest effectively, but it's so hard to follow what's going on that I'm not certain what to actually do to get the Best Possible QEMU on OSX Host.
In the case of Apple AVD, it's a multi-stage system with a bunch of special primitives, orchestrated by a Cortex-M3 with firmware. Codec-specific frontends emit IR which a less specialized backend can execute.
This really heavily depends on the device, though. There are all sorts of "hardware" video decoders ranging from fairly generic vector coprocessors running firmware to "pure" HDL/VLSI level implementations. Usually on more modern or advanced hardware you'll see more and more become more general purpose, since a lot of the later stages can be shared across codecs, saving area vs. a pure hardware implementation.
I agree in general; PCRs provide some basic degree of protection against this. Unfortunately, the position these management controllers are in often grants memory access, which renders all of the boot measurement type security methods useless. Even if it doesn't, there's also the notion that an attacker will replace the firmware from the very start with one that fakes the PCR hashes which are sent to the TPM. Unfortunately, this isn't really very hard with most UEFI implementations.
I see the point you're trying to make but it's really very orthogonal to this issue: this was an issue in a documented part of a documented feature, it's not some "deeply embedded" system management controller with no documentation, it's "the signed firmware update feature in the big obvious selling point where the server has a backdoor management interface was broken."
Almost all quadcopter brushless motors are constructed as “outrunners,” with a fairly thick, sturdy aluminum motor bell (rotor!) with strong permanent magnets glued inside of it and the stator in the center. I agree that they are not immune to RF but at high frequencies it will require a really comical amount of power to do anything to one.
I have never seen someone make a distinction between Secure Boot and boot verification on UEFI/x86, although I suppose it’s a valid one? I suspect the parent post is referring to Secure Boot in the colloquial sense it’s usually used for on x86: validation of the UEFI boot binary using Secure Boot keys followed by OS level trust chaining, usually accomplished by entangling PCR state with disk encryption in some way.
And I think this would deliver a slight level of protection from the BMC: tampering with the firmware image or key enrollment / secure boot state _should_ both break the UEFI root of trust and alter the PCR state and break everything downstream. Of course, all UEFI implementations are holier than Swiss cheese and there are probably a lot of ways to use the BMC to dump or modify memory post-boot anyway, but it does do something.
You mean the same Secure Boot that I mean. This is a software mechanism (almost universally implemented as an unholy mixture of ordinary code in firmware and a pile of immensely complex SMM code that, IMO, is entirely unnecessary if the hardware or the BMC gives even the slightest bit of help).
And Secure Boot is implemented in, and configured by, the firmware that the BMC can overwrite at its whim while entirely bypassing all the fancy CPU-hardware and SMM protections that are supposed to prevent writing arbitrary data to it.
To the extent that a mechanism not controlled by firmware will detect such an attack and extend PCRs accordingly before executing a single instruction from the compromised flash chip, it might partially mitigate attacks. But that part isn’t Secure Boot.
Oh, yes, we 100% agree on this, the true root of trust for firmware execution exists before and independently of “secure boot,” and therefore, often not at all (and “secure boot” is a terrible name).
https://www.youtube.com/shorts/HFzRTRcjiqg
Also of note, this isn't the first double-failure issue for the MK30 - they had an issue last year at their test facility where their LIDAR malfunctioned in the same way on two drones in the same weather condition (misting), the drones believed they were at 0.0AGL and powered down in flight.
https://www.bloomberg.com/news/articles/2025-05-16/amazon-re...
reply