4 ms·

Now all I can think of is #droidrage

mtgx 14y ago
Oh yeah, Microsoft's vitriolic campaign against Android. But this is not about Android per se, but about Samsung's drivers for the camera, and giving camera full access to root, because they were lazy.
- mikeash 14y ago
  I'm conflicted. On one hand, this is definitely Samsung's fault, not Android in general. On the other hand, an OS with more rigorous requirements for OEMs could have prevented this.
  - mdwrigh2 14y ago
    I'm curious what requirement you think would prevent this.
    - cube13 14y ago
      Apple's approach(no OEMs at all, known hardware) would mitigate the problem somewhat. But that doesn't stop lazy idiots from screwing up at Apple, and it doesn't work for anyone that's providing a general-purpose OS. That's really about it. This is a kernel-level driver issue, caused by a lazy Samsung coder. Unfortunately, the drivers need that level of access, since they're used by Android to actually work. I'd say normal *nix kernel security practices should apply here, but that still doesn't stop lazy idiots...
      - mdwrigh2 14y ago
        So the "more rigorous requirements for OEMs" is "no OEMs at all"? Seems a little like throwing the baby out with the bathwater. Besides, part of the point of Android is having an OS which allows for companies like Samsung to build their own variants. Also, the problem isn't unknown hardware (as you would suggest by saying they should use "known hardware"). If it was an issue where they unknowingly left the hardware in some strange debugging state so that userland could query the it for restricted information, then it would be an issue with unknown hardware. In this case they directly and intentionally provided unprotected access to all of memory. That's just bad engineering.
        cube13 14y ago
        >Also, the problem isn't unknown hardware (as you would suggest by saying they should use "known hardware"). No, the failure point here is, essentially, unknown hardware from Google's perspective. Android is not coded to work specifically with Samsung's configurations or hardware, so Samsung needs to provide drivers. As for "more rigorous" requirements, I don't think it's too hard to have the requirement that all drivers follow standard *nix security practices. That would have stopped this completely. So the solution is to either not allow custom OEM builds(which, as I noted, isn't possible for Android).
        mdwrigh2 14y ago
        > No, the failure point here is, essentially, unknown hardware from Google's perspective. Android is not coded to work specifically with Samsung's configurations or hardware, so Samsung needs to provide drivers. As for "more rigorous" requirements, I don't think it's too hard to have the requirement that all drivers follow standard * nix security practices. That would have stopped this completely. This is obviously a boneheaded mistake, but how do you verify that all drivers follow "* nix security practices" (and I'm still not entirely clear exactly what those are nor how they differ from generic security practices) short of an in-depth security audit for each new piece of hardware. It isn't enough to have requirements, you have to have to be able to validate them. >So the solution is to either not allow custom OEM builds(which, as I noted, isn't possible for Android). Is there a second part to this "either"?
    - mikeash 14y ago
      Some sort of certification process before being allowed to ship customized builds would seem to do it. Or simply disallowing any custom builds at all: OS vendor builds all drivers, provides a list of supported hardware, and that's all you get to choose from.
      - mdwrigh2 14y ago
        > Some sort of certification process before being allowed to ship customized builds would seem to do it. You still haven't answered what the requirement is, just that Google should have requirements and enforce them. What requirement specifically would have prevented this error? And Android does require a certification process in order for a device to be called an Android device, just not one that would be helpful here [1]. > Or simply disallowing any custom builds at all: OS vendor builds all drivers, provides a list of supported hardware, and that's all you get to choose from. Considering how reluctant most device manufacturers are to give up their customized builds, how well do you think the ecosystem would respond to disallowing all customizations? And just because you disallow customizations, doesn't mean that all of the code suddenly comes from one company. Samsung (as the SoC manufacturer) and their component suppliers still provide (potentially vulnerable) firmware. Google has a much larger job to do in order to support even a fraction of the available chipsets, as well as a much larger job to do supporting external companies (what happens when there's a kernel bug in somebody else's phones? how long are the individual chipsets supported? etc. etc.) Besides, part of the point of Android is to allow for different companies to build phones for people who want different things, while remaining compatible with the rest of the ecosystem. Barring customization is almost the antithesis of the project's goals. [1]: http://source.android.com/compatibility/overview.html http://source.android.com/compatibility/overview.html
        mikeash 14y ago
        > You still haven't answered what the requirement is, just that Google should have requirements and enforce them. What requirement specifically would have prevented this error? I suggested one that you quoted directly below your question. Come on.... Yes, it would be tough to do within the ecosystem. I'm not saying it would be easy. I'm not even saying it would be a good idea. I'm simply saying that it is possible. Am I bad at communicating my thoughts? It seems like people regularly reply to my comments after reading things I never intended, and attacking me for it. I don't get it. Am I including subtexts I don't intend? Do people just insist on imagining things that aren't there? What's the deal?
  - JimmaDaRustla 14y ago
    Don't operating systems, like windows, have a secure memory space that only the core OS can access? Memory access violation? Edit: I don't understand the complete issue, I just know there was something about accessing all the memory.

mtgx 14y ago

Oh yeah, Microsoft's vitriolic campaign against Android. But this is not about Android per se, but about Samsung's drivers for the camera, and giving camera full access to root, because they were lazy.

mikeash 14y ago
I'm conflicted. On one hand, this is definitely Samsung's fault, not Android in general. On the other hand, an OS with more rigorous requirements for OEMs could have prevented this.
- mdwrigh2 14y ago
  I'm curious what requirement you think would prevent this.
  - cube13 14y ago
    Apple's approach(no OEMs at all, known hardware) would mitigate the problem somewhat. But that doesn't stop lazy idiots from screwing up at Apple, and it doesn't work for anyone that's providing a general-purpose OS. That's really about it. This is a kernel-level driver issue, caused by a lazy Samsung coder. Unfortunately, the drivers need that level of access, since they're used by Android to actually work. I'd say normal *nix kernel security practices should apply here, but that still doesn't stop lazy idiots...
    - mdwrigh2 14y ago
      So the "more rigorous requirements for OEMs" is "no OEMs at all"? Seems a little like throwing the baby out with the bathwater. Besides, part of the point of Android is having an OS which allows for companies like Samsung to build their own variants. Also, the problem isn't unknown hardware (as you would suggest by saying they should use "known hardware"). If it was an issue where they unknowingly left the hardware in some strange debugging state so that userland could query the it for restricted information, then it would be an issue with unknown hardware. In this case they directly and intentionally provided unprotected access to all of memory. That's just bad engineering.
      - cube13 14y ago
        >Also, the problem isn't unknown hardware (as you would suggest by saying they should use "known hardware"). No, the failure point here is, essentially, unknown hardware from Google's perspective. Android is not coded to work specifically with Samsung's configurations or hardware, so Samsung needs to provide drivers. As for "more rigorous" requirements, I don't think it's too hard to have the requirement that all drivers follow standard *nix security practices. That would have stopped this completely. So the solution is to either not allow custom OEM builds(which, as I noted, isn't possible for Android).
        mdwrigh2 14y ago
        > No, the failure point here is, essentially, unknown hardware from Google's perspective. Android is not coded to work specifically with Samsung's configurations or hardware, so Samsung needs to provide drivers. As for "more rigorous" requirements, I don't think it's too hard to have the requirement that all drivers follow standard * nix security practices. That would have stopped this completely. This is obviously a boneheaded mistake, but how do you verify that all drivers follow "* nix security practices" (and I'm still not entirely clear exactly what those are nor how they differ from generic security practices) short of an in-depth security audit for each new piece of hardware. It isn't enough to have requirements, you have to have to be able to validate them. >So the solution is to either not allow custom OEM builds(which, as I noted, isn't possible for Android). Is there a second part to this "either"?
  - mikeash 14y ago
    Some sort of certification process before being allowed to ship customized builds would seem to do it. Or simply disallowing any custom builds at all: OS vendor builds all drivers, provides a list of supported hardware, and that's all you get to choose from.
    - mdwrigh2 14y ago
      > Some sort of certification process before being allowed to ship customized builds would seem to do it. You still haven't answered what the requirement is, just that Google should have requirements and enforce them. What requirement specifically would have prevented this error? And Android does require a certification process in order for a device to be called an Android device, just not one that would be helpful here [1]. > Or simply disallowing any custom builds at all: OS vendor builds all drivers, provides a list of supported hardware, and that's all you get to choose from. Considering how reluctant most device manufacturers are to give up their customized builds, how well do you think the ecosystem would respond to disallowing all customizations? And just because you disallow customizations, doesn't mean that all of the code suddenly comes from one company. Samsung (as the SoC manufacturer) and their component suppliers still provide (potentially vulnerable) firmware. Google has a much larger job to do in order to support even a fraction of the available chipsets, as well as a much larger job to do supporting external companies (what happens when there's a kernel bug in somebody else's phones? how long are the individual chipsets supported? etc. etc.) Besides, part of the point of Android is to allow for different companies to build phones for people who want different things, while remaining compatible with the rest of the ecosystem. Barring customization is almost the antithesis of the project's goals. [1]: http://source.android.com/compatibility/overview.html http://source.android.com/compatibility/overview.html
      - mikeash 14y ago
        > You still haven't answered what the requirement is, just that Google should have requirements and enforce them. What requirement specifically would have prevented this error? I suggested one that you quoted directly below your question. Come on.... Yes, it would be tough to do within the ecosystem. I'm not saying it would be easy. I'm not even saying it would be a good idea. I'm simply saying that it is possible. Am I bad at communicating my thoughts? It seems like people regularly reply to my comments after reading things I never intended, and attacking me for it. I don't get it. Am I including subtexts I don't intend? Do people just insist on imagining things that aren't there? What's the deal?
- JimmaDaRustla 14y ago
  Don't operating systems, like windows, have a secure memory space that only the core OS can access? Memory access violation? Edit: I don't understand the complete issue, I just know there was something about accessing all the memory.