Older gen keyless entry systems were subject to relay attacks, new ones aren't, because:

1. New fobs have accelerometers in them and go inactive after a short period, then there's no signal to relay.
2. New cars/fobs can use UWB technology, which uses time of flight calculations to locate the position of the fob with centimetre accuracy, in a way that can't be relayed. https://www.embedded.com/enhan...
3, New cars/fobs can use LF technology to locate the position of the fob with centimetre accuracy. https://ww1.microchip.com/down...

My Model Year 2024 car will refuse to lock the car if the fob is inside the car. If I stand outside the car with the fob in my pocket and reach through the window I can't start it, the fob has to be inside the car. The fob has a LED in it that blinks when it's within range of the car and active, and goes off after around a minute no matter how close it is to the car, showing it's gone inert. There's nothing to relay, you have to physically move the key to wake it up.

Solution to the problem? Buy a new car ;-)

Then you are fooling yourself, others have already pointed out why.

If you are a competent CS teacher, I am Larry Ellison.

...are doomed to repeat it.

I'll just leave this 24 year old paper here...

https://www.usenix.org/legacy/...

But sure, reinvent the wheel, with corners, and off-centre hub and no spokes.

> I don't f-ing trust them not to step all over each other's memory.

Boggle. You *really* don't have the faintest clue, do you?

I think you should probably stay away from computers altogether...

Employ people who know what they are doing.

The whole post is garbage. The problems with usespace spinlocks are pointed out in the pthread_spin_init(3) manpage and it's clear he knows about that library function as he mentions it in the comments. Shame he didn't bother to read the documentation.

Spin locks should be employed in conjunction with real-time scheduling policies (SCHED_FIFO, or possibly SCHED_RR).
Use of spin locks with nondeterministic scheduling policies such as SCHED_OTHER probably indicates a design mistake.
The problem is that if a thread operating under such a policy is scheduled off the CPU while it holds a spin
lock, then other threads will waste time spinning on the lock until the lock holder is once more rescheduled and releases the lock.

If threads create a deadlock situation while employing spin locks, those threads will spin forever consuming CPU time.

User-space spin locks are not applicable as a general locking solution. They are, by definition, prone to priority inversion and
unbounded spin times. A programmer using spin locks must be exceptionally careful not only in the code, but also in terms
of system configuration, thread placement, and priority assignment.

And now a load of people with an actual clue are having to refute his nonsense. He should grow a pair and retract the post.