Note that this wouldn't be the first time that Linux has done this. RedHat kernels used to support a 4GB/4GB address split on i386 PAE systems. Conventionally, on 32-bit systems, the kernel reserves the top 2GB of the address space and userspace gets the bottom 2GB. When this started to get cramped, the was an option to reserve the top 1GB for the kernel and make the bottom 3GB available for userspace. Sometimes, even that wasn't enough, so with a 4GB/4GB address split both get completely separate page tables and you do a page table swap on every kernel entry and exit. I remember it came with a performance hit, but I vaguely remember that it was closer to 5-10% back then (which some people were willing to pay if it meant that their code that needed 3.5GB of RAM actually ran, with the kernel using 3GB of RAM). It was fairly short lived, because most people who had a real use for it bought x86-64 hardware.
Leaving stale ones is often fine. FreeBSD does this intentionally in the transparent superpage promotion. When it condenses adjacent pages into a single superpage in the page tables, it doesn't invalidate the TLB entries. The exact behaviour of this varies between CPUs. When you get a TLB miss in an adjacent address range, it's filled from the superpage entry and now you have two TLB entries for the same virtual address[1]. Intel will just discard the smaller one, Centaur will note the mismatch, invalidate both, and refill from the page table, gem5 will crash (I think we've upstreamed the fix for this), and I'm not sure what AMD does.
Your example is highly unlikely, because the kernel typically reserves the top half of the address space for itself and an attempt by userspace to map anything in this range will fail. On x86 chips, there's a huge gap in the middle of the address space (it actually makes more sense to think of virtual addresses as signed values, with userspace ones being positive, kernel ones being negative, and the size of the number somewhat less than 64 bits [microarchitecture specific]). The kernel map, by default, will include the entire userspace portion of the address space for the current process, so that copies between kernel and userspace are cheap.
This kind of TLB invalidate is actually cheap on AMD, because they implement a tagged TLB with the cr3 value as the tag, so swapping cr3 values implicitly invalidates the TLB, but the entries become valid again when you reset the entry. The PCID feature, which is apparently the cause of this vulnerability, is largely a result of the fact that AMD patented this technique and so Intel doesn't use it.
[1] Some old SPARC chips would literally catch fire if you did this: the TCAMs would run hot enough to burn.
When it comes to the C compiler, Intel puts some things behind microarchitecture tests because in the past they didn't and people complained. They enabled fast paths after doing feature checks and it turned out that a bunch of x86 chips implemented certain instructions, but in microcoded slow paths and the optimised icc version that used them ran a lot slower than the version that didn't. As a result, they only enable certain instructions on chips that they have tested and which run faster when those instructions are used. And then people complained that they weren't doing optimisations on their competitors chips...
In this case, there is a vulnerability affecting a bunch of x86 processors, they issued a patch for x86 processors. This is exactly the right thing to do for a security issue: blanket enable and then whitelist safe CPUs.
Having done a fair amount of both, I would disagree. The things that make software complex are dynamic: you can dynamically create threads and you can dynamically allocate memory, which makes the number of possible interactions almost impossible to statically reason about. In a CPU, all of these things are bounded and (very) finite, to the extent that it is actually possible to apply formal methods to the design (Centaur in collaboration with UT Austin do some amazing work in this area).
The difference is that a bug in software can usually[1] be fixed after you ship, whereas a bug in silicon usually can't (though if you've got a lot of microcode you can sometimes work around it). ARM has a nice chart of the cost of fixing a bug at each stage in development, which becomes more and more terrifying, whereas for software that cost is roughly flat, so you can get away with spending a lot less effort on correctness.
[1] Though not always easily. A colleague of mine released his first CVE a couple of years ago for a small library he wrote a couple of decades back. It turns out that most deployments of this library are in fax machines and printers, with no software update mechanism.
It's been about 20 years since I did this, but I remember that with a battery you could get it to glow red and slowly burn. With a bench supply you could get it to glow white and throw off small burning particles that made it look like a firework.
Because if they don't collect the rubbish, some people won't bother to have it collected and will just pile it up. Rats will nest in it, but they won't stay there and they breed fast enough that some of them will be kicked out of the nest to go somewhere else. A plague of rats is everyone's problem. This is the same reason that a lot of local authorities will pay for rodent exterminators to visit your house if you report an infestation.
If you have a process running on macOS with ambient authority then in most cases a root exploit doesn't give you much - you can already access and modify everything that the user cares about. A vulnerability like this; however, can also be exploited by sandboxed applications (though hopefully not sandboxed daemons, which shouldn't have access to the HIDs).
Most Apple apps are now sandboxed, as are Microsoft Office and anything that is distributed via the App Store. I posted above that most people don't use the App Store, so it's not a huge issue, but I hadn't considered all of the possible vectors. This means that MS Word macro vulnerabilities (and fun things like their OLE bug a little while ago where an incorrect length in a document led to arbitrary code execution), PDF / PNG / JPEG vulnerabilities in Preview, and so on can now be system-level compromises instead of sandboxed-application compromises. That's a pretty big difference: without a vulnerability like this, if I send a Mac user a malicious PDF that they open in Preview and trigger an arbitrary-code execution flaw, I get read access to all of the documents that they have open in Preview (and possibly write access to anything that they've saved in Preview recently), and might be able to trick the user into elevating privilege slightly from there. With this vulnerability, I get complete system access.
This looks as if it's exploitable even for sandboxed processes. This isn't such a big deal on macOS, where both users of the Mac App Store might need to worry, but most other people are only running sandboxed apps written by Apple (I'm not sure if WebKit renderer processes have direct HID access - I don't think they do, because HID events are proxied for them from the privileged component, though the XPC vulnerability a few months ago turned sandboxed WebKit component vulnerabilities into whole-machine compromises). It is a much bigger deal for iOS, where most users run not-very-trusted applications from the iOS App Store and rely on the sandbox framework to isolate them. The sandbox framework doesn't work so well on a compromised kernel.
Most rapid transit does pretty well in this regard. The conventional design puts seats around the edges and has standing space in the middle. If there are lots of passengers, you have most of them standing. If there are fewer with more luggage, then they sit and put the luggage in the middle. I've not had a problem with a suitcase on the BART or the London Undergound.
When I was working my way through college I saw this sort of thing going on to varying degrees of outrageousness in a couple of pretty high priced establishments while some of the cheaper places were models of cleanliness and professionalism
Doesn't surprise me too much. Guess which restaurants get the most spot checks from heath inspectors or are most likely to have heath inspectors believe a tip from a disgruntled former employee? It's not the place where the Mayor eats...
Apple doesn't encourage you to throw away old phones, they encourage you to trade them in for newer ones. Apple recycles them and benefits from reducing the size of the second-hand iPhone market, pushing up prices and making people more likely to buy a new one.
Recycling glass always feels wasteful. We take a bottle, put a load of energy into melting it, and then use the melted glass to make an identical bottle. I find it really hard to believe that this is more cost effective than simply cleaning and refilling the bottle.
Actually, it's one really huge portion of the total cost. Bauxite is abundant, but until about 100 years ago aluminium was one of the most precious metals because the energy cost of smelting it is insane. It is so high, that aluminium smelters are only built in places where electricity generation is cheap (e.g. near hydroelectric dams) because it is not economically feasible to smelt aluminium using normally-priced electricity.
One ton of aluminium costs at least 14,000kWh of electricity to produce. One can is about 14g of aluminium, so that works out to about 0.2kWh per can. Even if that's the only cost, then that works out at about 2-4 cents per can if you're paying normal electricity prices, and well over 1/can even if you're getting a huge discount. That's very close to the wholesale price of a can.
TL;DR: The energy cost of smelting is the vast majority of the cost of aluminium.
Not sure about where you live, but when I was at school we had a wheelie bin to collect aluminium cans that a company paid to take away. The school donated the money to charity and encouraged people to bring aluminium cans to fill it. The gave a talk about their process. Apparently, after taking their costs into account, they made about 1p (in early '90s money) per can. Possibly not enough money to be worth picking them up off the floor, but if you're throwing them away anyway then after sorting it's definitely a profit centre for them. They also made a point that they were not receiving government subsidies for it.
Talking to one of the people in charge of waste management where I used to live, I heard a similar story. The council pays companies to process various kinds of waste, but the company that takes aluminium pays them.
It's not just labour costs. A lot of the reason things like this end up in China has nothing to do with the cost of labour, it's to do with environmental regulations. A bribe in the right place and no one cares that your factory in China is destroying the local environment and killing the workers. Try to do the same thing in the EU / US and you'll find the plant shut down and be looking at criminal charges. It's become so bad in China that they've started executing the bribe takers, which is probably a big part of the reason that it's becoming harder to put things there.
I think the solution would be for manufacturers and retailers to pay up front for the cost of the dealing with their end of life products
This is difficult to do well. Computers sold in the EU include a fee paid by the manufacturer to cover the cost of recycling, but it's a flat rate per product class so there's little incentive to produce one that's cheaper to recycle. For something that's expected to be recycled 3 or more years in the future (unlike a plastic bottle, which is expected to be recycled a few days after it's sold), working out a sensible cost can be quite tricky. You should also factor lifetime into the calculation. If two manufacturers make smartphones with identical components, I'd rather that the one that guarantees 5 years of security updates pays less than the one that guarantees 3, because the best way of reducing recycling costs is not to throw the thing away in the first place.
Burn them and you'll get simple hydrocarbons, plus carbon dioxide and water (and maybe carbon monoxide if you don't burn them with enough oxygen). In some cases, that might be the best option. We're not short of carbon, hydrogen, or oxygen, we're short of energy to turn them into useful things.
I think you're misreading my post. Even with SNI, knowing the IP tells you the domain name of the web site if it's the only web site hosted on that IP. That's rarely a problem, because most web sites are either huge and cover a variety of topics (e.g. Google, Wikipedia), or very small and hosted using vhosts.
Except that they don't know that. They know that you did a DNS lookup of abortionhelp.example and they know that you made a TCP connection to a server that hosts abortionhelp.example. The former can happen as a result of visiting a page there, but it can also happen as a result of virus scanning a spam email, your browser prefetching the destination of an ad, and so on.
If abortionhelp.example is the only host on that IP, then none of this matters, but increasingly it will be hosted on a virtual host that also hosts a hundred other web sites. They could try correlating the DNS queries with the hosted sites, but even that might not be enough and may give too many false positives to try to follow all of them.
If the penalty for dangerous driving that could result in death is the same as for dangerous driving that does result in death (the grandparent's premise), then the penalty will be the same and if you do kill the person and drive off then you're less likely to be caught.
I've seen a couple advertising ACME support. You can use ACME with client authentication, so it's compatible with EV: as long as you do the validation out of band and provide the credentials, you can then still use ACME for signing and deploying the certs.
Piccadilly line takes about an hour from Kings Cross to Heathrow, which isn't too bad if you bring a decent book, and at least doesn't require any changes. Once you've crossed Zone 1, it's usually much less busy and I've never had a problem getting a seat, and often had space around me to stretch out a bit.
Slashdot Mirror
Note that this wouldn't be the first time that Linux has done this. RedHat kernels used to support a 4GB/4GB address split on i386 PAE systems. Conventionally, on 32-bit systems, the kernel reserves the top 2GB of the address space and userspace gets the bottom 2GB. When this started to get cramped, the was an option to reserve the top 1GB for the kernel and make the bottom 3GB available for userspace. Sometimes, even that wasn't enough, so with a 4GB/4GB address split both get completely separate page tables and you do a page table swap on every kernel entry and exit. I remember it came with a performance hit, but I vaguely remember that it was closer to 5-10% back then (which some people were willing to pay if it meant that their code that needed 3.5GB of RAM actually ran, with the kernel using 3GB of RAM). It was fairly short lived, because most people who had a real use for it bought x86-64 hardware.
Leaving stale ones is often fine. FreeBSD does this intentionally in the transparent superpage promotion. When it condenses adjacent pages into a single superpage in the page tables, it doesn't invalidate the TLB entries. The exact behaviour of this varies between CPUs. When you get a TLB miss in an adjacent address range, it's filled from the superpage entry and now you have two TLB entries for the same virtual address[1]. Intel will just discard the smaller one, Centaur will note the mismatch, invalidate both, and refill from the page table, gem5 will crash (I think we've upstreamed the fix for this), and I'm not sure what AMD does.
Your example is highly unlikely, because the kernel typically reserves the top half of the address space for itself and an attempt by userspace to map anything in this range will fail. On x86 chips, there's a huge gap in the middle of the address space (it actually makes more sense to think of virtual addresses as signed values, with userspace ones being positive, kernel ones being negative, and the size of the number somewhat less than 64 bits [microarchitecture specific]). The kernel map, by default, will include the entire userspace portion of the address space for the current process, so that copies between kernel and userspace are cheap.
This kind of TLB invalidate is actually cheap on AMD, because they implement a tagged TLB with the cr3 value as the tag, so swapping cr3 values implicitly invalidates the TLB, but the entries become valid again when you reset the entry. The PCID feature, which is apparently the cause of this vulnerability, is largely a result of the fact that AMD patented this technique and so Intel doesn't use it.
[1] Some old SPARC chips would literally catch fire if you did this: the TCAMs would run hot enough to burn.
When it comes to the C compiler, Intel puts some things behind microarchitecture tests because in the past they didn't and people complained. They enabled fast paths after doing feature checks and it turned out that a bunch of x86 chips implemented certain instructions, but in microcoded slow paths and the optimised icc version that used them ran a lot slower than the version that didn't. As a result, they only enable certain instructions on chips that they have tested and which run faster when those instructions are used. And then people complained that they weren't doing optimisations on their competitors chips...
In this case, there is a vulnerability affecting a bunch of x86 processors, they issued a patch for x86 processors. This is exactly the right thing to do for a security issue: blanket enable and then whitelist safe CPUs.
Having done a fair amount of both, I would disagree. The things that make software complex are dynamic: you can dynamically create threads and you can dynamically allocate memory, which makes the number of possible interactions almost impossible to statically reason about. In a CPU, all of these things are bounded and (very) finite, to the extent that it is actually possible to apply formal methods to the design (Centaur in collaboration with UT Austin do some amazing work in this area).
The difference is that a bug in software can usually[1] be fixed after you ship, whereas a bug in silicon usually can't (though if you've got a lot of microcode you can sometimes work around it). ARM has a nice chart of the cost of fixing a bug at each stage in development, which becomes more and more terrifying, whereas for software that cost is roughly flat, so you can get away with spending a lot less effort on correctness.
[1] Though not always easily. A colleague of mine released his first CVE a couple of years ago for a small library he wrote a couple of decades back. It turns out that most deployments of this library are in fax machines and printers, with no software update mechanism.
It's been about 20 years since I did this, but I remember that with a battery you could get it to glow red and slowly burn. With a bench supply you could get it to glow white and throw off small burning particles that made it look like a firework.
Because if they don't collect the rubbish, some people won't bother to have it collected and will just pile it up. Rats will nest in it, but they won't stay there and they breed fast enough that some of them will be kicked out of the nest to go somewhere else. A plague of rats is everyone's problem. This is the same reason that a lot of local authorities will pay for rodent exterminators to visit your house if you report an infestation.
If you have a process running on macOS with ambient authority then in most cases a root exploit doesn't give you much - you can already access and modify everything that the user cares about. A vulnerability like this; however, can also be exploited by sandboxed applications (though hopefully not sandboxed daemons, which shouldn't have access to the HIDs).
Most Apple apps are now sandboxed, as are Microsoft Office and anything that is distributed via the App Store. I posted above that most people don't use the App Store, so it's not a huge issue, but I hadn't considered all of the possible vectors. This means that MS Word macro vulnerabilities (and fun things like their OLE bug a little while ago where an incorrect length in a document led to arbitrary code execution), PDF / PNG / JPEG vulnerabilities in Preview, and so on can now be system-level compromises instead of sandboxed-application compromises. That's a pretty big difference: without a vulnerability like this, if I send a Mac user a malicious PDF that they open in Preview and trigger an arbitrary-code execution flaw, I get read access to all of the documents that they have open in Preview (and possibly write access to anything that they've saved in Preview recently), and might be able to trick the user into elevating privilege slightly from there. With this vulnerability, I get complete system access.
This looks as if it's exploitable even for sandboxed processes. This isn't such a big deal on macOS, where both users of the Mac App Store might need to worry, but most other people are only running sandboxed apps written by Apple (I'm not sure if WebKit renderer processes have direct HID access - I don't think they do, because HID events are proxied for them from the privileged component, though the XPC vulnerability a few months ago turned sandboxed WebKit component vulnerabilities into whole-machine compromises). It is a much bigger deal for iOS, where most users run not-very-trusted applications from the iOS App Store and rely on the sandbox framework to isolate them. The sandbox framework doesn't work so well on a compromised kernel.
Most rapid transit does pretty well in this regard. The conventional design puts seats around the edges and has standing space in the middle. If there are lots of passengers, you have most of them standing. If there are fewer with more luggage, then they sit and put the luggage in the middle. I've not had a problem with a suitcase on the BART or the London Undergound.
When I was working my way through college I saw this sort of thing going on to varying degrees of outrageousness in a couple of pretty high priced establishments while some of the cheaper places were models of cleanliness and professionalism
Doesn't surprise me too much. Guess which restaurants get the most spot checks from heath inspectors or are most likely to have heath inspectors believe a tip from a disgruntled former employee? It's not the place where the Mayor eats...
Apple doesn't encourage you to throw away old phones, they encourage you to trade them in for newer ones. Apple recycles them and benefits from reducing the size of the second-hand iPhone market, pushing up prices and making people more likely to buy a new one.
It's hard to see because of the torch flame. Apply a large enough current across it and it burns quite prettily though.
Recycling glass always feels wasteful. We take a bottle, put a load of energy into melting it, and then use the melted glass to make an identical bottle. I find it really hard to believe that this is more cost effective than simply cleaning and refilling the bottle.
One ton of aluminium costs at least 14,000kWh of electricity to produce. One can is about 14g of aluminium, so that works out to about 0.2kWh per can. Even if that's the only cost, then that works out at about 2-4 cents per can if you're paying normal electricity prices, and well over 1/can even if you're getting a huge discount. That's very close to the wholesale price of a can.
TL;DR: The energy cost of smelting is the vast majority of the cost of aluminium.
Not sure about where you live, but when I was at school we had a wheelie bin to collect aluminium cans that a company paid to take away. The school donated the money to charity and encouraged people to bring aluminium cans to fill it. The gave a talk about their process. Apparently, after taking their costs into account, they made about 1p (in early '90s money) per can. Possibly not enough money to be worth picking them up off the floor, but if you're throwing them away anyway then after sorting it's definitely a profit centre for them. They also made a point that they were not receiving government subsidies for it.
Talking to one of the people in charge of waste management where I used to live, I heard a similar story. The council pays companies to process various kinds of waste, but the company that takes aluminium pays them.
They're too wet to burn.
It's not just labour costs. A lot of the reason things like this end up in China has nothing to do with the cost of labour, it's to do with environmental regulations. A bribe in the right place and no one cares that your factory in China is destroying the local environment and killing the workers. Try to do the same thing in the EU / US and you'll find the plant shut down and be looking at criminal charges. It's become so bad in China that they've started executing the bribe takers, which is probably a big part of the reason that it's becoming harder to put things there.
I think the solution would be for manufacturers and retailers to pay up front for the cost of the dealing with their end of life products
This is difficult to do well. Computers sold in the EU include a fee paid by the manufacturer to cover the cost of recycling, but it's a flat rate per product class so there's little incentive to produce one that's cheaper to recycle. For something that's expected to be recycled 3 or more years in the future (unlike a plastic bottle, which is expected to be recycled a few days after it's sold), working out a sensible cost can be quite tricky. You should also factor lifetime into the calculation. If two manufacturers make smartphones with identical components, I'd rather that the one that guarantees 5 years of security updates pays less than the one that guarantees 3, because the best way of reducing recycling costs is not to throw the thing away in the first place.
Burn them and you'll get simple hydrocarbons, plus carbon dioxide and water (and maybe carbon monoxide if you don't burn them with enough oxygen). In some cases, that might be the best option. We're not short of carbon, hydrogen, or oxygen, we're short of energy to turn them into useful things.
I think you're misreading my post. Even with SNI, knowing the IP tells you the domain name of the web site if it's the only web site hosted on that IP. That's rarely a problem, because most web sites are either huge and cover a variety of topics (e.g. Google, Wikipedia), or very small and hosted using vhosts.
Except that they don't know that. They know that you did a DNS lookup of abortionhelp.example and they know that you made a TCP connection to a server that hosts abortionhelp.example. The former can happen as a result of visiting a page there, but it can also happen as a result of virus scanning a spam email, your browser prefetching the destination of an ad, and so on.
If abortionhelp.example is the only host on that IP, then none of this matters, but increasingly it will be hosted on a virtual host that also hosts a hundred other web sites. They could try correlating the DNS queries with the hosted sites, but even that might not be enough and may give too many false positives to try to follow all of them.
If the penalty for dangerous driving that could result in death is the same as for dangerous driving that does result in death (the grandparent's premise), then the penalty will be the same and if you do kill the person and drive off then you're less likely to be caught.
I've seen a couple advertising ACME support. You can use ACME with client authentication, so it's compatible with EV: as long as you do the validation out of band and provide the credentials, you can then still use ACME for signing and deploying the certs.
Piccadilly line takes about an hour from Kings Cross to Heathrow, which isn't too bad if you bring a decent book, and at least doesn't require any changes. Once you've crossed Zone 1, it's usually much less busy and I've never had a problem getting a seat, and often had space around me to stretch out a bit.
He's not necessarily wrong, it's just that in most of the civilised world we haven't reached the end yet.