Assuming there isn't something that prevents the boot image from being replaced. See my other, more extensive, comment in this thread.

Don't be condescending. I'm not saying rebooting is a magic anything.

Whether or not this matters depends on the threat model and why the attacker is interested in patching the kernel. For example, one purpose would be to disable other kernel security features, such as SELinux, or dm-verity. Most SELinux rules are configured and the configuration can be altered by root, but some are compiled into the kernel and can only be modified by modifying the kernel. Altering the persistent kernel image may not be possible for a variety of reasons (read-only media, SecureBoot, etc.). In addition, in security-sensitive and mission-critical contexts an unexpected reboot may well be noticed.

I don't understand your assertion about SecureBoot. Are you referring to some known vulnerability of some particular secure boot system? Given a decent implementation of secure/verified boot, an attacker should not be able to convince the system to boot a modified kernel image, which means that run-time modification of the kernel is the only option if the attacker needs to bypass some kernel security enforcement.

In general, the security model of a high-security Linux system assumes that the kernel is more trustworthy than root. The ability for root to modify the running kernel invalidates this assumption, which most definitely is a security issue.

In the context of a system without mandatory access controls there may not be any reason to care, since once an attacker has obtained root there probably isn't any limit to what he can do.

Sure, if your concern is error, rather than malice. An attacker who gains root could use this to dynamically patch a backdoor into the running kernel. Rebooting the machine would potentially enable someone to notice.

As another poster noted, though, you can already dynamically patch the kernel for malicious purposes by loading a malicious module, assuming that hasn't been disabled. In contexts where security is crucial, I would disable both dynamic module loading and run-time patching.

The GP wasn't suggesting that excessive data was handed over, he said that an NSL could be used to demand installation of a backdoor. If I were a vendor, even one who really wanted to be cooperative, I'd balk at that, because the chances of something like a backdoor being discovered are too high. It would be actively sabotaging my customers, and not just to the NSA... a backdoor can't distinguish between users, it lets in anyone who figures it out. And, of course, if the existence of the backdoor were published it would do serious damage to my business.

Even companies who want to cooperate are going to be reluctant to do potentially business-destroying favors for the government. There would be a great deal of incentive to fall back on the law and refuse on the grounds that the law doesn't authorize such requests.

I'm skeptical that an Android device would survive running flat out for two years to crack a PIN. The heat and battery life issues I experienced when I tested it demonstrate clearly that mobile devices simply aren't designed to run full-speed 24x7.

Also, it should be pointed out that the attack I described is far from easy to carry out. Among other things, it requires dumping the contents of flash, which basically requires removing the flash chips from the mainboard without damaging it, then either putting the flash chips back or installing new flash, then the device must be unlocked, a custom, hostile OS flashed, and finally the attacker can start the multi-year process.

Note that the 630-day figure I cited is on average. It would take twice that long for a guaranteed break.

Finally, if you add one more character to your passcode (7-character alphanumeric), the crack time jumps from 630 days on average to 124 years.

I agree that Lollipop FDE still needs some improvement, but it's already quite good.

Your argument would carry more weight if the government who'd be trying Snowden weren't the same one he outed for violating its own laws, with the active collaboration of its judicial branch. Not to mention all of the recent fully-public sidestepping of due process for hundreds of other enemy combatants. Oh, and the torture, including of US citizens. And... do I really need to go on?

Snowden has extremely good reason to be skeptical of the fairness of a trial... or if he'd even get a real trial.

I see no evidence that Snowden didn't hand everything over to the Guardian et al, all at once, as he said he did. On what do you base your claim that he's still got something left?

In most cases these days it's a distinction without a difference.

I see this differently. Obj-C has the objects I need to interact with the framework. C++ has the speed, compatibility and expressive power I want. C has speed and compatibility, but lacks expressive power, which creates a lot of tedium and loses a lot of safety.

We agree on something :-)

I haven't really done much on Macs, but I did a lot of work on NeXTstep back in the day, and C++ was quite common in scientific computing there. Actually, what I saw a lot of was "Objective-C++"... they may have grown further apart, to the degree that this no longer works, but in the early 90s gcc allowed you to mix Objective-C and C++ constructs freely in the same code. So a common approach was to build everything in an OO fashion, but to choose between Objective-C and C++-style classes based on performance and flexibility tradeoffs. The result required you to be fluent in both, but that really just means being fluent in C++ because a C++ programmer can learn Objective-C in a day (which is something I respect about the language).

Cross-platform compatibility of C++ code is excellent these days, C++ can call low-level Apple APIs exactly as well as C, and there is no performance cost to C++ unless you choose it.

Unless you're concerned that you may need to target a platform not supported by a decent C++ compiler (which is really rare, given that gcc is basically everywhere), the only reason to choose C over C++ is personal preference or concern that some of the users of the code may not know C++.

It's not separate. In stock Lollipop there is only one password, and it's used both for FDE and for screen unlock. Some customized ROMs (e.g. CM) have separated it, which allows you to choose a strong boot password and a more convenient unlock password. Stock Android didn't go that direction because too many users would set a strong boot password which they only use once every few weeks and therefore forget, losing all of their data.

As mentioned by Gaygirlie, a big factor is the AES-NI instruction in the ARMv8 instruction set supported by your Nexus 6. It dramatically reduces the performance and power hit of AES operations.

(I'm a member Android Security team who worked on bits of Lollipop FDE)

This isn't completely true on Lollipop devices that have hardware-backed credential storage. (Well, it's not really "hardware-backed", but it's in a Trusted Execution Environment, typically ARM TrustZone.)

For Lollipop, a big change to FDE was the inclusion of a hardware-backed key in the key derivation function (KDF) for the FDE master key encryption key. This provides two benefits:

1) It means that a dump of the contents of your encrypted flash is useless without the device.

2) It means that brute force search of your PIN/pattern/password space is serialized and rate-limited by the performance of the device. In a way this means that faster devices are less secure, though we also apply a device-tuned scrypt function as part of the KDF, which compensates in the case of an attacker who tries to perform the entire attack on-device.

The best attack against Lollipop FDE, on a device with HW-backed credentials, is to dump the data from the device flash, then flash a custom OS which makes calls into the HW crypto to create an oracle, processing a stream of requests and returning the responses. Then you do a brute force attack with a mixture of on-device and off-device resources, computing the first scrypt function offline, then performing the on-device crypto operation, then taking the results of that and performing the second scrypt function offline, which you then use to try to decrypt the FDE master key, offline.

The fastest devices on the market today will perform the HW-backed crypto operation in about 50 ms. Assuming everything is pipelined properly, this is the brute force attempt rate: 20 attempts per second. With a four-digit PIN, this is negligible: the entire space can be searched in 8 minutes. However, a six-character alphanumeric password (random, all lowercase) would take 630 days, on average, to break. That's pretty reasonable security.

In theory. In practice it would take much longer than that. I tried running this test on a Nexus 9 and found the device kept throttling itself because it got too hot, plus even with a 2A charger it consumed more power than was being provided to it, so I had to stop when the battery died and wait for it to recharge.

Pre-Lollipop, and even on Lollipop devices that lack HW-backed crypto, you can conduct the entire attack off-line, parallelized, on however much hardware you care to throw at it. I can't make any promises about the future, but I will say that I, personally, really want to significantly improve Android FDE in the future. I have changes in mind that will make brute force essentially impossible, unless you can break into the Trusted Execution Environment.

Bah. Outright falsehood-pushing "journalism" is as old as journalism, and the online version of it as old as online journalism. Wikipedia has been abused as long as it has existed, and the Woozle Effect is also nothing new -- indeed the name and awareness of the phenomenon predates the existence of ARPANET, much less the Internet.

What has changed that's relevant? The existence of mobile devices? Bah.

Political correctness is new since 2005? Ummm, let me guess, you're under 30, aren't you?

Which was also true before 2005.

Also true before 2005.

I'll stop here, but nothing you mention was any different previously.

This exact same complaint was common before it was shown that Wikipedia is on par with dead tree encyclopedias. What makes it more true now than it was then?