Follow Slashdot stories on Twitter


Forgot your password?

Comment Re:FUD (Score 1) 73

Only data is stored in the secure enclave from what I understand. The secure enclave isn't an environment as it is storage area

It's a bit more complicated than that. The secure enclave offers services to the OS, for example you can give it a digital signature and ask if that signature was signed with a trusted key, or you can give it some data and ask it to decrypt or encrypt it with one of the stored keys. It needs to do these things so that the storage can be write-only: if you are able to pull the keys out of the secure element then you may as well do the whole thing in software. A number of Android phones do something similar using TrustZone (though recent TrustZone attacks give me less confidence in that than I'd have had a year ago), but the Apple implementation is a separate ARM core running its own OS and communicating with the main OS.

Your scenario relies on the connection between the camera and OS being open to attack and not secured.

Well, one of two attacks: the OS is fully compromised (in which case you can't get into the secure element, but you can see anything that the OS can see) or the OS exposes more information to userland than you might want it to.

We'll need more details but the current fingerprint scanner is secured from tampering from what I know.

The difference with the fingerprint scanner is that the only useful thing that you can do with the fingerprint scanner is scan fingerprints, so the OS can expose a simple interface that is simply 'is this a valid fingerprint'. This is actually a slightly too narrow interface for a lot of uses. For example, I might want several people to be able to unlock my iPad with their fingerprints, but no one other than me to be able to unlock my Internet banking app, and iOS currently doesn't provide this functionality, just a 'does this finger belong to an authorised person' query. In contrast, the distance-sensing camera is probably very useful for augmented reality things, where you actually do need to expose the depth information to userspace. This makes it much harder to prevent a malicious app from simply doing a face scan and uploading it to the NSA / FSB / Google / Flat Earth Society.

Comment Re:FUD (Score 1) 73

That there will be widely-distributed NSA malware that sneaks it's way onto iPhones and compromises the secure enclave and FaceID hardware?

As I understand it, the distance data from the camera isn't routed directly to the secure enclave, it's available for AR applications. This means that it doesn't really matter to a malware author if they can't get into the secure enclave: they can just lift the data directly from the camera the next time that you look at the screen.

Comment Re:Trust isn't the problem (Score 1) 191

Self-driving cars aren't the problem there, laws that most people violate are. If driving on a road safely means violating the laws that govern that road, then the laws are badly broken and should be fixed. Having a significant percentage of motorists actually follow the rules and cause mayhem as a result would be the best way of getting them fixed.

Comment Re:Evil Spell checker (Score 1) 180

That evil spell checker is scanning all the documents I type, and it's even scanning things outside my word processor!

My spell checker doesn't have network connectivity and scans only things on my local system. It is entirely under my control and none of the terms that it learns are transmitted externally. Something like Cortana would be very useful if it worked the same way: learning things about my workflow on my own device, not in someone else's computer.

Comment Re:It may not come from the USA (Score 1) 304

Speak for yourself on that one; the only people I've met that at actually like the metro interface on phones are all big fans of Microsoft. People who are indifferent towards Microsoft have never liked it in my experience.

To add another counter-annecdote:

I use macOS and FreeBSD almost exclusively on real computer, have an iPad and an Android phone (I did have an Asus TransformerPad, but it had crappy vendor support and went into an unrecoverable boot loop - never buying Asus again). My partner's Nokia 1020 (Windows Phone 8.1) was the only mobile device whose UI has not irritated me. It hasn't had security updates for a while and the third-party app support is dire, so she recently replaced it with an Android phone (running LineageOS). She much preferred the Windows Phone UI. A couple of years ago, she got a new Dell laptop that came with Windows 8.1 and an option to install Windows 7. She lasted two weeks with 8.1 before the Metro UI pissed her off there before having me wipe it and install Windows 7. The Dell died recently, so she's now using my old MacBook Pro.

I don't think either of us would be classified as 'big fans of Microsoft'. I should probably add a disclaimer that I do some work with Microsoft Research (and a tiny bit with a couple of product groups), relating to security and toolchains. I found it amusing when I visited Redmond a little while ago that my Mac laptop was the first machine that the group I was visiting had seen that worked with the projector in the meeting room we were in...

Comment Re:Drivers problem (Score 2) 304

It's worth noting that the next version of Android is trying to fix some of these issues, by providing stable kernel interfaces for device drivers, allowing the kernel to be updated independently of the device vendor. That doesn't help when there's a security vulnerability in a device driver that the vendor won't fix, but it does help when there's an issue elsewhere in the kernel. I suspect that part of the motivation for this is to allow Google to use Android device drivers with Magenta.

The big problem with Android has been that Google has developed its own software engineering practices that work well internally, but don't work in any other setting. The Google model is to have a trunk branch that is deployed into production as soon as it passes CI tests. They have large-scale refactoring tools that can run over the millions of lines of code in their internal codebase very quickly. This means that they don't need to design good APIs from the start, they just throw something together and refactor it later. Unfortunately, this makes it impossible to support multiple versions. When there's a security bug fixed in Chromium, it's often impossible to figure out when the bug was introduced or to back-port the fix. Their only solution is to update everyone to the latest Chromium, which is a problem if it doesn't support an older version of Android. Much of the Android development works like this, which makes updates hard.

Comment Re:*BSDs are rendering Linux irrelevant. (Score 4, Informative) 114

FreeBSD itself is -- as far as I know -- "managed" by the FreeBSD Foundation, and, in turn, that Foundation is managed by the FreeBSD developers.

Not quite. The FreeBSD Foundation is entirely separate from the FreeBSD Project. The FreeBSD Project is managed by the core team, which is a set of 9 people that are elected by 'active' contributors, defined as people who have committed something in the last year (I think - I'd have to double check the project bylaws for the exact time). The Foundation board is self-selected (i.e. board members are appointed by existing board members). There is usually at least one person who is both on the board of the Foundation and the Core team, though not always. The Foundation employs a few full time people and a lot of contractors to contribute to bits of the project that no one personally wants to work on, no single company wants to contribute, but which everyone thinks are important. This is typically guided by the Core Team. This structure protects the project's independence from the Foundation's financial weight (the Foundation's turnover is $1-2M/year). The Core Team decides who is allowed commit rights (usually in terms of granting this right, in very rare examples by taking it away), so the most the Foundation can do is pay someone to write code, they can't force the project to accept it.

The Foundation also handles a lot of vendor relations. Often, multiple vendors want the same thing, but no one wants to pay for all of it. The Foundation helps in these situations by getting different companies to pay for part of something. For example, ARM and Cavium jointly funded to the ARMv8 bring-up (ARM likes having a BSD-licensed reference implementation, because companies like Apple and Microsoft won't touch GPL'd code, Cavium wants to sell chips to companies like Juniper that use FreeBSD), but the Foundation organised the people to do the work (and others to do code review). They also do a lot of outreach. For the last few years, they've employed the release engineer, which is an incredibly annoying and high-stress job that it's hard to find volunteers for (and hard for companies to want to do, because the big downstream consumers typically use their own internal release process).

Disclaimer: I was on the Core Team for two terms, but this post contains personal opinions that may not reflect the opinions of the FreeBSD Project or the FreeBSD Foundation.

Comment Re:Some notes on branch prediction vs conditional (Score 1) 161

However, if you are aiming for high-end systems conditional move may not be that big of a deal. See for example the following analysis from Linus Torvalds regarding cmov

The problem with Torvalds' analysis (which is otherwise pretty good and worth reading) is that it only looks at local effects. The problem with branches is not that they're individually expensive, it's that each one makes all of them slightly more expensive. A toy branch predictor is basically a record of what happened at each branch, to hint what to do next time. Modern predictors use a variety of different strategies (normally in parallel) with local state stored in something like a hash table and global state shared with all branch locations. If the branch that you've added happens to hit the same table entry as another, then it may cause mispredictions elsewhere. This is horrible to try to model, because you have a performance cliff that moves depending on code layout (which is part of the reason why randomising the order of functions in a program can have around a 20% impact on performance).

The probability of misses increases based on branch density. Short branches have another issue, which is that typical superscalar processors don't make per-instruction predictions, they make predictions per fetch granule. If you have an 4-way superscalar processor, then you get one prediction for each 4 instructions. If you have two branches in there, then they'll be predicted together. This means that you really don't want a short branch immediately followed by another branch (or following a not-taken branch) unless you're really careful about alignment.

Note that some processors have spectacularly bad implementations of either branch prediction or conditional moves. PowerPC is notorious for this, where the performance difference between the two representations varies hugely between different iterations by the same vendor (and more between vendors), so compiler tuning is almost impossible.

If the ARM instruction set was designed today however it is likely that the designers would not go crazy with conditional execution since the bits could be better used for something else

You can see this with ARMv8. Most of the predication is gone, there are basically just conditional moves (conditional select) and conditional branches. There was apparently a lot of argument about whether to allow conditional loads. These are very useful because most other conditional patterns can be reduced to a conditional move: calculate both sides and select the one that you wanted, but is the condition is 'pointer is not null' then you can't speculatively load and then decide not to take the trap. Another proposed alternative is to have a non-trapping load (i.e. one that returns zero if that load would trap), though this can be difficult in the presence of swapping (the processor doesn't know the difference between a not-present page and a not-present-now-but-can-be-swapped-in page).

Comment Re:Let me know when Android gets 41MP Pureview. (Score 1) 135

My partner just replaced her Nokia 1020. It was quite depressing how much better the 1020 was than the replacement in almost all regards. She'd probably have kept it if not for the fact that it didn't speak a modern version of TLS and so was breaking with an increasing number of web sites. It's a shame no one managed a decent Android port to the 1020 - I'd love to put LineageOS on it.

Slashdot Top Deals

"Life is a garment we continuously alter, but which never seems to fit." -- David McCord