4 ms·
> Say there is an exploit in the OS ext* implementation, if ext* is not included in userland, then it will be subject to far less testing, so the exploit is les
by DCKing 12y ago
> Say there is an exploit in the OS ext* implementation, if ext* is not included in userland, then it will be subject to far less testing, so the exploit is less likely to be discovered.
If you want to mount an external ext* partition yourself in ChromeOS from now on, you'll have to do some manual work going down to Linux using a terminal or Crouton. If there's an exploit in any of that, it will also affect millions of other Linux computers around the world as ChromeOS is no different from any other Linux distro with respect to ext* anymore (just Linux + ext kernel modules + e2fsprogs). Google will not feel obliged to cover that use case in their tests, and rightly so I think.
In fact, they have described their "support" of ext* as accidental in the original thread, so it doesn't appear they ever tested it in the first place.
- lotsofmangos 12y agoThat sounds like the same approach that everyone used with openSSL. The fact that code is open source is not a sane reason not to test it.
- DCKing 12y agoI sympathize with the general sentiment, but it misses the point. Linux + ext kernel modules + e2fsprogs is tested daily by developers of many Linux distributions. There's really no problem with verifying that some module works. Furthermore, Google tests this system implicitly by haveing ChromeOS use ext4 as its root file system. So everyone is right to be confident it works correctly. However, testing whether or not something works is totally different from testing whether it is secure. Many people testing whether OpenSSL works correctly (which happens every single day) would not have shown Heartbleed at all.