But it has a very bad idea, which cannot be fixed: the mechanical functions keys are gone. Instead you have touche sensitive keys, with no travel. One can adapt toa new layout for a product one use often and long (ok, after some grumbling...), and with some utilities remap keys if needed (switching ctrl/caps lock is very common). But you can't add real keys where there are none here. And you can't select an alternative keyboard with the usual functions keys either.
It's very ironic that their new slogan is "Thinkpad, for those who do". I guess it's for those who don't do enough to remember each function key role in the applications they work with, and need an icon on the key to remember it. And use all this infrequently enough not to care about touch sensitive keys.
I'm for one very disappointed with this nonsense. I was looking forward to treat myself with a high definition screen, long battery life light laptop with this update. I guess Asus or somebody else can thank the "innovators" at Lenovo who pushed this crap through.
Then criticize such designs for being insecure, I'm fine with that. But rightfully criticizing a weak design, and condemning the whole of the cellular world are two different things. The article does the later and that's why I think there is exaggeration (with some errors and misunderstandings too).
In theory it is possible. In practice the network operator would see the extra traffic (so the NSA too it seems;), so the risk to get caught red handed seems way too high to me. It could kill a brand.
It's up to everyone to decide on their paranoia threshold and what they feel they need to protect against. But anyone who really cares about its own security and would trust 1) it's smartphone including a lot of closed source software even with Android 2) a complex baseband stack 3) a hugely complex operator network or even many for an international call, just doesn't get security. You want real secure? You need a trusted terminal host stack and and end-to-end secure connection (SRTP, or VoIP over a VPN, etc.). Then you don't have to trust anything in between as anything else just see encrypted traffic. You still have to trust the terminal host stack, so best if one can audit it. This is overkill for most. But that's what secure phones are, with a price to match.
Encryption is optional but typically always set in production network.
For the downgrade attack, I completely agree and mention this elsewhere. When a next gen cellular technology is out there's not much changes/updates on the previous ones as operator focus their investments in the latest. And due to this we still have the 2G issue you mention. That's unfortunate, but in practice I believe the only solution to this will come when 2G will be phased out. It's still a few years away in most countries, and has been done already in some places (some big operators in Japan, South Korea).
"Certification requirements" is the key thing here, and it's a lot of work for vendors (can't really be lazy and succeed in this space;).
Spectrum is a shared medium, and the worst jammer is a buggy device. Because of this there are strict certification requirements before being legally allowed to put a device over the air. And going through all the associated tests cost a lot of money: it's a lot of time with expensive testing hardware and in the field (after passing the "safe for network" part). It's expensive both for operators and vendors by the way. This cost make everyone quite conservative. Any change will go through a cost assessment. So it's not that they don't care about security, they do and even if there has been holes in the old versions a lot of work go into making the system secure. But not at any price.
To be practical, the target is good enough security for the average person. And that's ok. If you really have higher protection requirements than this, there is no way but having your own controlled end-to-end scheme. I would expect anyone claiming security is critical and taking this seriously to have figured this out.
Hi there. I'm not following 3G closely but in LTE the encryption schemes are secure. You have two options, both 128 bits: SNOW 3G (inherited from 3G as you can guess;) and an AES scheme. Both secure as of today. In R10 or R11 a Chinese scheme called ZUC has been added too, also 128 bits. The operator decides on which scheme is used, and the device must support both SNOW 3G and AES today.
The big thing is that the encryption is between the device and cell (base station). The assumption is that the cell is secure, and behind the operator network is secured by other means. So it's important to protect the cell (eNB in LTE) against compromises. A fake cell won't work as in LTE the authentication is mutual: the UE won't work with any cell, except for an emergency call.
No. The SIM is powered from the baseband, and when the baseband is off the SIM has no power supply and can't do anything. Plus the SIM can only communicate with cell towers through the baseband, never on its own. The SIM cannot wake-up the baseband on its own, enabling the radio subsystem can only be done from the host processor. So what you described is not possible.
What is possible however is that when your device cellular radio is on and the baseband is enabled, then the SIM can directly use the baseband to communicate with the network using what is called the SIM Toolkit (STK). This can be done with or without the user being informed. The STK also many features like transforming the numbers you dialed (to seamlessly add a routing prefix, or redirect), filter calls (block or accept), get and report a location, etc. The specs are public, look for 3GPP TS 31.048 and ETSI 102.223 (using USAT and CAT instead of STK, but it's all the same under different names).
I believe the article has some gross exaggerations, and I'm in the baseband business. Of course I can't speak for all implementations, so this is my opinion only.
When the baseband is in a separate die, connected with some interface like SDIO for QCOM, HSI, USB HSIC,... there is no way that the baseband will control any host resources (unless it can exploit a bug in the host software of course). When the baseband is in the same die as the application processor (AP) and its resources, it becomes at least possible in theory for the BB to access AP resources. But think about it: why do we have process memory isolation and MMUs in the first place? And a kernel sitting between hardware and user space? For security and fault isolation. Do you really want to be the poor engineer having to debug a complex system on chip (SoC) where a bug in the BB part can create weird bugs in completely unrelated parts of the system handled by different teams? That looks like a recipe for disaster. In the systems I work on you have hardware isolation between subsystems to prevent just this. And then a compromised BB can't do a lot of damage (same as for a separate die BB).
I believe the article is a bit sensationalistic and miss the real danger: a compromised base station. That's what the source articles quoted talk about. If you can compromise a cell you can spy traffic without any attack on the UE (encryption is only between device and cell). A fake cell is an issue with 2G but since then authentication is mutual: in LTE a device do authenticate the cell too, and won't work with a fake one. But that doesn't protect against a compromised cell. This is a risk with small and femto cells mostly, as macro cells are easier to protect. The only interest as see in compromising the BB is to use it as a vector to attack the host processor (which has been done), where you have access to much more interesting stuff. This requires a security exploit on the host side too. On its own the BB isn't really very interesting as an attack target.
While I'm at it, there are others not very serious claims here. The fact that one can redirect calls to voice mail with an AT command has nothing to do with baseband security. An baseband support a control interface, and even usually two: 1) a modern but proprietary interface and 2) the standard but old fashioned AT interface. You can do a lot with these commands, no need to compromise the BB. But normally such access is limited to trusted applications, so if anyone can access this it's a host security issue, not a baseband issue.
The baseband doesn't contain one RTOS but usually several instances. There's at least one RISC core (typically ARM), possibly more. At least one DSP, possibly more. With likely more than one OS: having an instance running linux is common, with other(s) on RTOS or even bare bone schedulers (depending on the complexity of the task at hand and timing constraints). That can vary a lot depending on each BB design, but as a rule of thumb for a modern LTE capable BB expect two RISC cores and two DSPs (YMMV).
The mutual authentication I've talked about already. Here the practical issue is that when the next gen is out there's not much interest in doing big upgrades to previous generations. So the lack of network authentication in 2G will stay with us until 2G is phased out, which is still a few years away in most places (big Japan networks have already killed 2G however).
The P5600 core is being touted as supporting up to six cores in a cache-coherent link, most likely similar to ARM's CCI-400.
The CCI-400 is not relevant here. In both MIPS and ARM worlds CPUs are now multi cores capable out of the box. One cluster can be configured from 1 to 4 cores typically, and here for this latest MIPS up to 6. The L2 management is handled as part of the cluster, which also typically supports coherency with external hardware accessing the L2 through one or several coherency port(s). The L1 cache(s), the L2 and the hardware are kept coherent inside a cluster (with some limitations at times on the low end, there are variants). All this can be taken for granted at the high-end, as here.
Now what the CCI-400 does is different: it extends coherency management between several clusters. This is very important in the ARM world because of the big.LITTLE scheme: you want the big cluster and little cluster to be kept coherent to speed-up and easy the transition between the low-power and high performance modes (that also helps when all cores are used at all times, as the OS can migrate tasks between cores more efficiently).
No, they will keep the Renesas team I believe as they need them. And the people they're laying off were recently (3 years ago, around October 2010) acquired. In short, historically Broadcom had its own 2G and 3G with associated engineers. When they looked at LTE, instead of developing the technology in-house they acquired a start-up called Beceem. Beceem was doing WiMAX successfully, and as everyone doing WiMAX were in the process of switching to LTE and had started announcing they were on it.
Three years later and Broadcom had no working LTE. Even Intel, who started announcing its first LTE chip in 2011, is starting to show hardware 2 years later. It's likely Broadcom management is not happy at all about the situation, and in the end what's happening here is that they're sacking the Beceem team to replace it with the Renesas LTE team. As they make a point of saying they only acquired the LTE assets of Renesas, they may keep the historical Broadcom 2G/3G people. I'm only guessing from public info here, YMMV.
Now I'm NOT laying the blame on the Beceem guys here. Integration in a bigger company can be complicated, with lots of turf wars. It's very possible that the in-house Broadcom 2G/3G team had their own in-house plans to develop LTE (skunk-work style maybe) and didn't see the Broadcom acquisition in a good light. As LTE needs to be integrated with 2G/3G you need some good cooperation between the teams. It's also possible that some key Beceem guys were not happy and left, leaving the rest in trouble. They could have over promised too. What I mean is that there are many ways to fail in such an acquisition, I don't know what happens and can't and won't lay the blame on anyone. I'm just trying to clarify the situation a bit on what happened.
Now the fact that it is said that only Renesas LTE is interesting. Renesas had a full 2G/3G/LTE system as far as I know. Are they cutting the 2G/3G out to keep their own to please the internal guys? How easy/fast such surgery will be? We're not at the end of the story...
In the original 1965 paper Moore was talking about the density of the least-cost process, and this part is often left out when summarizing what Moore's law is. The full more law is "the density of the least-cost process doubles every 18 months". This means that Moore's law can fail in two ways: if we can't get any denser (not yet) or if we can get denser, but not at a lower cost too (now?). The following says that the "full Moore law" stops at 28 nm:
Rising defect densities have created a situation where — for the first time ever — 20nm wafers won't be cheaper than the 28nm processors they're supposed to replace.
The economic part is often left out on tech sites discussions, but it matters a lot. Up to now we had a sustainable situation where the cost of new processes increased regularly, but at the same time eventually the cost of the new process was lower. This allowed to get all on board and to also increase the reachable market, to get more revenues. That's why we have small micro-controllers everywhere nowadays.
Now when the cost of new processes increases, only the part of the market that trully need the improved density and performance will move on. And that's only a small part of the whole market. So we will have increasing costs, with a reducing addressable market. Double whammy. Expect end prices for high performance to rise quickly. That may slow down things significantly.
We'll see how it develops soon, but I would expect the economic to bite before we reach tech limits.
It's "process" in a very general meaning here. There is a whole stack before getting to a physical embodiment on the silicon die from the design RTL. Small clients will just use the approved tools (from Cadence, Synopsys, Mentor...) with ready made libraries of cells/components (many providers, and ARM is one). The big guys have the man-power to define their own cells based on their own trade-offs to get higher performance (at the price of larger area / higher power) or lower power depending. They can also get some customization on the low-level tools. This enables to get more design margins when going to a new node very early to compensate for the fact that the technology is not mature yet for example. All of this is very labor intensive so is only for the big fabless players. You could summarize all this by saying that they have access to the very bottom layers of the stack. And as said elsewhere, all of this is a given for Intel with an even deeper integration between design and process.
Owning its own fab means that Intel can tweak process technology to match the particulars of a given architecture (and vice-versa)
That may be understood as an Intel exclusive, but it's not entirely true. Even in the fabless world the big shots (Qualcomm, NVidia, AMD & co) have very early access to new process nodes and can certainly tune their design to it, and have their own specifics tweaks made. So they can do both kind of adaptation too, although it's not as integrated as for Intel. If you draw a line, Intel is at one extreme being able to have close integration, the small fabless companies are at the other extreme taking the stock TSMC or GF or UMC or else offering as-is. But the big fabless guys are somewhat in the middle.
ARM, in contrast, is limited by the decisions of the foundry manufacturers it partners with.
It's also a bit misleading. ARM has early access to all big fabs (Globalfoundries and TSMC), and because ARM is so pervasive there is a very very high pressure for a fab to provide the best ARM implementations on their process. So sure, it's the fab making the decisions on their process in the end. But you can bet they will pay a lot of attention to any ARM feedback gained during the early access co-work.
ARM doesn't only provide processor IP, they do the whole range now from memory cells to GPUs to interconnect to memory controllers. And they work with the fabs to optimize their design for them and provide their customers "Process Optimization Packages" (POPs) that summarize how to get the best of a process for their IP. So ARM has the know-how, the access and the pull to have a big say in what happens in the fabs roadmaps.
Yes. Also a lot of people do not appreciate the difference between high performance and low power process variants. Getting a low power process successful is a lot harder for technical and economical reasons:
- To reduce resistance in wires (which in turns reduces power dissipation) a LP variants uses thicker wires. For a given process node, this means that the distance between the walls of two parallel wires will be reduced compared to a high perf process using thinner wires. This means that the process must be more controlled to avoid shortages and get a good yield.
- LP processes are used for mobile devices, where the selling prices is lower than for high performance. A middle of the road Haswell is ~$200, a high-end mobile AP is ~$15. Other high-perf devices are GPUs and FPGAs, and in both cases the selling prices is much higher than in low-power applications. Which means you can get away with a higher silicon cost and lower yield.
This is why all fabs start a new process node in high power first, as it's easier and you can get away with a so-so yield. Then some move to the more tricky low-power variant where it's at the same time more technically challenging and you need to get the cost low on top of it.
Now Intel is certainly the king of high-performance processes. But for low-power for mobile TSMC has been producing 28 nm parts for some time now, while what you can buy from Intel is still 32 nm. The 22 nm low-power Atoms from Intel are supposed to be available real soon now. But the key question is their cost: Intel could afford to take a hit to take some market initially, but in the long run they need to be competitive at the lower price point seen in mobile. Will there be able to do that it's still an open question. Having good performance from hand picked 22 nm Atom and having 22 nm parts in products are good steps but it's not sufficient. In the long run Intel must be able to make sufficient money on low cost parts. TSMC knows how to do that and will be there. For Intel, it's still an open question.
Another important point is that TSMC has experience in supporting customers for fabless, as it's their core business. While for Intel it's still very new. People may not appreciate how difficult all this is and how good support is key. There's a lot of know-how and process based on painful experiences, and even with a good process it takes time to build a good service part. Intel has started this, but mostly with simple designs (FPGA are the simpler you can get, that's why they're always the first on any new process node) and most are not out yet.
Lastly, Apple has massive volumes and can only take limited risks on production of their APs. TSMC looks like a much safer bet at this point. If Intel can prove they really can deliver in volume at low cost with good support (it's economics & process here, not having good technical metrics on a few samples) then it'll still be possible to switch in the future. At this time it would be a bit reckless IMHO. And I'm sure Apple did their due diligence all right on all this (with people that do understand the details of this complex business).
If blobs were ONLY firmware, they could run ONLY on the device, and could be loaded once at installation time.
Very few fall into this category. (Some wifi chips do load this way upon every boot).
Even when a firmware blob runs only on the device I would expect it to be loaded every time the device is reset, particularly for a WiFi chip. If you want the blob to be persistent you must add a local Flash to the WiFi subsystem, which increases the BOM cost. And at the very low price in WiFi this is just not acceptable anymore, the chipmaker would sell nothing. So there's no such local storage (except for a minimum bootloader maybe, and that could be in the chip in ROM) and the chip will load it's executable from the host at each reset. I've worked on systems (cellular, not WiFi) that do just that.
T-Mobile's HSPA+ 42 network hides a secret. While it delivers excellent sustained download speeds, those speeds don't look as fast in real life because of a very long time to negotiate the connection, which we measured as "time to first byte." This seemed to have to do with the network frequently switching between UMTS and HSPA+ modes when a connection was opened.
That explains the higher time to first byte compared to ATT HSPA. And then the latency on HSPA is higher than on LTE in general (plus on LTE the data connection is always on, not set-up on demand), as one key design goal of LTE was to allow a low latency (though there can be high variation depending on each operator core network, the radio part contribution is low with LTE).
And one guy opinion may not be representative of the whole of France. I happen to work in a start-up in France, many of my colleagues are foreigners for all around the world (not counting EU people as they're free to work here so not a problem for them). Yes there is some paperwork to do, but if you have a competent HR or go through external competent HR consulting it can be done. It could be more fluid and smoother for sure, nothing is perfect. But it's not as dire as often painted on the web. It adds delay and cost, but if the company pays decent salaries it's not a big factor. You have to justify hiring a foreigner (as in the US), but again if the job is technical it is usually not a big issue. There is high unemployment on average but as in many places there is also shortage of qualified people in some areas, and the administration is aware of this. Of course if you want to get foreigners on the cheap at cut rate salaries it's a different story, but then I'd say the issue is not the country law it's the employer.
It's also possible to fire people, and it has been made easier recently. The company has to provide typically 3 months of advance notice. But it's perfectly possible to just pay this and ask the employee to leave immediately (what we typically do where I work: if there's a problem with someone there's no point lengthening the issue). It's typical to pay a bit more, like 6 months severance. Bigger companies often go higher for old employees, 1 year is not unheard of. But for a start-up I would assume it's on the low end. The issue on firing is not that it cannot be done, but that there is significant legal uncertainty around it: the employee can turn against the employer and challenge the decision or severance amount. Some changes have been done to bring clarity there, I haven't followed the details. It's a true concern, but in high tech which is a small world with usually reasonable people, this is quite rare. I've had contacts with ex-employees working and I expect that to be typical. Everyone benefit by making this as unpleasant as possible (and it's never pleasant). The situation is very different when a manufacturing plant is closed, it can becomes messy with factories being occupied and that's what people tend to hear about. But when talking start-up the context is different.
There are many things to improve in France and many legitimate criticisms on the legal and administrative situation. Still I feel that some paint a blacker picture to justify their own unrelated problems, or having left the country (which is ok in itself: go and explore. No need to pretend you just left hell thought).
The fact is that I have more in common with you guys on/. than you might think. This is a community populated by engineers and technologists, not Luddites. You love great ideas. So do I. We may differ on the *economic value* of those great ideas, but I think this group debates innovation with the same passion and rigor that I do.
Not very useful. You don't need for the device to provide its location with GPS, the network can deduce it with no specific device support (except complying with the cellular standard for replying to the network pages and request for cells measurements). Google "RF pattern matching": it's 100% network side, and is more accurate than GPS in urban and semi-urban locations so cutting the GPS won't help at all here (and most people live in such environments nowadays). RF pattern matching is already deployed in some 2G/3G networks, and is currently being specified for future LTE evolutions.
In rural environments using the device GPS is still the most accurate method, but even then the network can provide a reasonable location estimation based on the device reporting the receive power of its serving and surrounding cells (a standard function, which is used to drive handover). And cellular networks do support this as not all devices have GPS.
When in idle mode, a phone only transmit every few hours to indicate it's still "there". So transmission power is negligible and not a concern. It works as the GP explains (and it's the same principles for UMTS, LTE, WiMAX BTW). In idle, a phone will listen for a possible network paging that indicates an incoming call, SMS or data connection for a very short duration (a few milliseconds to a few tens, depending on the actual standard and implementation) every paging cycle. The maximum paging cycle is 2.56s for LTE and 5.12s for WiMAX and CDMA2000 for example. So it's regular, but only needs reception not transmission (and reception uses less power than transmission).
Then every few hours (3 or 4 is typical, that's standard dependent and configurable) the device will also transmit to indicate it's still in the expected paging area (the LA of GP for GSM). It's just a keep alive to detect a phone going off "uncleanly". In a clean power off, the phone is expected to sign-out to the network so that the network immediately redirects to the voice mail any incoming call. If an incoming call happens for an uncleanly shut down phone before it is detected as out by the network, the network will page it but after a while without the phone replying, it will also consider the phone out and redirect to voice mail. So it will be safe, but will take a bit more time.
Breaking the law, like an awful lot of people in France, and nobody cares. There's this old notion of "cadre" / "non-cadre" in French labor law, and if you're an engineering or master level you're a cadre. Now if you're a cadre there's a special regime where hours are not counted, and the "35 hours" law just amounted to a lump of extra vacation days. You're still supposed to do 48h max but nobody tracks this. A lot of companies are using this and making 50+ hours is quite common. Yes, it is illegal strictly speaking but nobody cares. By "a lot" I mean a lot of big companies in internationally competitive markets, and most small companies. In high tech this set-up is mostly a given.
Now if you're in a big company, particularly if it's protected from international competition or has public roots, then it's a different story. You can be cadre and having to do 35 hours maximum, enforced with badging in some places with strong unions. One example I have in mind is doing military equipment and the French state is the main client.
And actually, even public companies themselves often break the law. Go to any public hospital and you'll find doctors and nurse pulling 60 to 70h work week just because there's not enough people to do the work and the hospitals can't afford to hire more. Everyone know the 35 hours are just not applicable in many contexts, and turn a blind eye to it.
The GGP story is maybe true but is just an anecdote in any case, you don't judge a whole country based on that. What you have to keep in mind is that 56% of the French economy is public economy, which is the highest in Europe. The public sector is then dominant, and rather protected, and can indulge in lazy practice (although there are hard workers too. They often get depressed after a while due to lack of recognition). But the others are working hard and efficiently enough to make France the n5 economy. And that's a statistically significant result not an anecdote;).
Ok, I haven't read TFA (hey, this is/.) but I've read a book addressing this topic: "Sustainable Energy — without the hot air", available for free on the web at http://www.withouthotair.com/ but well worth buying IMHO.
Nothing too surprising: renewable energy alone won't be able to address our current energy consumption level, so must be go with a reduction of our footprint (better efficiency when possible, but also less consumption too). Big problems are storage, and the large investments required to move to renewable in a big way. "Investment" here means money obviously, but also energy and that may create an "energy trap" if we don't anticipate enough the switch.
The author is a physicists at root. He doesn't address the economics of such a transition (big topic, but not his cup of tea) but focus on the physics part. This may be seen as a big limitation, and in a way it is, but the positive side is that he focuses on more solid ground where reaching a consensus based on core physics principle is possible (among people of good will at least). He's very good at illustrating in a simple yet solid way the opportunities and challenge of renewable energy sources. He also puts some boundaries on possible efficiency gains for different domains (transport, heating...) and this too is well explained and very informative.
None of what you list requires two separate OSs, although of course having two separate OSs is a way to implement this. Having users and users data isolation is perfectly possible on a multi-users OS and been done in practice, although not in a mobile environment. The independent management support can also be done by trusted software on the single OS.
An hypervisor really becomes the required approach if one must have two different OSs on the same device. There the multi-users OS falls short. But I wonder how practical it is in this context: you want the user to have similar environments in both professional and personal mode.
The hypervisor approach makes sense when two very different environments must share a CPU. For example, a very limited secure environment (limited to be small and easier to verify) and a regular OS. To simply split professional and user environments it seems overkill.
The pricing is not so much driven by the technology than by what operators can charge. It's particularly true for text, where the margin is really really huge and unrelated to technology. But as it's a geek site let's go over the tech now;) All 3 use slightly different mechanisms.
Short messages (SMS, or text) piggy back over the signaling protocol.
With GSM and WCDMA 3G (3GPP standards), voice and data share the same radio network. But on the network side there are separate core networks for voice (CS domain, for Circuit Switched) and data (PS domain, for Packet Switched). In the CDMA world there are actually separate radio networks for voice (CDMA 1x) and data (EVDO). This is why you can't do both voice and data at the same time on most CDMA phones: it would require 2 radios, which adds cost and complexity. Whereas with 2G/3G, both goes over the same radio network so both can operate concurrently with a single radio.
Starting with 4G, or LTE in practice, there is still a single radio network as before but now the core (EPC, Evolved Packet Core) is also unified and built over IP. Voice over LTE (VoLTE) is not common yet but it's basically VoIP built on IMS. All is unified, but voice is of course prioritized over best effort data using QoS both in the RAN (radio access network) and EPC.
Slashdot Mirror
But it has a very bad idea, which cannot be fixed: the mechanical functions keys are gone. Instead you have touche sensitive keys, with no travel. One can adapt toa new layout for a product one use often and long (ok, after some grumbling...), and with some utilities remap keys if needed (switching ctrl/caps lock is very common). But you can't add real keys where there are none here. And you can't select an alternative keyboard with the usual functions keys either.
It's very ironic that their new slogan is "Thinkpad, for those who do". I guess it's for those who don't do enough to remember each function key role in the applications they work with, and need an icon on the key to remember it. And use all this infrequently enough not to care about touch sensitive keys.
I'm for one very disappointed with this nonsense. I was looking forward to treat myself with a high definition screen, long battery life light laptop with this update. I guess Asus or somebody else can thank the "innovators" at Lenovo who pushed this crap through.
Then criticize such designs for being insecure, I'm fine with that. But rightfully criticizing a weak design, and condemning the whole of the cellular world are two different things. The article does the later and that's why I think there is exaggeration (with some errors and misunderstandings too).
In theory it is possible. In practice the network operator would see the extra traffic (so the NSA too it seems ;), so the risk to get caught red handed seems way too high to me. It could kill a brand.
It's up to everyone to decide on their paranoia threshold and what they feel they need to protect against. But anyone who really cares about its own security and would trust 1) it's smartphone including a lot of closed source software even with Android 2) a complex baseband stack 3) a hugely complex operator network or even many for an international call, just doesn't get security. You want real secure? You need a trusted terminal host stack and and end-to-end secure connection (SRTP, or VoIP over a VPN, etc.). Then you don't have to trust anything in between as anything else just see encrypted traffic. You still have to trust the terminal host stack, so best if one can audit it. This is overkill for most. But that's what secure phones are, with a price to match.
Encryption is optional but typically always set in production network.
For the downgrade attack, I completely agree and mention this elsewhere. When a next gen cellular technology is out there's not much changes/updates on the previous ones as operator focus their investments in the latest. And due to this we still have the 2G issue you mention. That's unfortunate, but in practice I believe the only solution to this will come when 2G will be phased out. It's still a few years away in most countries, and has been done already in some places (some big operators in Japan, South Korea).
"Certification requirements" is the key thing here, and it's a lot of work for vendors (can't really be lazy and succeed in this space ;).
Spectrum is a shared medium, and the worst jammer is a buggy device. Because of this there are strict certification requirements before being legally allowed to put a device over the air. And going through all the associated tests cost a lot of money: it's a lot of time with expensive testing hardware and in the field (after passing the "safe for network" part). It's expensive both for operators and vendors by the way. This cost make everyone quite conservative. Any change will go through a cost assessment. So it's not that they don't care about security, they do and even if there has been holes in the old versions a lot of work go into making the system secure. But not at any price.
To be practical, the target is good enough security for the average person. And that's ok. If you really have higher protection requirements than this, there is no way but having your own controlled end-to-end scheme. I would expect anyone claiming security is critical and taking this seriously to have figured this out.
Hi there. I'm not following 3G closely but in LTE the encryption schemes are secure. You have two options, both 128 bits: SNOW 3G (inherited from 3G as you can guess ;) and an AES scheme. Both secure as of today. In R10 or R11 a Chinese scheme called ZUC has been added too, also 128 bits. The operator decides on which scheme is used, and the device must support both SNOW 3G and AES today.
The big thing is that the encryption is between the device and cell (base station). The assumption is that the cell is secure, and behind the operator network is secured by other means. So it's important to protect the cell (eNB in LTE) against compromises. A fake cell won't work as in LTE the authentication is mutual: the UE won't work with any cell, except for an emergency call.
For more details have a look at the 3GPP 33.401 spec, for example the latest R9 version.
No. The SIM is powered from the baseband, and when the baseband is off the SIM has no power supply and can't do anything. Plus the SIM can only communicate with cell towers through the baseband, never on its own. The SIM cannot wake-up the baseband on its own, enabling the radio subsystem can only be done from the host processor. So what you described is not possible.
What is possible however is that when your device cellular radio is on and the baseband is enabled, then the SIM can directly use the baseband to communicate with the network using what is called the SIM Toolkit (STK). This can be done with or without the user being informed. The STK also many features like transforming the numbers you dialed (to seamlessly add a routing prefix, or redirect), filter calls (block or accept), get and report a location, etc. The specs are public, look for 3GPP TS 31.048 and ETSI 102.223 (using USAT and CAT instead of STK, but it's all the same under different names).
I believe the article has some gross exaggerations, and I'm in the baseband business. Of course I can't speak for all implementations, so this is my opinion only.
... there is no way that the baseband will control any host resources (unless it can exploit a bug in the host software of course). When the baseband is in the same die as the application processor (AP) and its resources, it becomes at least possible in theory for the BB to access AP resources. But think about it: why do we have process memory isolation and MMUs in the first place? And a kernel sitting between hardware and user space? For security and fault isolation. Do you really want to be the poor engineer having to debug a complex system on chip (SoC) where a bug in the BB part can create weird bugs in completely unrelated parts of the system handled by different teams? That looks like a recipe for disaster. In the systems I work on you have hardware isolation between subsystems to prevent just this. And then a compromised BB can't do a lot of damage (same as for a separate die BB).
When the baseband is in a separate die, connected with some interface like SDIO for QCOM, HSI, USB HSIC,
I believe the article is a bit sensationalistic and miss the real danger: a compromised base station. That's what the source articles quoted talk about. If you can compromise a cell you can spy traffic without any attack on the UE (encryption is only between device and cell). A fake cell is an issue with 2G but since then authentication is mutual: in LTE a device do authenticate the cell too, and won't work with a fake one. But that doesn't protect against a compromised cell. This is a risk with small and femto cells mostly, as macro cells are easier to protect. The only interest as see in compromising the BB is to use it as a vector to attack the host processor (which has been done), where you have access to much more interesting stuff. This requires a security exploit on the host side too. On its own the BB isn't really very interesting as an attack target.
While I'm at it, there are others not very serious claims here. The fact that one can redirect calls to voice mail with an AT command has nothing to do with baseband security. An baseband support a control interface, and even usually two: 1) a modern but proprietary interface and 2) the standard but old fashioned AT interface. You can do a lot with these commands, no need to compromise the BB. But normally such access is limited to trusted applications, so if anyone can access this it's a host security issue, not a baseband issue.
The baseband doesn't contain one RTOS but usually several instances. There's at least one RISC core (typically ARM), possibly more. At least one DSP, possibly more. With likely more than one OS: having an instance running linux is common, with other(s) on RTOS or even bare bone schedulers (depending on the complexity of the task at hand and timing constraints). That can vary a lot depending on each BB design, but as a rule of thumb for a modern LTE capable BB expect two RISC cores and two DSPs (YMMV).
The mutual authentication I've talked about already. Here the practical issue is that when the next gen is out there's not much interest in doing big upgrades to previous generations. So the lack of network authentication in 2G will stay with us until 2G is phased out, which is still a few years away in most places (big Japan networks have already killed 2G however).
The P5600 core is being touted as supporting up to six cores in a cache-coherent link, most likely similar to ARM's CCI-400.
The CCI-400 is not relevant here. In both MIPS and ARM worlds CPUs are now multi cores capable out of the box. One cluster can be configured from 1 to 4 cores typically, and here for this latest MIPS up to 6. The L2 management is handled as part of the cluster, which also typically supports coherency with external hardware accessing the L2 through one or several coherency port(s). The L1 cache(s), the L2 and the hardware are kept coherent inside a cluster (with some limitations at times on the low end, there are variants). All this can be taken for granted at the high-end, as here.
Now what the CCI-400 does is different: it extends coherency management between several clusters. This is very important in the ARM world because of the big.LITTLE scheme: you want the big cluster and little cluster to be kept coherent to speed-up and easy the transition between the low-power and high performance modes (that also helps when all cores are used at all times, as the OS can migrate tasks between cores more efficiently).
No, they will keep the Renesas team I believe as they need them. And the people they're laying off were recently (3 years ago, around October 2010) acquired. In short, historically Broadcom had its own 2G and 3G with associated engineers. When they looked at LTE, instead of developing the technology in-house they acquired a start-up called Beceem. Beceem was doing WiMAX successfully, and as everyone doing WiMAX were in the process of switching to LTE and had started announcing they were on it.
Three years later and Broadcom had no working LTE. Even Intel, who started announcing its first LTE chip in 2011, is starting to show hardware 2 years later. It's likely Broadcom management is not happy at all about the situation, and in the end what's happening here is that they're sacking the Beceem team to replace it with the Renesas LTE team. As they make a point of saying they only acquired the LTE assets of Renesas, they may keep the historical Broadcom 2G/3G people. I'm only guessing from public info here, YMMV.
Now I'm NOT laying the blame on the Beceem guys here. Integration in a bigger company can be complicated, with lots of turf wars. It's very possible that the in-house Broadcom 2G/3G team had their own in-house plans to develop LTE (skunk-work style maybe) and didn't see the Broadcom acquisition in a good light. As LTE needs to be integrated with 2G/3G you need some good cooperation between the teams. It's also possible that some key Beceem guys were not happy and left, leaving the rest in trouble. They could have over promised too. What I mean is that there are many ways to fail in such an acquisition, I don't know what happens and can't and won't lay the blame on anyone. I'm just trying to clarify the situation a bit on what happened.
Now the fact that it is said that only Renesas LTE is interesting. Renesas had a full 2G/3G/LTE system as far as I know. Are they cutting the 2G/3G out to keep their own to please the internal guys? How easy/fast such surgery will be? We're not at the end of the story...
Fortunately you can swap them in the BIOS and restore sanity.
Rising defect densities have created a situation where — for the first time ever — 20nm wafers won't be cheaper than the 28nm processors they're supposed to replace.
The economic part is often left out on tech sites discussions, but it matters a lot. Up to now we had a sustainable situation where the cost of new processes increased regularly, but at the same time eventually the cost of the new process was lower. This allowed to get all on board and to also increase the reachable market, to get more revenues. That's why we have small micro-controllers everywhere nowadays.
Now when the cost of new processes increases, only the part of the market that trully need the improved density and performance will move on. And that's only a small part of the whole market. So we will have increasing costs, with a reducing addressable market. Double whammy. Expect end prices for high performance to rise quickly. That may slow down things significantly.
We'll see how it develops soon, but I would expect the economic to bite before we reach tech limits.
It's "process" in a very general meaning here. There is a whole stack before getting to a physical embodiment on the silicon die from the design RTL. Small clients will just use the approved tools (from Cadence, Synopsys, Mentor...) with ready made libraries of cells/components (many providers, and ARM is one). The big guys have the man-power to define their own cells based on their own trade-offs to get higher performance (at the price of larger area / higher power) or lower power depending. They can also get some customization on the low-level tools. This enables to get more design margins when going to a new node very early to compensate for the fact that the technology is not mature yet for example. All of this is very labor intensive so is only for the big fabless players. You could summarize all this by saying that they have access to the very bottom layers of the stack. And as said elsewhere, all of this is a given for Intel with an even deeper integration between design and process.
Owning its own fab means that Intel can tweak process technology to match the particulars of a given architecture (and vice-versa)
That may be understood as an Intel exclusive, but it's not entirely true. Even in the fabless world the big shots (Qualcomm, NVidia, AMD & co) have very early access to new process nodes and can certainly tune their design to it, and have their own specifics tweaks made. So they can do both kind of adaptation too, although it's not as integrated as for Intel. If you draw a line, Intel is at one extreme being able to have close integration, the small fabless companies are at the other extreme taking the stock TSMC or GF or UMC or else offering as-is. But the big fabless guys are somewhat in the middle.
ARM, in contrast, is limited by the decisions of the foundry manufacturers it partners with.
It's also a bit misleading. ARM has early access to all big fabs (Globalfoundries and TSMC), and because ARM is so pervasive there is a very very high pressure for a fab to provide the best ARM implementations on their process. So sure, it's the fab making the decisions on their process in the end. But you can bet they will pay a lot of attention to any ARM feedback gained during the early access co-work.
ARM doesn't only provide processor IP, they do the whole range now from memory cells to GPUs to interconnect to memory controllers. And they work with the fabs to optimize their design for them and provide their customers "Process Optimization Packages" (POPs) that summarize how to get the best of a process for their IP. So ARM has the know-how, the access and the pull to have a big say in what happens in the fabs roadmaps.
This is why all fabs start a new process node in high power first, as it's easier and you can get away with a so-so yield. Then some move to the more tricky low-power variant where it's at the same time more technically challenging and you need to get the cost low on top of it.
Now Intel is certainly the king of high-performance processes. But for low-power for mobile TSMC has been producing 28 nm parts for some time now, while what you can buy from Intel is still 32 nm. The 22 nm low-power Atoms from Intel are supposed to be available real soon now. But the key question is their cost: Intel could afford to take a hit to take some market initially, but in the long run they need to be competitive at the lower price point seen in mobile. Will there be able to do that it's still an open question. Having good performance from hand picked 22 nm Atom and having 22 nm parts in products are good steps but it's not sufficient. In the long run Intel must be able to make sufficient money on low cost parts. TSMC knows how to do that and will be there. For Intel, it's still an open question.
Another important point is that TSMC has experience in supporting customers for fabless, as it's their core business. While for Intel it's still very new. People may not appreciate how difficult all this is and how good support is key. There's a lot of know-how and process based on painful experiences, and even with a good process it takes time to build a good service part. Intel has started this, but mostly with simple designs (FPGA are the simpler you can get, that's why they're always the first on any new process node) and most are not out yet.
Lastly, Apple has massive volumes and can only take limited risks on production of their APs. TSMC looks like a much safer bet at this point. If Intel can prove they really can deliver in volume at low cost with good support (it's economics & process here, not having good technical metrics on a few samples) then it'll still be possible to switch in the future. At this time it would be a bit reckless IMHO. And I'm sure Apple did their due diligence all right on all this (with people that do understand the details of this complex business).
If blobs were ONLY firmware, they could run ONLY on the device, and could be loaded once at installation time. Very few fall into this category. (Some wifi chips do load this way upon every boot).
Even when a firmware blob runs only on the device I would expect it to be loaded every time the device is reset, particularly for a WiFi chip. If you want the blob to be persistent you must add a local Flash to the WiFi subsystem, which increases the BOM cost. And at the very low price in WiFi this is just not acceptable anymore, the chipmaker would sell nothing. So there's no such local storage (except for a minimum bootloader maybe, and that could be in the chip in ROM) and the chip will load it's executable from the host at each reset. I've worked on systems (cellular, not WiFi) that do just that.
T-Mobile's HSPA+ 42 network hides a secret. While it delivers excellent sustained download speeds, those speeds don't look as fast in real life because of a very long time to negotiate the connection, which we measured as "time to first byte." This seemed to have to do with the network frequently switching between UMTS and HSPA+ modes when a connection was opened.
That explains the higher time to first byte compared to ATT HSPA. And then the latency on HSPA is higher than on LTE in general (plus on LTE the data connection is always on, not set-up on demand), as one key design goal of LTE was to allow a low latency (though there can be high variation depending on each operator core network, the radio part contribution is low with LTE).
And one guy opinion may not be representative of the whole of France. I happen to work in a start-up in France, many of my colleagues are foreigners for all around the world (not counting EU people as they're free to work here so not a problem for them). Yes there is some paperwork to do, but if you have a competent HR or go through external competent HR consulting it can be done. It could be more fluid and smoother for sure, nothing is perfect. But it's not as dire as often painted on the web. It adds delay and cost, but if the company pays decent salaries it's not a big factor. You have to justify hiring a foreigner (as in the US), but again if the job is technical it is usually not a big issue. There is high unemployment on average but as in many places there is also shortage of qualified people in some areas, and the administration is aware of this. Of course if you want to get foreigners on the cheap at cut rate salaries it's a different story, but then I'd say the issue is not the country law it's the employer.
It's also possible to fire people, and it has been made easier recently. The company has to provide typically 3 months of advance notice. But it's perfectly possible to just pay this and ask the employee to leave immediately (what we typically do where I work: if there's a problem with someone there's no point lengthening the issue). It's typical to pay a bit more, like 6 months severance. Bigger companies often go higher for old employees, 1 year is not unheard of. But for a start-up I would assume it's on the low end. The issue on firing is not that it cannot be done, but that there is significant legal uncertainty around it: the employee can turn against the employer and challenge the decision or severance amount. Some changes have been done to bring clarity there, I haven't followed the details. It's a true concern, but in high tech which is a small world with usually reasonable people, this is quite rare. I've had contacts with ex-employees working and I expect that to be typical. Everyone benefit by making this as unpleasant as possible (and it's never pleasant). The situation is very different when a manufacturing plant is closed, it can becomes messy with factories being occupied and that's what people tend to hear about. But when talking start-up the context is different.
There are many things to improve in France and many legitimate criticisms on the legal and administrative situation. Still I feel that some paint a blacker picture to justify their own unrelated problems, or having left the country (which is ok in itself: go and explore. No need to pretend you just left hell thought).
The fact is that I have more in common with you guys on /. than you might think. This is a community populated by engineers and technologists, not Luddites. You love great ideas. So do I. We may differ on the *economic value* of those great ideas, but I think this group debates innovation with the same passion and rigor that I do.
Now I'm concerned ;)
(emphasis mine)
Not very useful. You don't need for the device to provide its location with GPS, the network can deduce it with no specific device support (except complying with the cellular standard for replying to the network pages and request for cells measurements). Google "RF pattern matching": it's 100% network side, and is more accurate than GPS in urban and semi-urban locations so cutting the GPS won't help at all here (and most people live in such environments nowadays). RF pattern matching is already deployed in some 2G/3G networks, and is currently being specified for future LTE evolutions.
In rural environments using the device GPS is still the most accurate method, but even then the network can provide a reasonable location estimation based on the device reporting the receive power of its serving and surrounding cells (a standard function, which is used to drive handover). And cellular networks do support this as not all devices have GPS.
When in idle mode, a phone only transmit every few hours to indicate it's still "there". So transmission power is negligible and not a concern. It works as the GP explains (and it's the same principles for UMTS, LTE, WiMAX BTW). In idle, a phone will listen for a possible network paging that indicates an incoming call, SMS or data connection for a very short duration (a few milliseconds to a few tens, depending on the actual standard and implementation) every paging cycle. The maximum paging cycle is 2.56s for LTE and 5.12s for WiMAX and CDMA2000 for example. So it's regular, but only needs reception not transmission (and reception uses less power than transmission).
Then every few hours (3 or 4 is typical, that's standard dependent and configurable) the device will also transmit to indicate it's still in the expected paging area (the LA of GP for GSM). It's just a keep alive to detect a phone going off "uncleanly". In a clean power off, the phone is expected to sign-out to the network so that the network immediately redirects to the voice mail any incoming call. If an incoming call happens for an uncleanly shut down phone before it is detected as out by the network, the network will page it but after a while without the phone replying, it will also consider the phone out and redirect to voice mail. So it will be safe, but will take a bit more time.
Breaking the law, like an awful lot of people in France, and nobody cares. There's this old notion of "cadre" / "non-cadre" in French labor law, and if you're an engineering or master level you're a cadre. Now if you're a cadre there's a special regime where hours are not counted, and the "35 hours" law just amounted to a lump of extra vacation days. You're still supposed to do 48h max but nobody tracks this. A lot of companies are using this and making 50+ hours is quite common. Yes, it is illegal strictly speaking but nobody cares. By "a lot" I mean a lot of big companies in internationally competitive markets, and most small companies. In high tech this set-up is mostly a given.
;).
Now if you're in a big company, particularly if it's protected from international competition or has public roots, then it's a different story. You can be cadre and having to do 35 hours maximum, enforced with badging in some places with strong unions. One example I have in mind is doing military equipment and the French state is the main client.
And actually, even public companies themselves often break the law. Go to any public hospital and you'll find doctors and nurse pulling 60 to 70h work week just because there's not enough people to do the work and the hospitals can't afford to hire more. Everyone know the 35 hours are just not applicable in many contexts, and turn a blind eye to it.
The GGP story is maybe true but is just an anecdote in any case, you don't judge a whole country based on that. What you have to keep in mind is that 56% of the French economy is public economy, which is the highest in Europe. The public sector is then dominant, and rather protected, and can indulge in lazy practice (although there are hard workers too. They often get depressed after a while due to lack of recognition). But the others are working hard and efficiently enough to make France the n5 economy. And that's a statistically significant result not an anecdote
Ok, I haven't read TFA (hey, this is /.) but I've read a book addressing this topic: "Sustainable Energy — without the hot air", available for free on the web at http://www.withouthotair.com/ but well worth buying IMHO.
Nothing too surprising: renewable energy alone won't be able to address our current energy consumption level, so must be go with a reduction of our footprint (better efficiency when possible, but also less consumption too). Big problems are storage, and the large investments required to move to renewable in a big way. "Investment" here means money obviously, but also energy and that may create an "energy trap" if we don't anticipate enough the switch.
The author is a physicists at root. He doesn't address the economics of such a transition (big topic, but not his cup of tea) but focus on the physics part. This may be seen as a big limitation, and in a way it is, but the positive side is that he focuses on more solid ground where reaching a consensus based on core physics principle is possible (among people of good will at least). He's very good at illustrating in a simple yet solid way the opportunities and challenge of renewable energy sources. He also puts some boundaries on possible efficiency gains for different domains (transport, heating...) and this too is well explained and very informative.
Highly recommended.
None of what you list requires two separate OSs, although of course having two separate OSs is a way to implement this. Having users and users data isolation is perfectly possible on a multi-users OS and been done in practice, although not in a mobile environment. The independent management support can also be done by trusted software on the single OS.
An hypervisor really becomes the required approach if one must have two different OSs on the same device. There the multi-users OS falls short. But I wonder how practical it is in this context: you want the user to have similar environments in both professional and personal mode.
The hypervisor approach makes sense when two very different environments must share a CPU. For example, a very limited secure environment (limited to be small and easier to verify) and a regular OS. To simply split professional and user environments it seems overkill.
The pricing is not so much driven by the technology than by what operators can charge. It's particularly true for text, where the margin is really really huge and unrelated to technology. But as it's a geek site let's go over the tech now ;) All 3 use slightly different mechanisms.
Short messages (SMS, or text) piggy back over the signaling protocol.
With GSM and WCDMA 3G (3GPP standards), voice and data share the same radio network. But on the network side there are separate core networks for voice (CS domain, for Circuit Switched) and data (PS domain, for Packet Switched). In the CDMA world there are actually separate radio networks for voice (CDMA 1x) and data (EVDO). This is why you can't do both voice and data at the same time on most CDMA phones: it would require 2 radios, which adds cost and complexity. Whereas with 2G/3G, both goes over the same radio network so both can operate concurrently with a single radio.
Starting with 4G, or LTE in practice, there is still a single radio network as before but now the core (EPC, Evolved Packet Core) is also unified and built over IP. Voice over LTE (VoLTE) is not common yet but it's basically VoIP built on IMS. All is unified, but voice is of course prioritized over best effort data using QoS both in the RAN (radio access network) and EPC.