Comments 44
Увы, это никак не предотвратит предустановку дырявых "улучшайзеров" производителями устройств и полную невозможность удалять их без "рутования" устройства.
Два самых толстых вектора атаки — это GPU и апаратные кодеки. И у того, и у другого есть своя прошивка и есть возможность работать с любой памятью в обход ядра. При чем, аппаратные кодеки чаще всего управляются мелким ARM-ядром, соотвественно набор комманд известен.
Поэтому, то что MediaServer будет изолирован на уровня ядра линукса никак не спасет от хитрого видео-файла, который вызовет переполнение стека в коде аппаратного декодера и исполнение произвольного кода на отдельном процессорном ядре.
Мне кажется, что такие атаки непопулярны только потому что они будут таргетированны только на конкретную модель устройства.
Поэтому, то что MediaServer будет изолирован на уровня ядра линукса никак не спасет от хитрого видео-файла, который вызовет переполнение стека в коде аппаратного декодера и исполнение произвольного кода на отдельном процессорном ядре.
Мне кажется, что такие атаки непопулярны только потому что они будут таргетированны только на конкретную модель устройства.
Давно не слышно про уязвимости кодеков. Я думаю, потому что основная опасность — это парсинг формата файла, или контейнера, где есть размеры и смещения, которые можно выставить некорректными. В декодировании однородного потока данных, который stagefright скармливает декодерам, много меньше мест для ошибок, приводящим к изменению control flow. Там одна математика, а не управление буферами и размещением данных.
Кажется вы слишком хорошего мнения о проприетарных кодеках. Я бы мог много страшного рассказать, то NDA не дает вдаваться в детали.
Вот, например, был очень интересных глюк в однмом проприетарном OMX компоненте. В результате кривого взаимодействия с аппаратным модулем, код OMX компонента вызывал munmap с очень неправильным размером, в результате чего размапливалась вся память mediaserver'a. Просто потому что один разработчик прошивки кодека решил использовать поле size в шареном буфере немножно не по назначению.
А теперь представьте сколько ошибок такого рода просто не вылезло при тестировании или на них решили забить.
Вот, например, был очень интересных глюк в однмом проприетарном OMX компоненте. В результате кривого взаимодействия с аппаратным модулем, код OMX компонента вызывал munmap с очень неправильным размером, в результате чего размапливалась вся память mediaserver'a. Просто потому что один разработчик прошивки кодека решил использовать поле size в шареном буфере немножно не по назначению.
А теперь представьте сколько ошибок такого рода просто не вылезло при тестировании или на них решили забить.
Непонятно, как это не будет этапа «подготовки приложений».
Это же компиляция dex-кода установленных apk в машинный код, с объединением кода framework.jar и других системных jar с кодом приложения, чтобы применить «Whole program optimization». От такой мощной оптимизации решили отказаться?
Это же компиляция dex-кода установленных apk в машинный код, с объединением кода framework.jar и других системных jar с кодом приложения, чтобы применить «Whole program optimization». От такой мощной оптимизации решили отказаться?
«Подготовка» всего лишь сделана асинхронной. Сначала приложение скачивается и устанавливается, а потом оптимизируется.
Тут же вопрос не в установке приложения. А в том, что раньше OTA, содержащая обновление framework, инвалидировала dalvik-cache. При перезагрузке системы все приложения, встроенные и установленные, долго компилировалось заново. А теперь при начальной загрузке компилируются только критичные приложения (оболочка, телефон), а остальные позже в фоне?
В прошлых версиях Android ART работал как AOT (Ahead Of Time) компилятор. Все приложения, которые устанавливались на устройства с Android, компилировались один раз во время установки, используя текущую конфигурацию системы. После обновления ОС каждая программа должна была пройти оптимизацию, чтобы соответствовать изменениям в системе и новым API. Для решения этой проблемы в Android 7.0 ART работает как гибридный AOT/JIT компилятор. JIT (Just-in-time) предусматривает компиляцию программы каждый раз, когда она запускается. Это ускоряет как установку, так и работу системы, которой не нужно тратить ресурсы на компиляцию. Но JIT увеличивает нагрузку на процессор и память, расходуя больше заряда аккумулятора. Поэтому в Android 7.0, после установки (или обновления ОС) приложение запускается через JIT компиляцию, но когда устройство на зарядке и не используется, стартует AOT компилятор и завершает установку.
Спасибо, теперь всё разъяснилось.
Спасибо за объяснения!
Неужели лишние 10-15 минут при установке OTA (что происходит не так уж часто) оказались настолько критичными, что пошли на такое усложнение?
Неужели лишние 10-15 минут при установке OTA (что происходит не так уж часто) оказались настолько критичными, что пошли на такое усложнение?
Открыл сохранённый logcat от какого-то обновления.
265 приложений (только системные, на чистом телефоне) на Snapdragon 600 — примерно за 45 минут.
В некоторые времена я сотню разных утилит и игрушек ставил, это ещё порядка того же времени на компиляцию /data/app.
При этом, телефоном пользоваться нельзя, а вдруг захочется позвонить.
265 приложений (только системные, на чистом телефоне) на Snapdragon 600 — примерно за 45 минут.
В некоторые времена я сотню разных утилит и игрушек ставил, это ещё порядка того же времени на компиляцию /data/app.
При этом, телефоном пользоваться нельзя, а вдруг захочется позвонить.
Это не только OTA, это ещё дико тормозило девайс при установке обновлений через Google Play, а так же при удалении обновлений системных приложений (после удаления обновления оптимизировалась встроенная в систему версия приложения). Живой телефон при установке обновлений из маркета, да и просто быстрая установка приложений на обновлённом 5X весьма радует. Однако, при первом старте после чистки кэша Dalvik, оптимизация никуда не делась, но сейчас она проходит гораздо быстрее, так как в обязательном порядке оптимизирует лишь системные компоненты (system/framework, некоторые system/priv-app, vendor/app), а кэш приложений хранится в папке данных самого приложения, и создаётся лишь при необходимости (вижу как *.odex, так и *.art файлы для каждого приложения).
Мне кажется ?? или Андроид запиливается не только для смартфонов и планшетов, а для чего то более серьезного ???
Попахивает Рабочей станцией на Андроиде!!!
Попахивает Рабочей станцией на Андроиде!!!
UFO just landed and posted this here
А что с производительностью в этой версии?
UFO just landed and posted this here
печально, что-то не так у нас в консерватории
UFO just landed and posted this here
Хотелось бы чтобы консервы обрабатывались в новых консерваториях быстрее, но не наоборот :)
UFO just landed and posted this here
В новых девайсах ставят 64-битные процессоры, используется 64-битная система и библиотеки, что тоже явно не самым позитивным образом сказывается на потреблении памяти.
Меры напоминают попытку обернуть прогнившее ведро мусора оплеткой, чтобы не пахло и постояло дальше. Лучше бы купили ARM и сделали нормальную native OS с контролем всего и вся так как им будет нужно. При текущей парадигме, когда часть устройства с прошивками кодеков, модулей и самое интересное — ядром линукс отдается по сути вендору, ни одно решение не будет гарантировать безопасности. Либо все возможные дырки придется обернуть в кучу таких вот оплеток. За всеми возможными дырками не успеть. Вендоры наплодили просто зоопарк решений, консорциумов, над которыми нужно брать контроль.
После той кастомизации, которую легко делать декомпиляцией jar/apk, внесением изменений и рекомпиляцией, переходить на ОСь с native-кодом не хочется. Вот пример, как Navigation Bar с унылыми кнопками «Назад/Домой/Меню» превратили в прокручиваемую область с кучей режимов и кнопок: https://www.youtube.com/watch?v=74IZEvR6xw8
Помимо этого, несложно модифицируется «шторка» и множество аспектов системных приложений (алгоритмы работы авто-яркости, состав Power Button Menu, содержимое lockscreen, меняется интерфейс «Телефона» и «Контактов»).
Помимо этого, несложно модифицируется «шторка» и множество аспектов системных приложений (алгоритмы работы авто-яркости, состав Power Button Menu, содержимое lockscreen, меняется интерфейс «Телефона» и «Контактов»).
Вендоры наплодили просто зоопарк решений, консорциумов, над которыми нужно брать контроль.
Тут два момента:
1) Открытость и бесплатность андроида. Вендоры считают риски, и знают, что если завтра google откажется сотрудничать, они перейдут на другие облачные сервисы (Yandex, Nokia, Microsoft, Apple, Amazon), но в целом система не рухнет
2) Возможность кастомизации позволяет «выделиться». Например, Samsung комплектует устройства стилусом и реализует двухэкранный режим. HTC выкатывало новый интерфейс домашнего экрана «под плитки» (на волне анонса WinPhone, получилась в итоге ерунда и все вернулись в обычный режим, но как вау-фактор работало очень хорошо).
Microsoft, наоборот, пошла по пути, запрещающем сильные кастомизации. Это хорошо для платформы, но плохо для вендора. Зачем ему делать то же, что и у всех, становиться этаким noname-ом. Пользователи не будут подсаживаться на фичи интерфейса, и смогут легко переходить между производителями. А сейчас кто-то привык к Samsung, кто-то — к HTC, и нужны очень веские причины, чтобы сменить оболочку.
То есть, предложение взять ОСь под контроль не пройдёт, вендоры не поддержат.
Можно взять ОСь под контроль, но не менять user-space область – приложения, API. Все приложения крутятся в «виртуалках» dalvik (ныне art), причём уже скомпилированный код, и Google уже давно потихоньку затягивает гайки – приложения теряют доступ к флешке, к другим приложениям, к системным файлам, отключаются лишние броадкасты, во время сна теряется сетевой доступ, теперь вот запрещено использовать системные библиотеки в качестве динамически подключаемых для нативного кода, и т.д. При этом каждое приложение живёт своей жизнью и должно иметь у себя всё необходимое, все зависимости. Что там внутри – в целом, не должно интересовать ни разработчиков, ни конечных пользователей. Какая подсистема, что там происходит, как работает – это может быть скрыто и изменено. Те же медиа-библиотеки и сервисы, несмотря на описанные изменения, не изменились для разработчиков и для приложений, обеспечена полная совместимость. Так же андроид «портируется» под другие среды выполнения – например, можно запустить андроид-приложение без перекомпиляции или какой-либо модификации в хроме на компьютере на разных архитектурах и в разных операционных системах — в этом случае в качестве зависимого расширения скачается «эмулятор» – среда, внутри которого работает андроид, а файловый доступ представляется через стандартное файловое представление расширений хрома. В целом, это и есть показатель переносимости, который позволяет заменять внутренние организации системы, сохраняя внешнюю совместимость и работоспособность.
Таким образом, можно «взять ОСь под контроль» именно для унификации внутренних компонентов с сохранением совместимости, для исключения возможности влияния нативного дырявого кода от сторонних вендоров на всю систему. При этом внешняя кастомизация должна остаться, хотя и тут вендоры могут накосячить (и косячат!)
Таким образом, можно «взять ОСь под контроль» именно для унификации внутренних компонентов с сохранением совместимости, для исключения возможности влияния нативного дырявого кода от сторонних вендоров на всю систему. При этом внешняя кастомизация должна остаться, хотя и тут вендоры могут накосячить (и косячат!)
Не вариант, потому что вендорская кастомизация лезет и в ядро, и во framework.
Примеры:
— не выключается экран, если пользователь читает текст в любом приложении (камера отслеживает зрачки) — Samsung;
— можно вводить жесты на выключенном экране (свайп вверх — включение, свайпы влево-вправо — управление музыкальным плеером, реализовано модификацией кода драйвера тач-панели) — HTC;
— деление экрана на 2 обрасти, в каждой из которых работает своё приложение — Samsung.
К слову, только в Android 5.1 появилась поддержка dual-sim (до этого реализуемая вендорами вручную на всех уровнях — от ядра, до фрейморка и приложений).
То есть, чтобы получить отличную интеграцию и потрясающий UX, нужен доступ ко всем уровням ОС, иначе многие «инновационные» плюшки не сделаешь.
Примеры:
— не выключается экран, если пользователь читает текст в любом приложении (камера отслеживает зрачки) — Samsung;
— можно вводить жесты на выключенном экране (свайп вверх — включение, свайпы влево-вправо — управление музыкальным плеером, реализовано модификацией кода драйвера тач-панели) — HTC;
— деление экрана на 2 обрасти, в каждой из которых работает своё приложение — Samsung.
К слову, только в Android 5.1 появилась поддержка dual-sim (до этого реализуемая вендорами вручную на всех уровнях — от ядра, до фрейморка и приложений).
То есть, чтобы получить отличную интеграцию и потрясающий UX, нужен доступ ко всем уровням ОС, иначе многие «инновационные» плюшки не сделаешь.
Удивительно, как им удалось замять неудачный переход между dalvik и art. Последнему прочили лидерство в контексте многоядерных процессоров, однако обновление 5 и выше чуть ли не превратило в кирпичи часть их же фирменных устройств, которым к примеру являлся не слабый 4х ядерный nexus 12,13 годов c tegra на борту. Удивительно, как можно делать самим ОС, если свои же обновления просто убивают часть устройств в плане юзабилити из тормозов и глюков.
Кирпичи при обновлении — это одно (так и не понял, с чем именно это связано, но даже сестра подхватила синдром кирпича на Nexus 5, пришлось перешивать целиком полным образом), там изменился и процесс обновления, когда в OTA стали не диффы файлов вкладываться, а изменения блочных устройств (то есть это даже выше уровня ФС). А наибольшая проблема – тормоза старого железа. Art, несмотря на скорость работы, кушал больше памяти, и на девайсах с маленькой медленной оперативкой это стало болезненно. Более того, текущий их девайс, Nexus 5X, тоже имеет лишь 2 ГБ оперативки, и ещё пол-гига свапа – быстрая память спасает, но вынужденное шифрование печалит. При отключении шифрования заметна разница, особенно при нагрузке на IO – например, съёмка фотографий в HDR+, когда они обрабатываются, занимая память и проц, а затем сохраняются.
Здесь можно спорить долго, нужно понять одно — пока google дает вендорам право подсовывать практически любое по качеству ядро и затыкать все дырки кодом Android, все это останется примерно как сейчас. Ну зачем это делать?
Ему (вендору) не надо намекать, когда он делает решения на x86 — его задачи ограничиваются чем-то на уровне BIOS, за остальное отвечает нормальная компания с вменяемым образом мышления, ей уже не нужно никого называть дураками, так как она все делает за них. BIOSом тоже занимаются конторы со стажем чуть ли не 30+, такое есть на рынке. А что же в случае ARM? Бедная компания, которой нужно на одной подложке разместить миллиард транзисторов обязана, внимание, содержать штат embedded linux инженеров, или платить за это на сторону, что реже. Rockchip, Samsung, Qualcomm, до недавнего времени и Allwinner делали это. Крупная контентообразующая компания (название сами додумаете) вогнала вендоров в краску, заставив рынок потреблять 85% планшетов по цене 180 баксов и менее. У них нет денег на то, чтобы качественно пилить ядро. Samsung да в этом плане в основной гамме устройств за счет наработок прошлых лет неплохи, Quallcomm тоже. Остальные медленно подтягиваются или стоят на месте.
Производительность — уже давно пора иметь на Андроид вменяемые по качеству нагруженные приложения, те же игры, взгляните на свой магазинный топ, там уже не осталось вменяемого интересного контента, когда-то давно вы заточили операционку под быструю разработку простых приложений. Время пришло развивать платформу дальше. Как вы будете развиваться в этом направлении, если у вас нет контроля над качеством ядра, особенно в контексте графики?
Производительность — уже давно пора иметь на Андроид вменяемые по качеству нагруженные приложения, те же игры, взгляните на свой магазинный топ, там уже не осталось вменяемого интересного контента, когда-то давно вы заточили операционку под быструю разработку простых приложений. Время пришло развивать платформу дальше. Как вы будете развиваться в этом направлении, если у вас нет контроля над качеством ядра, особенно в контексте графики?
На x86 так исторически сложилось, что, во-первых, ноуты — это мобильные ПК (где пользователи привыкли сами ставить ОСь), во-вторых, ОСь традиционно была закрытой, поставлялась в виде скомпиленных бинарных файлов, и в ядре не было никакой возможности покопаться. С Андроидом иначе — джин выпущен из бутылки, сдавать свои позиции вендоры не будут.
Главное, зачем это гуглу? Думайте с точки зрения бабла. Сейчас все продажи идут через play store, принося 30% комиссии, все пользователи подсажены на крючок сервисов и сдают свои персональные данные. Если начинать мутить воду, есть риск, что их новую концепцию не примут, андроид форкнут, сервисы (почта, карты) закажут у другого поставщика (сейчас есть выбор). Одни убытки.
А какие плюсы? Концепция «чистого» устройства. Но есть же нексусы, как-то их народ не очень любит. Гугл в качестве осторожного эксперимента пробует этот путь. Если вы хотите такой андроид, болейте за что, чтобы у них с нексусами получалось лучше и лучше.
Лучше закидывать всё патчами или, ещё лучше, требовать от юзеров купить новое устройство, с закрытой дырой ))
С одной стороны, юзеры привыкли платить $1-$2, на таком бюджете сложно делать качественные игры.
С другой стороны, казуальное управление. Сложно управлять шутером или стратегией на тач-скрине. А девайсы с полноценными контроллерами выходят из нишы повсеместно носимых. Консоли на андроиде не взлетели из-за нехватки игр по 1-й причине.
И ещё момент (возможно, спорный). Если я хочу поиграть в качественную игру, мне нужно погружение в её мир. А это большой экран и много времени (а мобильные девайсы — это игры в очередях, в автобусах, в туалете и т.п. небольшие сессии).
Главное, зачем это гуглу? Думайте с точки зрения бабла. Сейчас все продажи идут через play store, принося 30% комиссии, все пользователи подсажены на крючок сервисов и сдают свои персональные данные. Если начинать мутить воду, есть риск, что их новую концепцию не примут, андроид форкнут, сервисы (почта, карты) закажут у другого поставщика (сейчас есть выбор). Одни убытки.
А какие плюсы? Концепция «чистого» устройства. Но есть же нексусы, как-то их народ не очень любит. Гугл в качестве осторожного эксперимента пробует этот путь. Если вы хотите такой андроид, болейте за что, чтобы у них с нексусами получалось лучше и лучше.
Лучше закидывать всё патчами или, ещё лучше, требовать от юзеров купить новое устройство, с закрытой дырой ))
те же игры, взгляните на свой магазинный топ, там уже не осталось вменяемого интересного контентаТут дело не в ядре. Я помню бум «графонистых» игр в 2009-2011 (выходили Dead Space, серии шутеров N.O.V.A. и Modern Combat). Это всё сдулось вовсе не из-за качества ядра.
С одной стороны, юзеры привыкли платить $1-$2, на таком бюджете сложно делать качественные игры.
С другой стороны, казуальное управление. Сложно управлять шутером или стратегией на тач-скрине. А девайсы с полноценными контроллерами выходят из нишы повсеместно носимых. Консоли на андроиде не взлетели из-за нехватки игр по 1-й причине.
И ещё момент (возможно, спорный). Если я хочу поиграть в качественную игру, мне нужно погружение в её мир. А это большой экран и много времени (а мобильные девайсы — это игры в очередях, в автобусах, в туалете и т.п. небольшие сессии).
Следуя этим комментариям можно признать такие творения как Ps Vita и то, чем занимаются Sony и Nintendo — дурачеством. Там же нет большого экрана Но там есть реально удобный, быстрый, продуманный и отлаженный продукт. Хотя это ниша потенциально может быть занята и Анроидом, но они там чувствуют себя вольготно и не боятся своей гегемонии, это реально массово с позиции игр. Кто бы что ни говорил, через мои руки прошел десяток аппаратов на google, общие мои взносы на деятельность этой компании превысили шестизначную сумму, но теперь я ношу с собой iPad. Вы сами сделали удобный конвеер для своего конкурента не заняв нишу, сходную по качеству продукта.
Sign up to leave a comment.
Новые функции безопасности Android 7