4 ms·

And as I recall Linux had a kernel patch that would bypass the affected hardware and run all floating point operations in software (splitting floats into two in

And as I recall Linux had a kernel patch that would bypass the affected hardware and run all floating point operations in software (splitting floats into two integers, etc), so you could bypass the flaw at the cost of performance.

wahern 7y ago
I remember Linux having floating-point emulation for 486 processors without a floating point unit. But at least according to this early message from Torvalds, Linux didn't implement this for FDIV: > It wouldn't be impossible, but it's not something I will do: this isn't a problem to be solved by the OS, but by Intel or the user. The fdiv bug isn't a problem for most people, and for those that it is, it's more efficient to make the compiler do the bug work-around instead. > Note that doing it in the kernel would mean trapping for every fp operation, and that's not good for a fp-intensive program: and the main programs which /would/ care about the fdiv bug are the fp-intensive ones. https://groups.google.com/d/msg/comp.os.linux.development/4o75FKT7Ng4/_OeHY8a-yWkJ https://groups.google.com/d/msg/comp.os.linux.development/4o... Googling around it seems the typical solution, other than just doing nothing, was to recompile, as GCC had a patch to detect the FDIV bug and emulate division much more efficiently. I only had a 486SX (no FPU) at the time so it was never really on my radar. Non-scientific software didn't really do floating-point arithmetic precisely because FPUs weren't very common on consumer hardware. Most of the people burnt by the FDIV bug were already well positioned to either recompile their software or receive patches from their vendors.
- flatiron 7y ago
  not OP but i always assume Linux had a workaround. But you are right, it just prints you got the bug and that's that https://github.com/torvalds/linux/search?q=X86_BUG_FDIV&unscoped_q=X86_BUG_FDIV https://github.com/torvalds/linux/search?q=X86_BUG_FDIV&unsc...

wahern 7y ago

I remember Linux having floating-point emulation for 486 processors without a floating point unit. But at least according to this early message from Torvalds, Linux didn't implement this for FDIV: > It wouldn't be impossible, but it's not something I will do: this isn't a problem to be solved by the OS, but by Intel or the user. The fdiv bug isn't a problem for most people, and for those that it is, it's more efficient to make the compiler do the bug work-around instead. > Note that doing it in the kernel would mean trapping for every fp operation, and that's not good for a fp-intensive program: and the main programs which /would/ care about the fdiv bug are the fp-intensive ones. https://groups.google.com/d/msg/comp.os.linux.development/4o75FKT7Ng4/_OeHY8a-yWkJ https://groups.google.com/d/msg/comp.os.linux.development/4o... Googling around it seems the typical solution, other than just doing nothing, was to recompile, as GCC had a patch to detect the FDIV bug and emulate division much more efficiently. I only had a 486SX (no FPU) at the time so it was never really on my radar. Non-scientific software didn't really do floating-point arithmetic precisely because FPUs weren't very common on consumer hardware. Most of the people burnt by the FDIV bug were already well positioned to either recompile their software or receive patches from their vendors.

flatiron 7y ago
not OP but i always assume Linux had a workaround. But you are right, it just prints you got the bug and that's that https://github.com/torvalds/linux/search?q=X86_BUG_FDIV&unscoped_q=X86_BUG_FDIV https://github.com/torvalds/linux/search?q=X86_BUG_FDIV&unsc...