3 ms·

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

by 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"?

by cube13 14y ago

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"?