391 karma · joined July 26, 2015
You can relocate the vector table and to block it off with the MPU if you have one and memory to spare.
static const float FIR_FILTER={
#include "fir_coefs.csv"
};
Since moving here I've effectively stopped riding because of the drivers.
> this attack could be done on literally any website. The issue is people re-used passwords, and also did not have 2fa enabled.
While possible to execute at scale on some websites, this type of attack tends to be quite loud on the receiving end once appropriate metrics are selected for monitoring and alerting.
> "We do not have any indication at this time that there has been a data security incident within our systems."
They should probably work on that, given that those systems were used to extract their customer's data, and that they only noticed when their customer's data was being sold.
Given how far behind they are on disclosure I'd guess they may have only found out from media inquiries.
MalwareBytes keeps a small structure in memory for every file it found during a scan. Sadly my computer had files on it and ran out of RAM.
SentinelOne's filtering scaled like linear search so as the ignore list got longer everything got slower.
Pi4 for SSH server and general arm64 playground.
Pair of Pi4 running Ardupilot and OpenHD, one on my quadcopter, one driving the base station monitor and antenna tracker.
Every so often our OS needed to read a memory mapped asynchronous timer, comparing values it emitted until they stopped changing to confirm that the various system clock demands were safely aligned and that the addition of a periodic tick was not rippling its way through the counter, before using the value. This time I ran at 32.768 kHz, but to see the glitch required reading the timer exactly as the adder rippled. Most of the time the CPU would read in between the ripples and it would work fine.
This driver had worked on several released products with an earlier version of the compiler, we upgraded the compiler slightly to take advantage of a new instruction set in the next chip.
The updated compiler would rarely assume sequential volatile reads from the same address had the same value.
Something like while(v!=v){} would become the equivalent of if(v!=v)while(1){};
This compiler fault meant that our previously working driver would lock up the machine between maybe an hour and a few days, whenever a particular IRQ occurred during the clock domains race.
Normally watchdogs would trap most infinite loops in the system, but it didn't I knew that it had to be this particular IRQ. Disassembled the whole thing, which only had one loop in it (this one). Took me forever to find because the loop structure was essentially correct except that it was branching just past one of the loads that needed redone. So instead of load x, load y, compare y,x, branch if difference to load x, it branches to load y, a difference of two bytes in the branch offset.
The compiler vendor confirmed this and corrected it in the next compiler version. The ticket number used to be on their website but they no longer publish the change log that far back.
The subject may be more complicated than my single sentence can capture.
With Wayland, have you tried out waypipe yet?
1) 40MB of textures 2) split into mipmaps 3) split into ~32x~32 tiles. 4) streamed in according to camera 5) with the lowest resolution layers always loaded to handle whipping the camera around quickly. 6) and the Z-buffer off to save memory bandwidth.
The video is worth watching too.
Perhaps this is a weakness, but I'm glad I checked.
It copied itself into the internal storage, then back to new SD cards.
I wrote out a little text file explaining what had happened and how to remove it.
Never figured out how to tell them about it.