This discussion isn't about ADSL, but NBN connections. At least on an ADSL plan, once you knew your link speed, you would get that much bandwidth all day. Now that people are swapping to NBN, and ISP's aren't paying their extortionate rate for bandwidth, your actual throughput will vary.
I hate the fact that we are building this brand new network, with enough capacity to provide for our bandwidth needs for the next 50 years. But we're not allowing people to use it unless they pay a stupid amount of money. How much of this new infrastructure is sitting idle?
Would we be as complacent if the government built a new road network, but then set speed limits per car based on the wealth of the driver, allowing only 1% of the capacity of the road to be used?
Sure, there was a bunch of documentation from various sources, in various places. But sometimes you just don't know the right key words to look for, or the right place to enter them.
Similar experience here. I've worked with a number of juniors, who all had to learn a new programming language, get their head around our application, source control, red tape, etc. Initially, every task I assign to them takes more of my time to explain and review than if I did it myself. Maybe I'll try to explain what I mean a couple of times, then just quickly type the solution and tell them to read the help pages for every function I used that they don't know yet.
If they hit a problem, I'd tell them to try to find the answer on their own for maybe half an hour, then come and ask. Don't waste a whole day on a question that I can answer in 5 seconds, but try to research the problem first. You may not find the solution, but you might find something else that's equally useful.
After about 3 months, that tends to break even. They should have picked up enough that together we can do slightly more than I could alone. I can flesh out a rough design for a task that might take me a couple of hours alone, answer a couple other questions while they work on it, and they finish it in maybe a day with test cases and any other red tape. The financial break even point comes a bit later, when they are getting the same amount of work done per dollar paid, but working that out was generally someone elses problem.
Provided a junior is showing progress towards that break even point, I don't mind spending the time. But if it feels like I'm doing their work for them for too long, and they aren't showing enough evidence of learning on their own, their days are numbered.
Though I will say that we were very picky about who we hired. We ran graduate students through a 3 hour programming test that nobody finished, to see what they know and how they think. On average, we probably tested 60 people for every person we hired. Every time management hired someone without going through that process, we regretted it.
We shut down our coal fired power station. Since we have so many wind turbines, and we're connected to the other big generators in the eastern states.
Then one day we had a storm that knocked over a big power line to the eastern states. Our other power line was down for maintenance. Our wind turbines switched off to save themselves (perhaps a bit more sensitive than they needed to be). Then the whole grid went dark.
This battery was built as a knee-jerk political response to the event. As well as building some over priced diesel generators.
I don't mind speculative loads, so long as they still enforce bounds checks. eg clang / gcc introduced a builtin in response to spectre to only load from a pointer if it is actually in range. Though fixes like this require the front end language to tell the CPU explicitly what a valid pointer load looks like. If / when built into a future assembly instruction, it should both improve safety and speed.
That's one way of looking at spectre. Another is that the CPU should not remember branch predictions of processes in a different security context. Since the only way to exploit spectre is to train the CPU to do what you want.
It's not the download speed that's the problem, it's that most servers pushing data to you are using a TCP protocol that actively tries to keep the bottleneck network buffer full. If all those servers swapped to BBR, which actively tries to keep that buffer empty, the problem would probably disappear.
At home I get about 4mbit through my ADSL connection. With 4 windows machines downloading OS and game updates, the internet was essentially unusable. So I now run my own DNS and redirect windows & steam download domains to an nginx proxy. That way I can use the rate limiting features of my crappy modem to throttle all traffic going to the proxy's IP.
IMHO The A380 works pretty well servicing flights into or out of Australia. I think It's pretty much the ideal case for the plane right now. Lots of people wanting to travel half way around the world, with varied destinations. Routes that no plane can yet do in a single hop, with enough demand to fill each plane. So fill a few A380's going to other travel hubs, and swap there for another large plane.
But for the northern hemisphere, there's enough demand for single hop flights between regional airports, and a few choices for planes that can fly those routes efficiently. Plus smaller airports are much cheaper to fly into and out of. Bigger is not always better.
Browsing llvm/clang's mailing list, I also found that variant 1 is getting a compiler work around. Though this requires opt-in from each vulnerable call site.
I skimmed both papers, and that seems to about sum it up. Though I would add that all three attacks cause speculative execution of a construction like; "x = array[ *pointer ];", to push memory from an array into or out of cache based on the data loaded from the victim pointer. So combining the announcement does make some sense, as the details of any of those variants might point people to rediscovering the others.
I was impressed with the work put into variant 2. Tricking the CPU branch predictor into running ROP-like gadgets within a higher privileged process, then using cache access timing to work out what happened. It almost sounds like bad sci-fi dialog, yet they actually did it. And yes, the attack complexity sounds comparable to similar ROP stack smashing exploits.
Variant 2 is being patched in compilers. Both gcc and clang are working on patches (that might already be released?) that avoid any speculative execution of indirect branching. Using a trick documented by google to patch the stack with the destination address, and then return. So now we just have to recompile *everything* that has access to privileged / sensitive memory contents to hopefully prevent attackers doing anything useful with branch poisoning. Of course there will be a performance hit, as no indirect branches can be correctly predicted.
Personally I would say that the problem with variant 2 is sharing the branch predictor between domains. Branches taken in one process, influence how branches in other processes are predicted. I can understand that in a modern OS, multiple processes end up running the same library code, so this may have been a deliberate decision. But, if these tables were stored per-thread and context switched, this problem would probably have never been exploitable.
The Spectre paper did suggest that they had found some evidence of something like variant 2 on an AMD CPU. But I believe that the inner workings of AMD's branch predictor are not as easily deduced as Intel's. So the researchers took the easiest route and attacked 3 different Intel cores instead. That doesn't mean that nobody will ever work out how to pull off an attack though.
With a vulnerability disclosure of that scale, I can forgive a researcher for making a poor decision. Maybe you spend months to years bug hunting and make one discovery.
But someone who deals with a near constant stream of high severity bugs, should take a more considered position.
Why did OpenBSD silently release a patch before the embargo?
OpenBSD announced an errata on 30 August 2017 that silently prevented our key reinstallation attacks. More specifically, patches were released for both OpenBSD 6.0 and OpenBSD 6.1.
We notified OpenBSD of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: “In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging”. Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.
The other angle he's griping about, is that these patches are being pushed with no off switch. So when do we return to normal? What about other CPU's that might not be vulnerable? Do we always slow down AMD too?
Exploiting Indirect Branches. Drawing from return oriented programming (ROP) [33], in this method the attacker chooses a gadget from the address space of the victim and influences the victim to execute the gadget speculatively. Unlike ROP, the attacker does not rely on a vulnerability in the victim code. Instead, the attacker trains the Branch Target Buffer (BTB) to mispredict a branch from an indirect branch instruction to the address of the gadget, resulting in a speculative execution of the gadget....
The bit about execution beyond software checks is explaining a specific detail about memory side effects. The above section builds on that concept to show that you can induce these memory side effects by tricking the branch predictor to execute existing code in an unexpected way.
This actually makes you seem like a paid shill for AMD, since the spectre paper states;
We have empirically verified the vulnerability of several Intel processors to Spectre attacks, including Ivy Bridge, Haswell and Skylake based processors. We have also verified the attack’s applicability to AMD Ryzen CPUs. Finally, we have also successfully mounted Spectre attacks on several Samsung and Qualcomm processors (which use an ARM architecture) found in popular mobile phones.
All this means is that they haven't finished an exploit for AMD, not that such an exploit is impossible.
No, don't forget about Spectre. Spectre is the stuff of nightmares.
Meltdown can be avoided by the OS. Spectre can't.
The only mitigation I can see for spectre is to recompile everything without using *any* indirect branch instructions. And that includes "ret", which would require redefining how C calling conventions work, breaking *every* platform ABI.
Simple Meltdown attacks run within your own attacking process, bypassing privilege bits.
The design fault spectre exploits is sharing the branch predictor between different processes. Spectre *doesn't* depend on bypassing privilege bits. Spectre attacks trick the processor into accessing privileged memory from within a privileged process, by speculatively branching to snippets of the wrong code.
The CPU design fix for spectre should actually be quite simple; swap out branch prediction state with thread context switches. But impossible to retrofit via microcode updates.
Spectre exploits the implementation of the CPU branch predictor to trick a high privilege process to speculatively execute some number of ROP-like gadgets. The victim process *doesn't* trip over any privilege checks.
This works because the Ivy Bridge, Haswell and Skylake indirect branch prediction state is shared between threads running on the same core. The Spectre paper claims that this also applies to AMD's Ryzen CPU's, but they didn't implement a working exploit.
Spectre doesn't depend on having the kernel memory mapped into the process, so probably isn't mitigated by FUCKWIT (er KPTI).
Every single system call will essentially incur a costly task switch that wasn't there before. The total slowdown will be based on the total number of syscalls used in any particular workload.
Though since this is the new reality, where accessing kernel memory directly is more expensive than it used to be, you can expect kernel and application developers to try and claw back some of these losses over time.
Slashdot Mirror
This discussion isn't about ADSL, but NBN connections. At least on an ADSL plan, once you knew your link speed, you would get that much bandwidth all day. Now that people are swapping to NBN, and ISP's aren't paying their extortionate rate for bandwidth, your actual throughput will vary.
I hate the fact that we are building this brand new network, with enough capacity to provide for our bandwidth needs for the next 50 years. But we're not allowing people to use it unless they pay a stupid amount of money. How much of this new infrastructure is sitting idle?
Would we be as complacent if the government built a new road network, but then set speed limits per car based on the wealth of the driver, allowing only 1% of the capacity of the road to be used?
Sure, there was a bunch of documentation from various sources, in various places. But sometimes you just don't know the right key words to look for, or the right place to enter them.
Similar experience here. I've worked with a number of juniors, who all had to learn a new programming language, get their head around our application, source control, red tape, etc. Initially, every task I assign to them takes more of my time to explain and review than if I did it myself. Maybe I'll try to explain what I mean a couple of times, then just quickly type the solution and tell them to read the help pages for every function I used that they don't know yet.
If they hit a problem, I'd tell them to try to find the answer on their own for maybe half an hour, then come and ask. Don't waste a whole day on a question that I can answer in 5 seconds, but try to research the problem first. You may not find the solution, but you might find something else that's equally useful.
After about 3 months, that tends to break even. They should have picked up enough that together we can do slightly more than I could alone. I can flesh out a rough design for a task that might take me a couple of hours alone, answer a couple other questions while they work on it, and they finish it in maybe a day with test cases and any other red tape. The financial break even point comes a bit later, when they are getting the same amount of work done per dollar paid, but working that out was generally someone elses problem.
Provided a junior is showing progress towards that break even point, I don't mind spending the time. But if it feels like I'm doing their work for them for too long, and they aren't showing enough evidence of learning on their own, their days are numbered.
Though I will say that we were very picky about who we hired. We ran graduate students through a 3 hour programming test that nobody finished, to see what they know and how they think. On average, we probably tested 60 people for every person we hired. Every time management hired someone without going through that process, we regretted it.
Still waiting for someone to photoshop a new button onto the Tesla launch mode UI....
We shut down our coal fired power station. Since we have so many wind turbines, and we're connected to the other big generators in the eastern states.
Then one day we had a storm that knocked over a big power line to the eastern states. Our other power line was down for maintenance. Our wind turbines switched off to save themselves (perhaps a bit more sensitive than they needed to be). Then the whole grid went dark.
This battery was built as a knee-jerk political response to the event. As well as building some over priced diesel generators.
At least the battery was a good investment.
You forgot to add the political goal to sell the power network. On terms that allow the network operator to guarantee a return on any upgrades.
Most of the recent price rises in SA have gone into the grid infrastructure, not power generation.
I don't mind speculative loads, so long as they still enforce bounds checks. eg clang / gcc introduced a builtin in response to spectre to only load from a pointer if it is actually in range. Though fixes like this require the front end language to tell the CPU explicitly what a valid pointer load looks like. If / when built into a future assembly instruction, it should both improve safety and speed.
That's one way of looking at spectre. Another is that the CPU should not remember branch predictions of processes in a different security context. Since the only way to exploit spectre is to train the CPU to do what you want.
It must be nice living somewhere with infinite bandwidth.
So it's basically; while(true) { send_packet(); next_packet += interval; sleep(next_packet - now()); }
eg, when the CPU wakes up, try to send all the packets you missed?
It's not the download speed that's the problem, it's that most servers pushing data to you are using a TCP protocol that actively tries to keep the bottleneck network buffer full. If all those servers swapped to BBR, which actively tries to keep that buffer empty, the problem would probably disappear.
At home I get about 4mbit through my ADSL connection. With 4 windows machines downloading OS and game updates, the internet was essentially unusable. So I now run my own DNS and redirect windows & steam download domains to an nginx proxy. That way I can use the rate limiting features of my crappy modem to throttle all traffic going to the proxy's IP.
IMHO The A380 works pretty well servicing flights into or out of Australia. I think It's pretty much the ideal case for the plane right now. Lots of people wanting to travel half way around the world, with varied destinations. Routes that no plane can yet do in a single hop, with enough demand to fill each plane. So fill a few A380's going to other travel hubs, and swap there for another large plane.
But for the northern hemisphere, there's enough demand for single hop flights between regional airports, and a few choices for planes that can fly those routes efficiently. Plus smaller airports are much cheaper to fly into and out of. Bigger is not always better.
Browsing llvm/clang's mailing list, I also found that variant 1 is getting a compiler work around. Though this requires opt-in from each vulnerable call site.
I skimmed both papers, and that seems to about sum it up. Though I would add that all three attacks cause speculative execution of a construction like; "x = array[ *pointer ];", to push memory from an array into or out of cache based on the data loaded from the victim pointer. So combining the announcement does make some sense, as the details of any of those variants might point people to rediscovering the others.
I was impressed with the work put into variant 2. Tricking the CPU branch predictor into running ROP-like gadgets within a higher privileged process, then using cache access timing to work out what happened. It almost sounds like bad sci-fi dialog, yet they actually did it. And yes, the attack complexity sounds comparable to similar ROP stack smashing exploits.
Variant 2 is being patched in compilers. Both gcc and clang are working on patches (that might already be released?) that avoid any speculative execution of indirect branching. Using a trick documented by google to patch the stack with the destination address, and then return. So now we just have to recompile *everything* that has access to privileged / sensitive memory contents to hopefully prevent attackers doing anything useful with branch poisoning. Of course there will be a performance hit, as no indirect branches can be correctly predicted.
Personally I would say that the problem with variant 2 is sharing the branch predictor between domains. Branches taken in one process, influence how branches in other processes are predicted. I can understand that in a modern OS, multiple processes end up running the same library code, so this may have been a deliberate decision. But, if these tables were stored per-thread and context switched, this problem would probably have never been exploitable.
The Spectre paper did suggest that they had found some evidence of something like variant 2 on an AMD CPU. But I believe that the inner workings of AMD's branch predictor are not as easily deduced as Intel's. So the researchers took the easiest route and attacked 3 different Intel cores instead. That doesn't mean that nobody will ever work out how to pull off an attack though.
With a vulnerability disclosure of that scale, I can forgive a researcher for making a poor decision. Maybe you spend months to years bug hunting and make one discovery.
But someone who deals with a near constant stream of high severity bugs, should take a more considered position.
Why did OpenBSD silently release a patch before the embargo?
OpenBSD announced an errata on 30 August 2017 that silently prevented our key reinstallation attacks. More specifically, patches were released for both OpenBSD 6.0 and OpenBSD 6.1.
We notified OpenBSD of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: “In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging”. Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.
The other angle he's griping about, is that these patches are being pushed with no off switch. So when do we return to normal? What about other CPU's that might not be vulnerable? Do we always slow down AMD too?
Sigh, did anyone actually read the spectre paper;
Exploiting Indirect Branches. Drawing from return oriented programming (ROP) [33], in this method the attacker chooses a gadget from the address space of the victim and influences the victim to execute the gadget speculatively. Unlike ROP, the attacker does not rely on a vulnerability in the victim code. Instead, the attacker trains the Branch Target Buffer (BTB) to mispredict a branch from an indirect branch instruction to the address of the gadget, resulting in a speculative execution of the gadget. ...
The bit about execution beyond software checks is explaining a specific detail about memory side effects. The above section builds on that concept to show that you can induce these memory side effects by tricking the branch predictor to execute existing code in an unexpected way.
We have empirically verified the vulnerability of several Intel processors to Spectre attacks, including Ivy Bridge, Haswell and Skylake based processors. We have also verified the attack’s applicability to AMD Ryzen CPUs. Finally, we have also successfully mounted Spectre attacks on several Samsung and Qualcomm processors (which use an ARM architecture) found in popular mobile phones.
All this means is that they haven't finished an exploit for AMD, not that such an exploit is impossible.
No, don't forget about Spectre. Spectre is the stuff of nightmares.
Meltdown can be avoided by the OS. Spectre can't.
The only mitigation I can see for spectre is to recompile everything without using *any* indirect branch instructions. And that includes "ret", which would require redefining how C calling conventions work, breaking *every* platform ABI.
Simple Meltdown attacks run within your own attacking process, bypassing privilege bits.
The design fault spectre exploits is sharing the branch predictor between different processes. Spectre *doesn't* depend on bypassing privilege bits. Spectre attacks trick the processor into accessing privileged memory from within a privileged process, by speculatively branching to snippets of the wrong code.
The CPU design fix for spectre should actually be quite simple; swap out branch prediction state with thread context switches. But impossible to retrofit via microcode updates.
You're describing Meltdown, Spectre is worse.
Spectre exploits the implementation of the CPU branch predictor to trick a high privilege process to speculatively execute some number of ROP-like gadgets. The victim process *doesn't* trip over any privilege checks.
This works because the Ivy Bridge, Haswell and Skylake indirect branch prediction state is shared between threads running on the same core. The Spectre paper claims that this also applies to AMD's Ryzen CPU's, but they didn't implement a working exploit.
Spectre doesn't depend on having the kernel memory mapped into the process, so probably isn't mitigated by FUCKWIT (er KPTI).
Spectre has a POC written in Javascript, targeting Chrome's JIT.....
Every single system call will essentially incur a costly task switch that wasn't there before. The total slowdown will be based on the total number of syscalls used in any particular workload.
Though since this is the new reality, where accessing kernel memory directly is more expensive than it used to be, you can expect kernel and application developers to try and claw back some of these losses over time.