You could always just go to Settings > General > Passcode > Simple Passcode, check "No," and then "use whatever they enter, no matter how long." Of course then you wouldn't have the had then fun of writing the last four paragraphs...
Would you have preferred if I had written "Apple does not actually need a backdoor per se in order toto perform the actions mentioned in the article?" My point was that what law enforcement is asking does not require a backdoor, since a lot of posters seem to think it implies there must be one. Furthermore, security researchers can and do look and see how all the signing keys etc are structured on running systems even without source code access. Is there a chance there is still something hidden, sure, but there is also a chance someone snuck a root exploit into an innocuous looking commit in an important open source project. Source code access generally does lead to more trustworthy code, but it isn't so black and white as you claim. In the end we depend on people to validate what we use, and just having the source available is not in and of itself validation.
As for the rest of the your comments, you simply don't know what you are talking about, but you would if you had actually read the PDF I linked. First off, rewriting the bootloader via JTAG is not an option on a lot of SoC's and embedded devices once they have had some of their internal fuses blown. From the PDF:
"When an iOS device is turned on, its application processor immediately executes code from read-only memory known as the Boot ROM. This immutable code is laid down during chip fabrication, and is implicitly trusted. The Boot ROM code contains the Apple Root CA public key, which is used to verify that the Low-Level Bootloader (LLB) is signed by Apple before allowing it to load."
So the stuff in flash might be rewritable, but it won't be executed unless it is signed. Reading the raw flash is also completely useless, because all data written to it is AES encrypted via a DMA engine in the SoC that uses various different keys, but all of them are tied to or derived from values fused into the processor and not readable via software or JTAG (they are routed directly to the DMA block and never exposed). That means the brute force needs to be attempted on the SoC in that particular iPhone, or you need to drastically increase the search space. A suitably advanced attacker code probably also obtain the SoC keys by decapping the chip, dying it, and looking at the fuses with a scanning electron microscope, but I generally don't worry about an attacker with sorts of resources; they would probably just beat my PIN out of me...
Apple does not have a backdoor per se. But Apple does have the device signing key and can thus completely compromise the chain of trust. The only thing stopping you from compromising a phone with a 4 digit passcode in seconds by brute forcing it is the fact that software rate limits attempts, and the option to have it delete its intermediary keys after 10 bad attempts. If you have the ability to load an arbitrary kernel it is trivial to bypass both of these, but only Apple has that capability, at least on devices without jailbreaks that can be executed them while locked.
Influenza causes only a small minority of all deaths in the U.S., even among senior citizens,
36,000 die of complications from the flu annually in the US. That's very nearly as many as die from car accidents.
It is entirely accurate to say flu deaths are a minority of all deaths. According to the CDC in 2006 there were 56,326 deaths from Influenza and Pneumonia, out of a total of 2,426,264 deaths. If we assume all of those 56,326 deaths were from the flu, that is a grand total of 2.3% of all deaths from the flu. If the number is actually 36,000 (which sounds reasonable once you factor out Pneumonia) then it is only ~1.5%.
Of course that has nothing to do with the accuracy of the story, but lets not jump on the parts where we actually have reasonable data.
Erlang is very cool, but it is not designed to replace C. In fact, it is designed to handle some bits of the higher level concurrency stuff and call out to C "drivers" for level work. Apparently Ericsson's switch code has almost as much C/C++ code as Erlang code. GCD addresses concurrency in problem spaces Erlang is completely inappropriate for, just like Erlang plays in spaces that GCD is not appropriate for. They are different tools for different jobs.
No, what the actual situation is is that a block consists of some number of pages (currently on the flash used in SSDs it tends to be 128). The pages can be written individually, but only sequentially (so, write page 1, then page 2, then page 3), and the pages cannot be erased individually, you need to erase the whole block.
The consequence of this is that when the FS says "Write this data to LBA 1000" the SSD cannot overwrite the existing page it is stored without erasing its block, so instead it find somewhere else to store it, and in its internal tables it marks the old page as invalid. Later when the GC is sweeping blocks for consolidation the number of valid pages is one of the criteria it uses to figure out what to do. If a block has very few valid pages and has been completely filled then those pages will probably be copied to another block that is mostly valid and the block the data was originally in will be erased.
There is an extensions that was recently added to ATA, the TRIM command. The TRIM command allows an OS to specify a blocks data is no longer useful and the drive should dispose of it. No productions support it, but several beta firmwares do. There are also patches for the Linux kernel that adds support to the black layer along with appropriate support to most filesystems. Windows 7 also has support for it.
There is a lot of confusion about this on the OCZ boards, with people thinking GC somehow magically obviates the needs for TRIM. As you pointed out the GC doesn't know what is data and what is not with respect to deleted files in the FS. I wrote a blog post (with pictures and everything) explaining this just a few days ago
I am pretty certain you can get a downloaded copy of the.AZW to store on your own system, since that is the mechanism for loading books if you are not in an area it gets cell coverage. From the documentation it appears you can also copy the books off the device. They will only work on a device registered to you, but if you want to keep the bits instead of depending on Amazon there does not appear to be any impediment to doing that.
The graphical version takes slightly fewer resources. You have to run a single buffer through an RLE decompression routine directly out into a linear mapped framebuffer. To display text you actually have to use all of the console code. Remember, there is no hardware console, so you have to actually do all the text element positioning in software, and the graphics card is in exactly the same mode either way.
It does not take appreciably more resources either way, and both code paths are fairly simple and well tested.
Picture this scenario. My parents just bought a flat panel EDTV because they are concerned about space. They want to hook it up to a DVD player. Currently they would use between 3 and 5 cables, a number of which are physically identical. With HDMI they use one.
The fact that HDMI allows HD signals and the fact that it is a single cable are two orthogonal facts. Just because it is on the highend now does not mean it will be there forever. There are plenty of people buying new ED/HD sets who are not audio/videophiles, who will use the built in speakers, and will be happy with the simplified interface. And it means fewer tech support calls to me from my mother who is upset with her new TV purchase;-)
There is also something appealing about only needing one type of cable in highend setups. It means less types of things to buy. Checkout this receiver. Using only 5 (13 if you count the speakers and subwoofer) cables you can hook an OTA STB, an Upscaling DVD player, a Satellite receiver, and PVR, while still guaranteeing correct clockskew on the scaler (since the audio and video are bundled). I bet if they threw out all the analog ports and signal processors that are only used in the analog path they could shave a bunch of money off it too.
HDMI does a few things right. Adding audio is very useful for a lot of people (one cable is always easier than than 2 or 3). They also tweaked the signaling to run longer ranges, and added support for YUV (if you thing YUV support is not a big deal then do searches for the whole PC RGB/Studio RGB crush and push issues people have with DVI DVD players).
There are tradeoffs of course. In order to reduce the connector size they eliminated the analog link and the second digital link. I think the improved signaling allows them to run their digital interface a little faster than DVI, so the second link may not be a huge issue. The lack of an analog link means that you cannot make a cheap cable only VGA adapter like you can for DVI-I, which seems like a pretty big issue if somebody were actually going to try to push computer adoption of this, especially for laptops.
If it wasn't for HDCP it would be a pretty nice improvement over DVI for many users.
The problem is libraries. A lot of libraries use mmap (think image loading libraries). It is generally not wise to use signal handlers since they can get stomped by the main program installing signal handlers.
I know that a lot of people think it is a great thing, but it is really problematic. It makes great sense on systems that have fixed disks, but once you start having transient filesystems (network filesystems or removable drives) it becomes a real problem. If a filesystem is removed then programs may segfault since the mapping disappears. All other entry points for this sort of thing fail at a system call (read or write) which allows for graceful recovery. Conceivably the OS could inform the user or insert a zero filled backing, but that could lead to data corruption.
This is a particularly bad problem for desktop systems, where the users are not experts. For server or cluster systems it is not an issue.
But in general end to end security models like this have had trouble because it has not been possible to get central signing in a way that can be administrated cheaply enough to allow wide deployment. I fear that this will fester in the same acceptance purgatory as DNSSEC, for roughly the same reasons
HFS+ is extent allocated, so you will only ever allocate single blocks if the file is smaller than a single block and closed before the first bit of the file is flushed, or the disk is pathologically fragmented
Mac OS X absolutely does deferred writes and preallocation when appropriate
The PowerPC absolutely has multiply instructions (mulhwx, mulhwux, mulli, mullwx)
Now we just need support for analog PVR cards
on
PVR For Linux
·
· Score: 1
I have been following this project for a while now, and I would be using it if there was anyway to use a WinTV-PVR or Creative Labs Digital VCR card with Linux. Unfortunately there don't seem to be any drivers for tuners with integrated MPEG2 encoders.
Most commercial developer's understand how to cope with these sorts of things. Lots of people have access source code they are not supposed to share, as well as code that they have the freedom to work on. Before Jordan worked for Apple he worked for WindRiver/BSDi/Walnut Creek. There he had access to the BSD/OS source code. It was never an issue.
Just for reference, I was an opensource developer who was eventually given commit access to Darwin, and later I was hired by Apple, so I have some personal experience with this situation, but feel free to take my opinions with a grain of salt;-)
That would be a mistake. First off, TiVo is probably pissed about the MPEG. They *will* be pissed about the Program Guide. For reference, hacking the program guide is currently trivial. And there are legitimate uses for it (Tridge makes his own for australia, etc).
What could TiVo do: They have a crypto chip on the board, I am not sure what its bandwidth is, but they could concievably run everything through it (including MPEG). The CPU may be weak, but ASICs are a beautiful. There are any number of other options.
This was bound to happen. The replays are already extractable... time to wait for the ECM.
As an active contributer to Darwin (I have cvs commit access), I would just like to say I think the article is silly and inane. Apple attempts to give back all of its updates upstream, it makes their life simpler. Sometimes it doesn't quite work out immediately, but it generally does).
The general policy, as far I can tell, is to keep everything under the originating license. The one excpetion to this was when the released the original kernel code they put an APSL on everything, just in case. If you want some changes Apple made to a file that did not originate at Apple, but is under APSL, ask, they will probably relicense it.
When I committed a bunch of code from FreeBSD into the kernel recently, I asked, and was specificly told to leave it under the original BSD license.
Apple tend to contribute to the projects it takes from.
Louis
(On a side note, while I do not currently work for them, I have accepted a job offer from Apple. I have been involved with their Open Source development since well before this occured, but I figured I would be entirely open about).
Quite frankly, I would argue the problem with the netware client is not Apple's problem. If you follow the guidelines for writing extensions, things tend to work. The Netware extentions were always a POS, and that it not Apple's fault, they don't write them.
Cleartext passwords are awful. Apple does not use them in any of their current Appleshare/IP products. Appletalk has been deprecated for a while, though I would like to point out that while it is chatty and ugly, it does have its benefits. Until very recently most laserprinters had hideous tcp stacks onboard. We had one printer here that took something like 5 times as long to print a job over lpr and tcp/ip as it tooke to print over appletalk.
Your right though, OS X is much better, and a heck of a lot more stable.
I have gone to, and worked for CTY. I have to say they traditionally have had a spectacular introductory computer science course. In recent years most of the people responsible for designing a lot of their (IMHO) better courses (such as Theoretical Introduction to Computer Science, Number Theory, Digital Logic, and Introduction to Neuroscience) have left CTY for a number of reasons, including sometimes significant philosophical differences with the administration about how the courses should be run. In recent years it looks like they have added a number of new course, such as Cryptography, but I worry that people going are in essence buying what was recently a good brand name, as opposed to a good education experience.
Slashdot Mirror
You could always just go to Settings > General > Passcode > Simple Passcode, check "No," and then "use whatever they enter, no matter how long." Of course then you wouldn't have the had then fun of writing the last four paragraphs...
Would you have preferred if I had written "Apple does not actually need a backdoor per se in order toto perform the actions mentioned in the article?" My point was that what law enforcement is asking does not require a backdoor, since a lot of posters seem to think it implies there must be one. Furthermore, security researchers can and do look and see how all the signing keys etc are structured on running systems even without source code access. Is there a chance there is still something hidden, sure, but there is also a chance someone snuck a root exploit into an innocuous looking commit in an important open source project. Source code access generally does lead to more trustworthy code, but it isn't so black and white as you claim. In the end we depend on people to validate what we use, and just having the source available is not in and of itself validation.
As for the rest of the your comments, you simply don't know what you are talking about, but you would if you had actually read the PDF I linked. First off, rewriting the bootloader via JTAG is not an option on a lot of SoC's and embedded devices once they have had some of their internal fuses blown. From the PDF:
"When an iOS device is turned on, its application processor immediately executes code from read-only memory known as the Boot ROM. This immutable code is laid down during chip fabrication, and is implicitly trusted. The Boot ROM code contains the Apple Root CA public key, which is used to verify that the Low-Level Bootloader (LLB) is signed by Apple before allowing it to load."
So the stuff in flash might be rewritable, but it won't be executed unless it is signed. Reading the raw flash is also completely useless, because all data written to it is AES encrypted via a DMA engine in the SoC that uses various different keys, but all of them are tied to or derived from values fused into the processor and not readable via software or JTAG (they are routed directly to the DMA block and never exposed). That means the brute force needs to be attempted on the SoC in that particular iPhone, or you need to drastically increase the search space. A suitably advanced attacker code probably also obtain the SoC keys by decapping the chip, dying it, and looking at the fuses with a scanning electron microscope, but I generally don't worry about an attacker with sorts of resources; they would probably just beat my PIN out of me...
Apple does not have a backdoor per se. But Apple does have the device signing key and can thus completely compromise the chain of trust. The only thing stopping you from compromising a phone with a 4 digit passcode in seconds by brute forcing it is the fact that software rate limits attempts, and the option to have it delete its intermediary keys after 10 bad attempts. If you have the ability to load an arbitrary kernel it is trivial to bypass both of these, but only Apple has that capability, at least on devices without jailbreaks that can be executed them while locked.
If you want to make sure your data is secure then use a full password and not a PIN, which will make Apple's ability to run code moot since brute forcing it will not be practical any more. You can look at https://acg6415.wikispaces.com/file/view/iOS_Security_May12.pdf/343490814/iOS_Security_May12.pdf for more info on the actual architecture.
Not that it really changes your point much, but they were given a 250K cash bonus AND a stock grant.
36,000 die of complications from the flu annually in the US. That's very nearly as many as die from car accidents.
It is entirely accurate to say flu deaths are a minority of all deaths. According to the CDC in 2006 there were 56,326 deaths from Influenza and Pneumonia, out of a total of 2,426,264 deaths. If we assume all of those 56,326 deaths were from the flu, that is a grand total of 2.3% of all deaths from the flu. If the number is actually 36,000 (which sounds reasonable once you factor out Pneumonia) then it is only ~1.5%.
Of course that has nothing to do with the accuracy of the story, but lets not jump on the parts where we actually have reasonable data.
Erlang is very cool, but it is not designed to replace C. In fact, it is designed to handle some bits of the higher level concurrency stuff and call out to C "drivers" for level work. Apparently Ericsson's switch code has almost as much C/C++ code as Erlang code. GCD addresses concurrency in problem spaces Erlang is completely inappropriate for, just like Erlang plays in spaces that GCD is not appropriate for. They are different tools for different jobs.
No, what the actual situation is is that a block consists of some number of pages (currently on the flash used in SSDs it tends to be 128). The pages can be written individually, but only sequentially (so, write page 1, then page 2, then page 3), and the pages cannot be erased individually, you need to erase the whole block.
The consequence of this is that when the FS says "Write this data to LBA 1000" the SSD cannot overwrite the existing page it is stored without erasing its block, so instead it find somewhere else to store it, and in its internal tables it marks the old page as invalid. Later when the GC is sweeping blocks for consolidation the number of valid pages is one of the criteria it uses to figure out what to do. If a block has very few valid pages and has been completely filled then those pages will probably be copied to another block that is mostly valid and the block the data was originally in will be erased.
There is an extensions that was recently added to ATA, the TRIM command. The TRIM command allows an OS to specify a blocks data is no longer useful and the drive should dispose of it. No productions support it, but several beta firmwares do. There are also patches for the Linux kernel that adds support to the black layer along with appropriate support to most filesystems. Windows 7 also has support for it.
There is a lot of confusion about this on the OCZ boards, with people thinking GC somehow magically obviates the needs for TRIM. As you pointed out the GC doesn't know what is data and what is not with respect to deleted files in the FS. I wrote a blog post (with pictures and everything) explaining this just a few days ago
I am pretty certain you can get a downloaded copy of the .AZW to store on your own system, since that is the mechanism for loading books if you are not in an area it gets cell coverage. From the documentation it appears you can also copy the books off the device. They will only work on a device registered to you, but if you want to keep the bits instead of depending on Amazon there does not appear to be any impediment to doing that.
As always, RTFM.
The graphical version takes slightly fewer resources. You have to run a single buffer through an RLE decompression routine directly out into a linear mapped framebuffer. To display text you actually have to use all of the console code. Remember, there is no hardware console, so you have to actually do all the text element positioning in software, and the graphics card is in exactly the same mode either way.
It does not take appreciably more resources either way, and both code paths are fairly simple and well tested.
Picture this scenario. My parents just bought a flat panel EDTV because they are concerned about space. They want to hook it up to a DVD player. Currently they would use between 3 and 5 cables, a number of which are physically identical. With HDMI they use one.
;-)
The fact that HDMI allows HD signals and the fact that it is a single cable are two orthogonal facts. Just because it is on the highend now does not mean it will be there forever. There are plenty of people buying new ED/HD sets who are not audio/videophiles, who will use the built in speakers, and will be happy with the simplified interface. And it means fewer tech support calls to me from my mother who is upset with her new TV purchase
There is also something appealing about only needing one type of cable in highend setups. It means less types of things to buy. Checkout this receiver. Using only 5 (13 if you count the speakers and subwoofer) cables you can hook an OTA STB, an Upscaling DVD player, a Satellite receiver, and PVR, while still guaranteeing correct clockskew on the scaler (since the audio and video are bundled). I bet if they threw out all the analog ports and signal processors that are only used in the analog path they could shave a bunch of money off it too.
Louis
HDMI does a few things right. Adding audio is very useful for a lot of people (one cable is always easier than than 2 or 3). They also tweaked the signaling to run longer ranges, and added support for YUV (if you thing YUV support is not a big deal then do searches for the whole PC RGB/Studio RGB crush and push issues people have with DVI DVD players).
There are tradeoffs of course. In order to reduce the connector size they eliminated the analog link and the second digital link. I think the improved signaling allows them to run their digital interface a little faster than DVI, so the second link may not be a huge issue. The lack of an analog link means that you cannot make a cheap cable only VGA adapter like you can for DVI-I, which seems like a pretty big issue if somebody were actually going to try to push computer adoption of this, especially for laptops.
If it wasn't for HDCP it would be a pretty nice improvement over DVI for many users.
Louis
The problem is libraries. A lot of libraries use mmap (think image loading libraries). It is generally not wise to use signal handlers since they can get stomped by the main program installing signal handlers.
I know that a lot of people think it is a great thing, but it is really problematic. It makes great sense on systems that have fixed disks, but once you start having transient filesystems (network filesystems or removable drives) it becomes a real problem. If a filesystem is removed then programs may segfault since the mapping disappears. All other entry points for this sort of thing fail at a system call (read or write) which allows for graceful recovery. Conceivably the OS could inform the user or insert a zero filled backing, but that could lead to data corruption.
This is a particularly bad problem for desktop systems, where the users are not experts. For server or cluster systems it is not an issue.
But in general end to end security models like this have had trouble because it has not been possible to get central signing in a way that can be administrated cheaply enough to allow wide deployment. I fear that this will fester in the same acceptance purgatory as DNSSEC, for roughly the same reasons
I don't even no where to begin.
I have been following this project for a while now, and I would be using it if there was anyway to use a WinTV-PVR or Creative Labs Digital VCR card with Linux. Unfortunately there don't seem to be any drivers for tuners with integrated MPEG2 encoders.
Louis
Yes. And I have been pushing for it for a long time ;-)
Louis
Most commercial developer's understand how to cope with these sorts of things. Lots of people have access source code they are not supposed to share, as well as code that they have the freedom to work on. Before Jordan worked for Apple he worked for WindRiver/BSDi/Walnut Creek. There he had access to the BSD/OS source code. It was never an issue.
;-)
Just for reference, I was an opensource developer who was eventually given commit access to Darwin, and later I was hired by Apple, so I have some personal experience with this situation, but feel free to take my opinions with a grain of salt
Louis
That would be a mistake. First off, TiVo is probably pissed about the MPEG. They *will* be pissed about the Program Guide. For reference, hacking the program guide is currently trivial. And there are legitimate uses for it (Tridge makes his own for australia, etc).
What could TiVo do: They have a crypto chip on the board, I am not sure what its bandwidth is, but they could concievably run everything through it (including MPEG). The CPU may be weak, but ASICs are a beautiful. There are any number of other options.
This was bound to happen. The replays are already extractable... time to wait for the ECM.
Louis
As an active contributer to Darwin (I have cvs commit access), I would just like to say I think the article is silly and inane. Apple attempts to give back all of its updates upstream, it makes their life simpler. Sometimes it doesn't quite work out immediately, but it generally does).
The general policy, as far I can tell, is to keep everything under the originating license. The one excpetion to this was when the released the original kernel code they put an APSL on everything, just in case. If you want some changes Apple made to a file that did not originate at Apple, but is under APSL, ask, they will probably relicense it.
When I committed a bunch of code from FreeBSD into the kernel recently, I asked, and was specificly told to leave it under the original BSD license.
Apple tend to contribute to the projects it takes from.
Louis
(On a side note, while I do not currently work for them, I have accepted a job offer from Apple. I have been involved with their Open Source development since well before this occured, but I figured I would be entirely open about).
I have a Darwin 1.2 machine that has been up for over 70 days now ;-)
Quite frankly, I would argue the problem with the netware client is not Apple's problem. If you follow the guidelines for writing extensions, things tend to work. The Netware extentions were always a POS, and that it not Apple's fault, they don't write them.
Cleartext passwords are awful. Apple does not use them in any of their current Appleshare/IP products. Appletalk has been deprecated for a while, though I would like to point out that while it is chatty and ugly, it does have its benefits. Until very recently most laserprinters had hideous tcp stacks onboard. We had one printer here that took something like 5 times as long to print a job over lpr and tcp/ip as it tooke to print over appletalk.
Your right though, OS X is much better, and a heck of a lot more stable.
I know, I taught several of the lectures for the Boston Alumni Group last year ;-)
Louis
I have gone to, and worked for CTY. I have to say they traditionally have had a spectacular introductory computer science course. In recent years most of the people responsible for designing a lot of their (IMHO) better courses (such as Theoretical Introduction to Computer Science, Number Theory, Digital Logic, and Introduction to Neuroscience) have left CTY for a number of reasons, including sometimes significant philosophical differences with the administration about how the courses should be run. In recent years it looks like they have added a number of new course, such as Cryptography, but I worry that people going are in essence buying what was recently a good brand name, as opposed to a good education experience.