814 karma · joined November 5, 2013
The sum of all mission-detailed satellites is lower than the total (even thought there’s a « no recorded » line
There’s a grand total of 58 surveillance satellites around the earth today ? Yeah... I think there’s a few missing
I was interested by the title but will skip the article because of poor UI
"Intel. We notified Intel about our findings, including a preliminary writeup and proof-of-concept code, on January 31st, 2019. Intel had acknowledged the issue and requested an embargo on the results in this paper, ending May 14th, 2019. Intel has further classified this issue as Microarchitectural Store Buffer Data Sampling (MSBDS), assigning it CVE-2018-12126 and a CVSS ranking of Medium. Finally, Intel had indicated that we are the first academic group to report this issue and that a similar issue was found internally as well.
AMD. We also notified AMD’s security response team regarding our findings, including our writeup. AMD had investigated this issue of their architectures and indicated that AMD CPUs are not vulnerable to the attacks described in this paper.
ARM. We have also notified ARM’s security response team regarding our findings. ARM had investigated this issue and found that ARM CPUs are not vulnerable to the attacks described in this paper. IBM. Finally, we also notified IBM security about the finding reported in this work. IBM had responded that none of their CPUs is affected, including System-V and PowerPC."
And here's a description (from the paper) of the mechanisms :
"The Mechanism Behind Fallout. Fallout exploits an optimization that we call Write Transient Forwarding (WTF), which incorrectly passes values from memory writes to subsequent memory reads. In a nutshell, when the program writes a value to memory, the processor needs to first translate the virtual address of the destination to a physical address and then acquire exclusive access to the location. Rather than stalling the store instruction and subsequent computation, the processor records the value and the address in the store buffer, and continues executing the program. The store buffer then resolves the address, acquires the access to the memory location and stores the data.
When a value is in the store buffer, care should be taken that subsequent loads from the same address do not read stale values from memory. To solve this, the processor matches the addresses of all load instructions against addresses in the store buffer. In the case of a match, the processor forwards the matching value from the store buffer to the load instruction. To increase efficiency, the processor uses partial address matches to rule out the need for store-to-load forwarding. WTF kicks in when a load instruction partially matches a preceding store and the processor determines that the load is bound to fail. In such cases, instead of cleaning up the state of the processor, it marks the load as faulty, and incorrectly forwards the value of the partially matched store.
Exploiting the WTF optimization. Fallout exploits this behavior to leak, through a microarchitectural channel, the value that WTF incorrectly forwards. The attacker deliberately performs a faulty load, causing the CPU to transiently forward an incorrect value from the store buffer. We subsequently leak the value using a Flush+Reload [58] side channel. As the store buffer is a shared resource used by all software running on a CPU core, the incorrectly-forwarded value might not even belong to the attacker’s process."
People are losing faith in the political system and I fear they are also losing faith in the judicial system.
Do you think the people would be OK with more oversight on the lower level of the executive branch, but none on the legislative or the judicial branches nor on the top level of the executive branch (the president, in the US of A and in at least a few other countries) ?
Also, it's worth noting that laws are usually not retroactive, AFAIK, meaning that if you commit what would be a crime under a new law before that law was passed, you can't be prosecuted.
The "finding the issue" aspect is interesting but rarely used in real life (well, it's often used during debugging, once an issue was found in production).
The insight is very interesting. I always thought there would be 2 separate binary searches...
Even though, I don't really understand that one : "The IN-early-out optimization: When doing a look-up on a multi-column index and an IN operator is used on a column other than the left-most column, then if no rows match against the first IN value, check to make sure there exist rows that match the columns to the right before continuing with the next IN value. ". I would think there's no need to check the right column(s) if the leftmost one has no match...
Is there any follow up on the body that approved a patent that should never have been granted ? Not per the court order. Is there any punitive damage awarded to the defender against the filer ? Not per the court order.
Having been personally frivolously sued in the past, I can tell you, it's not fun and it's expensive. And even if you win, you have to sue back to pretend to any kind of financial compensation. If you have a settlement saying the opposing party is supposed to give you X amount of money, you have to sue to recover that money. And they can appeal. And even if you have an agreement saying that the winning party is entitled to have their legal fees paid by the opposing party, apparently no judge ever grants the real legal fees.
There's a major amount of work to be done in how we deal with abusive lawsuits and who pays the bill for the shared public legal system.
EDIT : the author(s) of the press release used the word "upload". That term is nowhere to be found in the original paper as far as I can tell.
EDIT : I don't even think we know of a way to fix Spectre in the kernel...
1) know your debugging tools. IMO this is imperative, as you're going to set probably thousands of breakpoints over your career, and use the continue/step functions millions of times. I personally use the eclipse integrated debugger. The "back-in-time" debuggers have proven too slow for the kind of product I work with.
2) Try to find a case that does the right thing. It's always useful to be able to compare 2 use cases, even though it might be a bit overloading at times. It might also help you understand what works and what doesn't, reducing the potential target area. And it'll give you a test case. Too many people write the test case after having "fixed" the bug, but end up using either a test case that was working to begin with.
3) make assumptions. Don't dig into every function on the code path. Step over a function, knowing what result you'd expect if the function was doing the right thing and what you'd expect if it was doing the wrong thing. If it's doing neither of these, either you don't understand the function/product as well as you thought or the previous developer didn't help you. If it's doing what you believe is the right thing, don't worry about that function. Move on.
4) Don't go for the long winding code path. If there's 2 ways a function could fail, you might want to go down the easiest to prove/disprove rather than the most likely to fail. If you can prove the bug is in the small path, you're basically done. If you can prove it's not, then you can start going down the rabbit hole. If you can't prove either way, maybe try to assume the bug is further down the execution path.
5) keep track of your previous assumptions. I like the eclipse debugger because I can see all my breakpoints at once, even when they span files. I can also deactivate some without losing their location. Sometimes, you'll have to go back to your previous assumptions, either because they were wrong or because your brain is trying to process too much information.
6) that brings me to something that saved me so many times : Don't hesitate to restart from scratch. It'll never be really from scratch. When going through the metal process again, you'll remember why you mad that assumption, you'll see paths that seemed curious but that you ignored. You might be able to cleanup a lot of the breakpoints you deactivated but didn't delete. None of that is wasted time
7) take a breath. Sometimes, I physically feel odd. A ball in my chest, my head goes heavy, I have some sort of anxiety attack. I've decided to think all those are just a sign my brain is getting overwhelmed. Take a breath, get some water, take a short walk, and go back to 6. You might have made a wrong assumption, or you're just trying to keep too much data in your brain. Just restart and get back to where you were again. Usually you'll be much faster the 2nd time than the 1st time, and faster the 3rd time, etc.
8) if you find a solution that's like "if value is one specific value, then return", you're probably on the right path but you're not fixing the whole thing. Which means you or someone else will be doing exactly what you did. If it's you, you'll just get frustrated. If it's someone else, they'll probably do a worse job than you, or hate you for your hack, or just add one more hack to yours. Dont start the nasty if statement. Sometimes it's what you need to do, but that's pretty rare in my experience.
9) if a sudden idea sounds completely absurd, unrelated to the current code path at end, or stupid but is overly easy to test, drop everything and do test that idea. Because you still have all your breakpoints visible, restarting from scratch won't be that long, but the stupid idea might save you a lot of time. An example from no later than yesterday : After debugging something that seemed impossible, we realized we were simply not connecting to the right database. Stupid to no point, but super easy to test and gave us the right answer right there. Feel free to laugh at yourself, but don't blame/shame yourself or the person you're helping. Just tease them/you a bit and move on.
10) don't hesitate to debug using printf. I know it's frowned upon in certain circles, but if a specific line is being hit hundreds of time by your smallest test case, hitting "step" or "continue" every time will prove too long. I personally print something along the lines of "MOLYSS 10a : this is what I'm doing and here's the value of the variable I'm interested in : ". No one else in the entire company should be printing anything starting with MOLYSS, so it's super easy to grep my logs for it. If you think a code path is very unlikely, just put "WTF" in your printf output, so you know you need to understand why you're printing it in the first place.
11) know what a race condition is. Learning to recognize one when you see one has saved me many times. These are often extremely hard to prove, but fixing them might just be about adding a dependency or a synchronized block.
12) feel free to be proud when you found something. No one will pat your back, so you got to do it yourself. It's one of these skills that few people see but that are crucial and that can make you the person to go to for tricky/urgent issues. And when Sev0 always end up on your plate not because you're responsible for the bug but because you're the most reliable around, it gets noticed.
I'm probably missing a few things, but I think if you can do all that, you'll probably be better and faster at debugging than many people around you
In other words, he might not have been building up the hype but instead was making sure he wouldn't have to retract a paper with a (more or less) obvious mistake in it. That's how science should be done rather than behind closed doors !
I've experience the hour long crying showers first hand, and I don't wish it to anyone. Don't minimize how you feel, and don't blame/shame yourself. Therapy can be scary and still cary a stigma, but it's basically allowed me to be myself.
I am no founder myself, so I don't pretend to know what you're going through, but I know the symptoms. Let me know if you want to discuss this further
Still today, over 10% of the world population don't have access to clean water. I'm also curious on how clean the water needs to be to be used with this catalyst. AFAIK, most catalyst conversion need pretty pure water, in which case, we would not only use water, but use _clean_ water, which is even more scare than "dirty" water...
That's completely ignoring the fact that if you have cheaper workers, you end up being underpaid and/or doing a job you'd rather not be doing. Unemployment rate alone don't tell the whole story, and failing to acknowledge that sounds like poor/partial journalism to me
Apparently, having a bachelor's degree and a job in computer science was enough, under certain policies, to be H1B eligible. that the bachelor degree might have been in chemistry or in art wasn't relevant to the old policy. The new policy articulates that the degree should be computer related.
On top of it, it seems the old memorandum was not properly informing on the real policy. The given example sounds very odd though (apparently only programmers who were working for a company who's specialty was _not_ software were eligible for the 2-year degree rule...).
Computer programmer is not in and on itself a "specialized occupation" with the new memo. You also would need to be either senior or have the relevant degrees.
"most browsers" would become "the majority of browsers". If there were 5 browsers, "the majority of 5 browsers" would be "3 browsers or more". It doesn't make any difference which ones are most used, the sentence (apparently now changed or removed) wasn't "most of the requests will be protected", or even "most users will be protected"
They apparently use their own product on their email server, which unpacked the POC by guessing the password of the archive, scanned the uncompressed file and triggered the bug that was being reported. Love it !
That stuff costs money and if you're only launching 5 people at once, it's still a high sticker for each launch. While "regular" vacation scales pretty well with the number of people you're going with, it's not going to be the case for space exploration.
On a regular vacation, most of the cost overhead for each additional person is the transportation cost. Here, the vacation _is_ the trip
Jocking aside, I don't think there can only be one. I am comparing BO and SpaceX the same way I'd compare google and apple. In the same industry but not doing exactly the same thing. And when Apple tried to go on one of Google's turf with maps, they sucked. When Google tried to go do phones, at first they sucked. Comparison is natural and welcome.
Here, it feels to me that BO is putting themselves up for comparison for no reason.
As far as the positive direction of spaceflight, I think that transparency is key. Space exploration needs more accountability and trust that ever has been available before _in_any_industry_ever_. And there, so far SpaceX is winning hands down, including versus the old players (soyouz, ariane, ULA...). When SpaceX says "one of our struts was structurally deficient, broke down, made the rocket lose equilibrium and ultimately explode", they're also telling their competitors "Watch this. We've learned it the hard way.". Same with fog icing the leg lock. In the grand scheme of things they are making space safer, and not only for their customers. I only see bragging and borderline (note the "borderline") bullying on BO's side
As far as space tourism, I feel like it's just that : tourism. Reserved to more and more concentrated elite and pretty short sighted. There's no problem with being excited about it, but it's better to also do something meaningful about it, other than signing a check and posting some cool instagram picture of your 30 seconds vacation. Even if it's just understanding how much effort was put in getting you there.