3 ms·

In the hardware world are there risks of taking advantage of a bug knowing that the manufacturer may someday fix the bug? I know in the software world it's a ba

In the hardware world are there risks of taking advantage of a bug knowing that the manufacturer may someday fix the bug? I know in the software world it's a bad idea to leverage a bug in a platform to enable a feature (or fix another bug). The bug you're counting on being present may get fixed 15 years in the future and then your system explodes and no one knows why. edit: seems like there was a recent discussion about something similar... undefined behavior in some C function iirc

vlovich123 2y ago
Undefined behavior in C/C++ has been discussed for a very very long time. I'd say the impact of it when combined with optimizing compilers first came to broader public awareness around the 2010ish time frame (maybe 2013?) which is now about 12+ years old. As for this paper, it's not about relying on a bug but rather presenting what might be possible with DRAM in the hopes of standardizing capabilities.
alexpotato 2y ago
This pops up in low latency HFT specifically with networking cards. Certain network cards have either a bug or combination of features that work in an interesting way to the benefit of the trading firm. These bugs (and features too) sometimes get removed in favor of either getting rid of the bug or those features are seen as not needed for the larger market etc. Therefore, firms will sometimes attempt to buy up all available supply of certain models.
nomel 2y ago
This usually falls under "interoperability testing", but usually mitigated through your firmware rather than hardware. In the worst types of cases, you need to make sure your hardware works with some popular defunct vendor from 15 years ago since some big customers have used that hardware for 15 years, without issue, and will see your hardware as the problem when they plug it in. For communication equipment, this is super important, with all sorts of "quirks" put in for vendors that didn't follow the spec. And, that includes keeping quirks in your firmware, so you don't break anyone else's. Imagine entire walls of legacy and long-gone and current competitor equipment, with robot arms to plug things in, and you have an idea of what some hardware validation labs look like. Motherboard manufacturer firmware is also filled with quirks for specific CPUs, chipsets, etc.

vlovich123 2y ago

Undefined behavior in C/C++ has been discussed for a very very long time. I'd say the impact of it when combined with optimizing compilers first came to broader public awareness around the 2010ish time frame (maybe 2013?) which is now about 12+ years old. As for this paper, it's not about relying on a bug but rather presenting what might be possible with DRAM in the hopes of standardizing capabilities.

alexpotato 2y ago

This pops up in low latency HFT specifically with networking cards. Certain network cards have either a bug or combination of features that work in an interesting way to the benefit of the trading firm. These bugs (and features too) sometimes get removed in favor of either getting rid of the bug or those features are seen as not needed for the larger market etc. Therefore, firms will sometimes attempt to buy up all available supply of certain models.

nomel 2y ago

This usually falls under "interoperability testing", but usually mitigated through your firmware rather than hardware. In the worst types of cases, you need to make sure your hardware works with some popular defunct vendor from 15 years ago since some big customers have used that hardware for 15 years, without issue, and will see your hardware as the problem when they plug it in. For communication equipment, this is super important, with all sorts of "quirks" put in for vendors that didn't follow the spec. And, that includes keeping quirks in your firmware, so you don't break anyone else's. Imagine entire walls of legacy and long-gone and current competitor equipment, with robot arms to plug things in, and you have an idea of what some hardware validation labs look like. Motherboard manufacturer firmware is also filled with quirks for specific CPUs, chipsets, etc.