> ‘Oceanic Boundlessness’ (OBN)
LOL
Readit NewsPaul McKenney's "Memory Barriers: a Hardware View for Software Hackers" is excellent, with Preshing's blog (preshing.com) offering more approachable explanations for beginners.
Thank you
"Memory Barriers: a Hardware View for Software Hackers"
https://www.researchgate.net/publication/228824849_Memory_Ba...
Thank you
Thank you very much.
I can not give you thi final feedback at the moment, I only breefly looked through the articles for not.
The first ones are very accessible (given my prior lnowledge of lamport clocks and happens before as in Java memory model), the later ones I am currently not sure are very clear.
But are easier than the docs I used when first approached this topic in the past, like Documentation/memory-barriers.txt and the Doug Lea's texts.
* for not.
for now
Shameless plug: https://lwn.net/Articles/844224/ is in my opinion exactly the parts that are missing from the book that the author criticizes. I focus on how threads synchronize, independent of the actual primitives you use, and then explain how that synchronization is usually realized.
Thank you very much.
I can not give you thi final feedback at the moment, I only breefly looked through the articles for not.
The first ones are very accessible (given my prior lnowledge of lamport clocks and happens before as in Java memory model), the later ones I am currently not sure are very clear.
But are easier than the docs I used when first approached this topic in the past, like Documentation/memory-barriers.txt and the Doug Lea's texts.
Can anyone suggest a good explanation of memory barriers?
avodonosov commented on Emailing a one-time code is worse than passwords blog.danielh.cc/blog/pass... · Posted by u/max__dev
I don't know if you're sarcastic or just missing the problem; which is that people will be presented with lika a facebook login page, on a site with url like `facebook.quick-login.com` or `facebock.com` and they'll enter the passcode since as fair as they were concerned, they did everything correct. The disclaimer does shit preventing that, they »obviously« didn't share the code with any other website, they entered it on the facebooks as they were told!
I am sarcastic because this discussion is about a different attack. Not about fishing.
(The OP says one time codes are worse than passwords. In case of fishing passwords fail the same way as one time codes.)
I was also sarcastic/provocative even in the prev comment, saying the GOOD site always includes a warning with the code making the attack impossible. A variation of the attack is very widely used by phone scammers: "Hello, we are updating intercomm on your appartment block. Please tell us your name and phone number. Ok, you will receive a code now, tell it to us". Yet many online services and banks still send one time codes without a warning to never share it!
The fishing point may also be used in defence of one time codes: if the GOOD service was using passwords instead of one time codes, the BAD could just initiated fishing attack, redirecting the user to a fake login page - people today are used to "Login with" flow.
avodonosov commented on Emailing a one-time code is worse than passwords blog.danielh.cc/blog/pass... · Posted by u/max__dev
I can assure you that by now, my brain is conditioned to lock into the four-digit code as soon as it can, entirely ignoring everything around it, including the words to the left.
I’m an avid reader. But there are limits to what I can process, and our world has become so full of noise that it has become a coping strategy for brains to selectively ignore stuff if they feel it’s not important at the moment. That effect becomes even more pronounced as the brain deteriorates with age.
I do not believe that receiving such a message you will not notice the phrase.
And more so if you receive them constantly.
But of course, you are entitled to your opinion, even if it's wrong.
avodonosov commented on Emailing a one-time code is worse than passwords blog.danielh.cc/blog/pass... · Posted by u/max__dev
OP’s claim was not that “people don’t read.”
It was that “[t]hey only read what they need to finish what they are currently trying to do.”
Those are two different claims.
Ok. When they need the code they will have to scan through a message like
Do not share the code 3456
The code should be in the same font as the rest of the text.
In a multi-threaded context, memory reads and writes can be reordered by hardware. It gets more complicated with shared cache. Imagine that you have core 1 writing to some address at (nearly) the same time that core 2 reads from that. Does core 2 read the old or the new? Especially if they don't share the same cache -- core 1 might "write" to a given address, but it only gets written to core 1's cache and then "scheduled" to be written out to main memory. Meanwhile, later core 2 tries to read that address, it's not in its cache, so it pulls from main memory before core 1's cache has flushed. As far as core 2 is concerned, the write happened after it read from the address even though physically the write finished in core 1 before core 2's read instruction might have even started.
A memory barrier tells the hardware to ensure that reads-before is also "happens-before" (or after) a given writen to the same address. It's often (but not always) a cache and memory synchronization across cores.
I found Fedora Pikus's cppcon 2017 presentation [1] to be informative, and Michael Wong's 2015 presentation [0] filled in some of the gaps.
C++, being a generic language for many hardware implementations, provides a lot more detailed concepts for memory ordering [2], which is important for hardwares that have more granularity in barrier types that what most people are used to with x86-derived memory models.
[0]: https://www.youtube.com/watch?v=DS2m7T6NKZQ
[1]: https://www.youtube.com/watch?v=ZQFzMfHIxng
[2]: https://en.cppreference.com/w/cpp/atomic/memory_order.html