Русский
Русский
English
Статистика
Реклама

Apple m1

Перевод Ваш компьютер на самом деле не ваш

16.11.2020 18:23:29 | Автор: admin

Вот он. Наступил. Не заметили?

Речь, конечно, идет о мире, предсказанном Ричардом Столлманом в 1997 году. О мире, о котором нас предупреждал Кори Доктороу.

В современных версиях macOS вы не можете просто включить компьютер, запустить текстовый редактор или просмотрщик электронных книг и писать или читать, не передавая и не журналируя ваши действия.

Оказывается, текущая версия macOS отправляет в Apple хэш (уникальный идентификатор) при запуске каждой программы. Многие люди не были в курсе этого, так как хэш передается незаметно и только при наличии выхода в интернет. А сегодня серверы работали очень медленно и не успевали проверять хэши. Как результат, все приложения не открывались, если имелся выход в интернет.

Поскольку хэши передавались через интернет, серверы, конечно же, видят ваш IP-адрес и знают, в какое время пришел запрос. А IP-адрес в свою очередь позволяет установить ваш город, интернет-провайдера, а также составить таблицу со следующими заголовками

Дата, Время, ПК, Провайдер, Город, Штат, Хэш приложения

Apple (или кто-то еще), безусловно, может вычислить эти хэши для обычных программ: для всех программ из App Store, Creative Cloud, браузера Tor, инструментов для взлома или, например, реверс-инжиниринга да для чего угодно!

Это означает, что Apple знает, когда вы дома, а когда на работе. Какие приложения вы открываете и как часто. Они знают, когда вы открыли Premiere в гостях у друга, используя его сеть Wi-Fi, или когда вы сидите в браузере Tor в отеле во время поездки в другой город.

Я часто слышу: Кого это волнует?.

Что ж, волнует не только Apple. Эта информация не задерживается у них:

1. Эти OCSP-запросы передаются в незашифрованном виде. Их могут перехватывать все, кто в сети, включая вашего интернет-провайдера, а также, кто прослушивает интернет-трафик.

2. Эти запросы проходят через стороннюю CDN, управляемой другой компанией, Akamai.

3. С октября 2012 года Apple является партнером Разведывательного сообщества США в рамках государственной программы по шпионажу PRISM, которая предоставляет федеральной полиции и вооруженным силам США беспрепятственный доступ к данным без ордера. В первой половине 2019 года они воспользовались этим правом более 18 000 раз, а во второй половине 2019 года еще более 17 500.

Эти данные представляют собой огромный массив данных о вашей жизни и привычках, позволяя кому-то, кто владеет им, идентифицировать вас по вашим передвижениям и модели активности. Для некоторых людей это может даже представлять физическую опасность.

До сегодняшнего дня была возможность заблокировать подобное поведение на вашем Mac с помощью программы Little Snitch (на самом деле это единственное, что заставляет меня использовать macOS на данный момент). По умолчанию программа разрешает передачу между компьютером и серверами Apple, но вы можете вручную разрешать или блокировать то или иное соединение. А ваш компьютер продолжит работать нормально, не стуча на вас в Apple.

macOS 11.0 Big Sur получила новые API, которые ломают работу Little Snitch. Они не позволяют программе проверять или блокировать какие-либо процессы на уровне ОС. Кроме того, новые правила в macOS 11 затрудняют работу даже VPN, так что приложения Apple просто обходят их.

Патрик Уордл (Patrick Wardle) сообщил нам, что демон trustd, отвечающий за эти запросы, находится в новом списке исключений ContentFilterExclusionList, что означает, что он не может быть заблокирован никаким пользовательским брандмауэром или VPN. На его скриншоте также показано, что CommCenter (используется для совершения телефонных звонков с вашего Mac) и Карты также будут игнорировать ваши брандмауэр и VPN, ставя потенциально под угрозу ваш голосовой трафик и информацию о будущем или планируемом местоположении.

Помните только что анонсированные красивые Mac на новом процессоре Apple? В три раза быстрее и на 50 % больше времени автономной работы. Они не будут поддерживать ни одну ОС, кроме Big Sur!

Это первые компьютеры общего назначения, когда вам придется сделать выбор: или у вас быстрый и мощный компьютер, или личный. Мобильные устройства Apple работают таким образом уже как пару лет. За исключением использования устройств для фильтрация внешнего сетевого трафика (например, VPN-маршрутизатора), которые контролируете именно вы, на Mac с новым процессором не будет больше возможности загрузиться с какой-либо ОС, чтобы она не "звонила" в Apple. Иначе ОС может вообще не загрузиться из-за аппаратной криптозащиты.

Обновление. 13.11.2020 07:20 UTC

Мне стало известно, что у Mac на процессорах Apple с помощью утилиты bputil можно отключить защиту при загрузке и изменить Signed System Volume (SSV). Один я уже заказал и, как только со всем разберусь, напишу у себя об этом в блоге. Насколько я понимаю, даже после внесения таких изменений по-прежнему можно будет загружать только версии macOS, подписанные Apple. Хотя, возможно, и с некоторыми удаленными или отключенными нежелательными системными процессами. Дополнительные данные появятся, когда система будет у меня в руках.

Теперь ваш компьютер служит удаленному хозяину, который решил, что имеет право шпионить за вами. Даже имея самый производительный ноутбук с высоким разрешением в мире, вы не можете этому помешать.

Давайте не будем сейчас особо задумываться о том факте, что Apple может с помощью этих онлайн-проверок сертификатов предотвратить запуск любого приложения, которое они (или их правительство) потребуют подвергнуть цензуре.

Лягушка в кипятке

На этой неделе настал день, о котором нас предупреждали Столлман и Доктороу. Это был постепенный и последовательный процесс, но вот мы наконец-то и приплыли. Вы больше не будете получать оповещений о передаче данных на серверы Apple.

Смотрите также

21 января 2020 г. Apple отказалась от плана по шифрованию резервных копий после жалобы ФБР.

Возможно, не в тему

К другим новостям: Apple незаметно отказалась от сквозной криптографии в iMessage. В настоящее время актуальная iOS будет запрашивать ваш Apple ID во время установки и автоматически включать iCloud и iCloud Backup.

В iCloud Backup не используется сквозное шифрование: резервная копия вашего устройства шифруется с помощью ключей Apple. Каждое устройство с включенным резервным копированием iCloud (а оно включено по умолчанию) загружает резервную копию всей истории iMessage на серверы Apple вместе с секретными ключами iMessage каждую ночь при подключении к сети. Apple может расшифровать и прочитать все данные, даже не притрагиваясь к устройству. Даже если вы отключили резервное копирование в iCloud, вполне вероятно, что тот, с кем вы переписываетесь с помощью iMessage, этого не сделал. Как следствие, ваша переписка загружается на серверы Apple. Еще и через PRISM со свободным доступом для Разведывательного сообщества США, ФБР и др. без ордера или веской на то причины.

Используйте Signal.

FAQ

В.: Это часть собираемой аналитической информации macOS? Будут ли собираться данные, если у меня отключена отправка аналитической информации?

О.: Это не имеет отношения к аналитической информации. Похоже, что это часть кампании Apple по борьбе с вредоносным ПО (и, возможно, по борьбе с пиратством). Это происходит на всех компьютерах Mac с уязвимыми версиями ОС, независимо от каких-либо настроек по сбору аналитической информации. В ОС отсутствует пользовательская настройка для отключения.

В.: Когда это началось?

О.: Это происходит по крайней мере с момента выхода macOS Catalina (10.15.x, выпущена 7 октября 2019 г.). То есть это началось не со вчерашнего выпуска Big Sur, а происходило незаметно как минимум год. По словам Джеффа Джонсона (Jeff Johnson) из Lap Cat Software, все началось с macOS Mojave, выпущенной 24 сентября 2018 года.

Каждую новую версию macOS я устанавливаю начисто, выключаю сбор аналитической информации, не вхожу ни в какие сервисы (как iCloud, App Store, FaceTime или iMessage) и включаю внешнее устройство для мониторинга всего исходящего сетевого трафика. У последних версий macOS наблюдался довольно активный сетевой трафик, даже если вы не используете никакие сервисы Apple. В Mojave (10.14.x) были некоторые проблемы с конфиденциальностью и отслеживанием, но я не помню, существовала ли тогда конкретная проблема с OCSP или нет. Я еще не тестировал Big Sur (следите за обновлениями), но, согласно отчетам тех, кто тестировал, возникают опасения по поводу пользовательских брандмауэров вроде Little Snitch, приложений Apple, которые обходят эти брандмауэры, и VPN-соединений. Догадываюсь, что у меня будет большой список вопросов, когда я установлю Big Sur на тестовую машину на этой неделе.

В.: Как мне защитить свою конфиденциальность?

О.: По-разному. Ваш Mac отправляет тонну трафика на серверы Apple. Если вы беспокоитесь о своей конфиденциальности, можете начать с отключения функций, у которых имеются кнопки: отключите и выйдите из iCloud, отключите и выйдите из iMessage, отключите и выйдите из FaceTime. Убедитесь, что службы геолокации отключены на ваших компьютере, iPhone и iPad. То были значительные слабые места, по которым вас могли отследить и на которые вы уже согласились, но есть простой выход: выключите все.

Что до проблемы с OCSP, я считаю (но еще не тестировал!), что сработает эта команда

echo 127.0.0.1 ocsp.apple.com | sudo tee -a /etc/hosts

Такой трафик я блокирую программой Little Snitch, которая еще работает на версии 10.15.x (Catalina) и ниже. Отключите в Little Snitch все разрешающие правила для служб macOS и службы iCloud, чтобы получать предупреждения, когда ОС пытается связаться с Apple.

Если у вас Mac на Intel (а такой почти у всех сейчас), не беспокойтесь о грядущих изменениях. Если вы хотите изменить пару настроек в ОС, то скорее всего всегда настраивали все предыдущие macOS под себя. Это особенно актуально для немного более старых Mac на Intel, в которых нет чипа безопасности T2. Но вполне вероятно, что даже на таких компьютерах можно будет отключать безопасную загрузку (тем самым позволяя настраивать ОС), как это можно делать сейчас.

Новые Mac на ARM64 (Apple Silicon), которые были выпущены на этой неделе, стали причиной моего беспокойства: еще неизвестно, дадут ли пользователям возможность вообще модифицировать ОС на этих чипах. На других ARM-системах от Apple (iPad, iPhone, Apple TV, Watch) криптографически запрещено отключать такой функционал ОС. Для новых Mac на ARM по умолчанию скорее всего тоже будет запрещено, хотя, надеюсь, продвинутые пользователи смогут отключить некоторые средства защиты и настраивать систему. Я надеюсь, что утилита bputil(1) даст возможность отключить проверку целостности системного тома на новых Mac, что позволит нам удалить определенные системные службы из автозагрузки, не отключая все функции безопасности платформы. Больше информации узнаем в ближайшее время, когда ко мне приедет новый Mac на M1 в этом месяце.

В.: Если тебе не нравится Apple и ты не доверяешь их ОС, то почему ей пользуешься? Почему сказал, что покупаешь новый Mac на ARM?

О.: Простой ответ заключается в том, что без оборудования и программного обеспечения я не могу с уверенностью говорить о том, что они делают или не делают, или о шагах, которые можно предпринять для нивелирования проблем с конфиденциальностью. Длинный ответ заключается в том, что у меня есть более 20 компьютеров с примерно 6 различными архитектурами процессоров. У меня в коллекции имеются все операционные системы, о которых вы слышали, и некоторые из тех, о которых вы, вероятно, и не знали. Например, в моей лаборатории есть 68k Mac (16-битный, почти 32-битный (привет, мой IIcx) и чисто 32-битный), Mac на PowerPC, 32-битный Mac на Intel, 64-битный Mac на Intel (с чипом безопасности T2 и без). Да я бы прослыл последним бездельником, если не много не поковырялся в Mac на ARM64.

В.: Зачем Apple шпионит за нами?

О.: Я не верю, что это было специально разработано как часть телеметрии, но это прекрасно подходит для этой цели. Простое (без злого умысла) объяснение состоит в том, что это часть кампании Apple по борьбе c вредоносным ПО и обеспечению безопасности платформы в macOS. Кроме того, OCSP-трафик, генерируемый macOS, не зашифрован, что делает его идеальным объектом для использования в военных операциях по наблюдению (которые пассивно контролируют всех основных интернет-провайдеров и сетевые магистрали) с целью сбора диагностических данных. И неважно, намеренно ли Apple закладывала такой функционал или нет.

Еще что интересно: недавно Apple с обновлением iOS представила iCloud Backup, добавив закладку в iMessage, чтобы ФБР могло продолжить чтение всех данных на вашем телефоне.

Как говорил Голдфингер: "Один раз случай, два совпадение, три заговор врага". Было всего пару раз, когда Apple (которая, кстати, нанимает крутейших специалистов по криптографии) признавала, что допускала передачу открытого текста или ключей шифрования в открытом виде с устройства в сеть/Apple, и извинилась: Ой, это была случайность. И ей поверили.

Последний раз я сообщал Apple в 2005 году о проблеме, связанной с передачей открытого текста по сети. Тогда они быстро все исправили, но это касалось только поиска слов в словаре. Вскоре после того, как была представлена технология App Transport Security, которая помогает сторонним разработчикам приложений не забивать на сетевое шифрование, Apple усложнила отправку незашифрованных запросов в приложениях из App Store. Поэтому для меня не понятно, почему Apple до сих пор отправляет OCSP-запросы в незашифрованном виде, несмотря на то, что это стандартная практика в отрасли.

Если Apple действительно заботится о конфиденциальности пользователей, прежде, чем выпускать новую ОС, им следует тщательнее следить за передачей данных даже на ненастроенном Mac. Мы вот заботимся. Чем дольше они закрывают на это глаза, тем менее убедительными становятся их заявления о соблюдении конфиденциальности пользователей.

В.: Зачем ты поднимаешь ложную тревогу? Разве ты не знаешь, что OCSP предназначен только для предотвращения запуска вредоносных программ и обеспечения безопасности ОС, а не для сбора телеметрии?

О.: Побочный эффект в том, что он функционирует как телеметрия независимо от первоначального замысла. Кроме того, даже, несмотря на то, что OCSP-ответы подписаны, OCSP-запросы не зашифрованы, что позволяет любому пользователю сети (включая Разведывательное сообщество США) видеть, какие приложения вы запускаете и когда. А это можно считать крайней степенью халатности.

Многие вещи функционируют как телеметрия, даже если изначально это и не было задумано. Спецслужбы, которые шпионят за каждым, могут воспользоваться этим независимо от намерений разработчиков.

Не стоит организовывать тотальный контроль на каждым, чтобы, например, победить, терроризм, или пересаживать всех на платформу с тотальной слежкой для борьбы с вредоносным ПО. В погоне за созданием безопасной платформы, вы отказывайтесь от того светлого, что уже имеете. Вы создаете платформу, которая по своей сути небезопасна из-за низкого уровня конфиденциальности.

В.: Они поместили закладку в сквозное шифрование iMessage? Охренели вообще?!

О: Ага. Технический разбор в моих комментариях тут и тут.

TL;DR: Об этом даже говорится на их сайте: https://support.apple.com/en-us/HT202303.

Сообщения в iCloud также используют сквозное шифрование. Если у вас включено резервное копирование в iCloud, ваша резервная копия содержит копию ключа, защищающего ваши сообщения. Этот подход гарантирует, что вы сможете восстановить свои Сообщения, если потеряете доступ к связке ключей iCloud и своим доверенным устройствам. При отключении резервного копирования iCloud на вашем устройстве создается новый ключ для защиты будущих сообщений, который не хранится у Apple.

(курсив автора)

Обратите внимание, что само резервное копирование iCloud не имеет сквозного шифрования, что приводит к проблеме условного депонирования ключа iMessage, которая препятствует сквозному шифрованию последнего. На этой веб-странице есть раздел, в котором перечислены материалы, которые используют сквозное шифрование, и вот резервного копирования iCloud там нет.

Как и ваши фотографии в iCloud. Системные администраторы в Apple (а также военные и федералы США) могут спокойно видеть все ваши интимные фотографии в iCloud или iMessage.

Дальнейшее чтение

P. S. Перевел статью целиком только из-за того, что текущий перевод вообще не соответствует уровню статей Хабра.

Подробнее..

Apple M1. Если Intel ничего не предпримет, то мы можем увидеть его закат

18.11.2020 12:16:11 | Автор: admin


То что сейчас происходит это выбивание стула из под Intel, никак иначе. Еще и AMD может зацепить, хотя они показывают хороший прогресс. Если Intel продолжит свою текущую политику, продолжит считать себя монополией и диктовать цены на свои процессоры, то ее, веряотно, ждет закат. Почему? Я проанализировал первые тесты Apple M1 и они сделали первый серьезный удар.

Сразу скажу Я не фанат Apple, хоть и пользуюсь Apple MacBook Pro 13 еще 2015 года, а недавно выбирал супруге ноутбук и остановился на Apple MaCbook Pro 16, хотя и перебрал множество других недешевых ноутбуков. Я не в восторге от политики компании, от многочисленных багов в MacOS и если бы для меня существовала альтернатива, то я бы с радостью сьехал на Xubuntu. Потому я не являюсь ярым фанатом, потому не пытайтесь меня уличить в предвзятости =)

Сегодня появились в продаже новые MacBook Air, MacBook Pro 13 и Mac mini. Есть первые тесты производительности.

По тесту Geekbench 5 в тесте на 1 ядре Apple M1 3.2 GHz уделывает MacBook Pro 16 на топовом Intel Core i9-9880H 2.6 Ghz и даже iMac 2020 года на топовом Intel Core i9-10910 3.6 GHz. Результаты синтетических тестов 1689 vs 1251 vs 1095.



В multi-core тесте результаты 7288 vs 9021 vs 6869. При этом, у iMac 10 ядер, а у остальных по 8 ядер.



Но! Эти тесты без эмуляции x86, а у M1 архитектура ARM, потому тот же Premier Pro для x86 систем будет медленнее работать. Ранее на Geekbench были замеры в режиме эмуляции и там результаты single core/multi-core были куда скромнее: 1313 и 5888. Но потом с Geekbench данные этих тестов удалили и оставили нативные тесты. Но интернеты помнят все. Даже с эмуляцией это быстрее чем Core i7 и Core i9. А что будет когда Premier Pro и прочие сделают поддержку нативную ARM?



Эти тесты это синтетика, стоит помнить. У MacBook Air нет вентилятора, а у MacBook Pro есть, потому я предполагал возможность перегрева при длительной нагрузке и будет происходить снижение производительности. Но я уже видел экспорт H264 4K@60fps видео длиной в 20 минут, которые не привели к снижению производительности. Производительность не падает! На этом видео, кстати, видно, что экспорт занял 24 минуты, а топовый MBP 14 года проиграл 4%. Разница не так велика, но это Air vs Pro, без вентилятора и базового уровня, дальше Apple обещает более мощные чипы.

Еще под полной нагрузкой M1 нагрелся до 33 градусов по цельсию на корпусе на Air без вентилятора! Что повергло прямо в шок, ибо MacBook Pro 16 греется до 46-50 градусов, жужа как пылесос.

Работа в Davinci, Final Cut и Premiere Pro с 4K видео работает как нативно (Final Cut), так и с Premiere Pro в режиме эмуляции x86 (Rosetta 2). При x4 воспроизведении 4К не наблюдалось тормозов.

Тесты Cinebench R23 показали преимущество над Core i9-9880, 1498 vs 1183 в single core тесте. Правда Ryzen лидирует в multi-core тесте.





Affinity тест: M1 дает жару iMac с AMD 580X.



Утром подьехали тесты компиляции WebKit.





Числа выше говорят за себя. Но вот что еще Apple подняла цены на официальном сайте на версии с Intel процессорами. Для примера, MacBook Pro 16 с Core i9-9880H, 16Gb RAM и 512Gb SSD стоит $2699. В то время как Apple MacBook Air с M1, 16Gb RAM и 512Gb SSD стоит $1499. При почти одинаковой производительности Базовый Air entry level против топового Pro Давление ценой и качеством. Что же, это мощный удар.

Что может последовать дальше? Волна хайпа вдохновит других вендоров и разработчиков OS пересмотреть свой подход. ARM позволяет запускать сотни тысяч приложений с мобильного AppStore и пользователи смогут запускать тот же Instagram уже на Mac. У Google тоже есть своя большая экосистема на ARM и это может подстегнуть Google активней разрабатывать свою OS, либо даже посмотреть в сторону производства своих устройств. Если сойдутся звезды, то и MS присоединиться к гонке. Выиграет от этого покупатель в любом случае. А что думаете вы? Пишите в комментариях!

Материал подготовелен на базе моей публикаций в авторском телеграм канале Об IT без галстуков. Правда о менеджменте, действиях и мотиваторах топ-менеджмента, про то как расти в компании и что ценят собственники бизнеса. Ну и авторский материал про современную разработку!


Изображение на обложку взято с ixbt.com, ну очень в тему)
Подробнее..

Поддержка процессоров Apple M1 в .NET

21.11.2020 22:12:40 | Автор: admin

17 ноябряAppleофициально представила устройства на базе своего нового ARM-процессораAppleM1. Естественно, это событие не могло быть не замечено со стороны компанииMicrosoft, которая с 2014 года начала активную экспансию .NET на новые платформы. Давайте посмотрим, что нас ждет в связи с этим в ближайшее время.

Начнем пожалуй с инструментов, а затем перейдем к самой платформе .NET, но если вам не терпится узнать, получат ли новые маки поддержку .NET, то вот вам небольшой спойлер:

Spoiler

Да, на новых маках будет .NET

Visual Studio Code

Команда разработчиков Visual Studio Code уже объявила о том, что работает над поддержкой новых процессоров. На странице загрузок Insider Preview для macOS уже появились опция для загрузки экспериментальной сборки с поддержкой ARM. Следить за работой команды можно на официальном аккаунте в GitHub.

Visual Studio for Mac

Если команда VS Code уже подготовила тестовые сборки с поддержкой Apple M1, то их коллеги из команды Visual Studio for Mac оказались не так расторопны:

Впрочем Visual Studio for Mac гораздо более крупный и сложный проект, поэтому портирование его на новый процессор может занять несколько больше времени. Сейчас эта версия IDE может работать при поддержке Rosetta 2.

На данный момент у владельцев новых ноутбуков Apple наблюдаются некоторые проблемы при отладке проектов на Xamarin.Forms для iOS. Соответствующий баг уже заведен в репозитории проекта Xamarin.iOS & Xamarin.Mac.

Rider

В JetBrains уже объявили, что они работают над переносом JetBrains Runtime (и всех продуктов, работающих на JVM, в том числе и Rider) на Apple Silicon. На данный момент IDE от JetBrains работают на чипах Apple Silicon через Rosetta 2. Правда не все функции работают в этом режиме стабильно. Так, например, многие жалуются на то, что отладка в Rider сейчас не работает.

Docker

Docker стал практически must have инструментом для современного разработчика. У Майкрософт есть обширный набор образов для .NET, но к сожалению, воспользоваться вы ими на ноутбуке с новым процессором от Apple пока не сможете.

Будем надеяться, что в ближайшее время поддержка M1 будет реализована в Docker.

.NET

А теперь перейдем к самому главному получит ли новый чип поддержку .NET?

Те, кто подсмотрели спойлер в начале статьи уже знают ответ на этот вопрос. Команда разработки .NET активно работает над поддержкой Apple M1. Для этого даже был создан отдельный проект в трекинге платформы. Стоит отметить тот факт, что текущая версия платформы (а именно, недавно ушедший в релиз .NET 5) будет работать поверх Rosetta. А вот в .NET 6 уже будет нативная поддержка нового чипа. Согласно планам Microsoft, произойдет это не раньше, чем через год:

Из того, что уже выполнено, я бы отдельно отметил такие задачи:

Также запланирована поддержка нового процессора в ASP.NET Core.

Но несмотря на то, что официальной поддержки новых процессоров придется ждать почти год, уже доступна к загрузке альфа-версия .NET 6.0. На момент написания статьи, это версия 6.0.0-alpha.1.0562.6.

Mono

Проект Mono, который обычно был догоняющим (так как команде приходилось реализовывать те возможности, которые уже были в .NET) на этот раз оказался слегка впереди. Пулреквест с поддержка нового процессора сделала сама Apple, которая ранее обещала помощь в поддержке M1 для проектов с открытым исходным кодом.

Проекты, которые вскоре должны получить поддержку Apple M1Проекты, которые вскоре должны получить поддержку Apple M1

Самое большое изменение, которое было сделано для поддержки процессора M1 связанно с тем, как работает JIT, а именно, с изменение состояния потоков. Это было реализовано с помощью новых макросов в mono/mini.h. Они были встроены в систему из соображений производительности.

Rosetta 2

В этой публикации не один раз упоминалась технология Rosetta 2. Для тех, кто не знает, что это, приведем пояснение, которое размещено на странице портала Apple Developer:

Rosetta - это процесс трансляции, который позволяет пользователям запускать приложения, содержащие инструкции x86_64, на микросхеме Apple. Rosetta призвана упростить переход на микросхему Apple, давая разработчикам время на создание универсального двоичного кода приложений. Если исполняемый файл содержит только инструкции Intel, macOS автоматически запускает Rosetta и начинает процесс трансляции. По окончании трансляции система запускает подготовленный исполняемый файл вместо оригинала. Однако процесс перевода требует времени, поэтому транслированные приложения иногда запускаются или работают медленнее.

Итоги

Новый процессор (а соотвественно устройства, которые будут на основаны на нем) без сомнений получит нативную поддержку в .NET, впрочем эта задача не является приоритетной в текущем роадмапе, поэтому ждать ее придется не раньше, чем в релиз уйдет шестая версия платформы. До того момента можно будет работать c .NET, используя возможности Rosetta 2. Что касается инструментария для разработчиков, то я могу предположить, что в ближайшие пол года основные проблемы будут решены (возможно даже с участием Apple) и уже к апрелю можно будет потихоньку присматриваться к компьютерам на базе Apple M1 в качестве рабочего инструмента.

Подробнее..

Перевод Компиляция CC на Apple M1

02.12.2020 20:12:10 | Автор: admin


Заинтригованный впечатляющими бенчмарками M1, я достал последний Mac Mini, чтобы замерить скорость компиляции на C/C++.

Измеряем локальный build2 (без репозитория пакетов), который включает преимущественно код на C++ (611 единиц трансляции) с некоторыми блоками на C (29) и связками между ними (19). Такой бенчмарк требует только компилятора C++ и входит в тестовый набор Phoronix, поэтому можно сравниться с большим количеством процессоров.

Бенчмарк Phoronix в настоящее время использует build2 0.12.0, у нас 0.13.0 (текущий релиз), здесь сборка выполняется примерно на 10% медленнее.

После настройки Mac OS и установки инструментов командной строки для XCode 12.2 у нас есть всё необходимое:

$ clang++ --versionApple clang version 12.0.0 (clang-1200.0.32.27)Target: arm64-apple-darwin20.1.0

Судя по _LIBCPP_VERSION в заголовке __version файла libc++, эта версия Apple Clang ответвилась от ванильного Clang где-то в процессе разработки 10.0.0.

Возможно, вы также заметили, что название процессора в триплете Apple Clang отличается от стандартного aarch64. На самом деле config.guess показывает следующее:

$ ./config.guessaarch64-apple-darwin20.1.0

Чтобы не использовать два названия для одного и того же, build2 канонизировал arm64 в aarch64, поэтому в buildfiles мы всегда видим aarch64.

Проверим количество аппаратных потоков в sysctl:

$ sysctl -n hw.ncpu8

Здесь 8 потоков, это 4 производительных ядра и 4 энергоэффективных. В первом прогоне задействуем все ядра. Очевидно, это даёт наилучший результат:

$ time sh ./build2-install-0.13.0.sh --local --yes ~/install163s

Приятным сюрпризом оказалось то, что build2 0.13.0 заработал без особых проблем, хотя он вышел раньше M1. Поскольку в ARM слабое упорядочение памяти, это также послужило дополнительной проверкой многопоточной реализации build2 и интенсивного использования атомиков.

Для начала сравним M1 с моей рабочей станцией на 8-ядерном Intel Xeon E-2288G (по сути, i9-9900K плюс ECC). Та же сборка на ванильном Clang занимает 131с. Хотя это лучший результат, но производительность M1 всё равно впечатляет. Особенно если учесть, что во время компиляции рабочая станция буквально изрыгает горячий воздух и гудит как самолёт, а М1 тихо шуршит с едва заметным потоком тёплого воздуха.

Однопоточный бенчмарк оценивает производительность CPU в инкрементальных билдах:

$ time sh. /build2-install-0.13.0.sh --local --yes-j 1 ~ / install691s

Ядро E-2288G справляется за 826 секунд. Таким образом, ядро Xeon на 5ГГц на самом деле медленнее, чем ядро M1 на 3,2 ГГц.

Еще один интересный результат четырёхпоточный прогон, который использует только производительные ядра М1:

$ time sh ./build2-install-0.13.0.sh --local --yes -j 4 ~/install207s

Хотя он несколько медленнее восьмиядерного теста, но зато использует меньше памяти. Таким образом, такой вариант имеет смысл на системах с недостатком оперативной памяти (как на всех современных машинах M1).

Вот краткое изложение всех результатов:

CPU   CORES/THREADS  TIME-------------------------E-2288G    8/16      131sM1         4+4       163sM1         4         207sM1         1         691sE-2288G    1         826s

Понятно, что во многих отношениях это сравнение яблок с апельсинами (рабочая станция против мобильного устройства, старый дизайн и техпроцесс против самого современного и т.д.)

Теперь добавим несколько интересных результатов из бенчмарка Phoronix. В частности, уместно взять показатели новейших рабочих станций и мобильных процессоров Intel и AMD. Вот моя подборка (можете составить собственную, только не забудьте добавить дополнительные 10% к результатам Phoronix; также обратите внимание, что в большинстве тестов используется GCC вместо Clang):

CPU                    CORES/THREADS  TIME------------------------------------------AMD   Threadripper 3990X    64/128    56sAMD   Ryzen        5950X    16/32     71sIntel Xeon       E-2288G    8/16      131sApple                 M1    4+4       163sAMD   Ryzen        4900HS   8/16      176s*Apple                 M1    4         207sAMD   Ryzen        4700U    8/8       222sIntel Core         1185G    4/8       281s*Intel Core         1165G    4/8       295s* Экстраполяция.

Обратите внимание, что результаты для лучших мобильных Intel (1185G) и AMD (4900HS), к сожалению, ещё не доступны, и приведённые цифры экстраполированы на основе частоты и других бенчмарков.

Из приведённой выше таблицы легко понять, что Apple M1 впечатляющий процессор, особенно с учётом энергопотребления. Более того, это первый общедоступный ARM-процессор настольного класса. Для сравнения, та же сборка на Raspberry Pi 4B занимает 1724 секунды, то есть более чем в 10 раз медленнее! Хотя мы не можем тут загрузить Linux или Windows, но есть некоторые свидетельства, что они работают на виртуальных машинах с приличной производительностью. В итоге, конвейер непрерывной сборки на базе ARM может стать стандартным.

Увидев бенчмарки M1, невольно задаёшься вопросом, как Apple такое удалось. Хотя есть много спекуляций с некоторыми элементами чёрной магии и колдовства, но вполне хорошим источником технической информации мне показалась эта статья о M1 на Anandtech (и ещё одна там по ссылке). Основные моменты:

Процесс TSMC 5 нм
По сравнению с интеловскими 10 нм (для 11x5G, 14нм для E-2288G) и 7нм у AMD/TSMC.

LPDDR4-4266 RAM
Только новейшие мобильные процессоры от Intel и AMD работают с такой быстрой памятью.

Большой кэш L1
У M1 необычно большой кэш L1 для команд и данных.

Большой и быстрый общий кэш L2
В отличие от процессоров Intel и AMD, которые используют отдельные кэши L2 меньшего объёма и большой, но более медленный общий кэш L3, в процессоре M1 реализован быстрый и большой общий кэш L2.

Широкое ядро
У M1 необычайно широкое ядро, которое выполняет несколько инструкций параллельно и/или не по порядку. Есть предположение, что из-за слабого упорядочения памяти ARM и кодирования команд фиксированного размера, Apple смогла сделать гораздо более широкое ядро.

Было бы также интересно посмотреть, как Apple сможет масштабировать эту конструкцию на большее количество ядер.
Подробнее..

Перевод Реверс-инжиниринг GPU Apple M1

05.03.2021 10:06:07 | Автор: admin
image

Новая линейка компьютеров Apple Mac содержит в себе разработанную самой компанией SOC (систему на чипе) под названием M1, имеющую специализированный GPU. Это создаёт проблему для тех, кто участвует в проекте Asahi Linux и хочет запускать на своих машинах Linux: у собственного GPU Apple нет ни открытой документации, ни драйверов в open source. Кто-то предполагает, что он может быть потомком GPU PowerVR, которые использовались в старых iPhone, другие думают, что GPU полностью создан с нуля. Но слухи и домыслы неинтересны, если мы можем сами заглянуть за кулисы!

Несколько недель назад я купила Mac Mini с GPU M1, чтобы изучить набор инструкций и поток команд, а также разобраться в архитектуре GPU на том уровне, который ранее не был публично доступен. В конечном итоге я хотела ускорить разработку драйвера Mesa для этого оборудования. Сегодня я достигла своего первого важного этапа: теперь я достаточно понимаю набор команд, чтобы можно было дизассемблировать простые шейдеры при помощи свободного и open-source тулчейна, выложенного на GitHub.

Процесс декодирования набора команд и потока команд GPU аналогичен тому процессу, который я использовала для реверс-инжиниринга GPU Mali в проекте Panfrost, изначально организованном проектами свободных драйверов Lima, Freedreno и Nouveau. Обычно для реверс-инжиниринга драйвера под Linux или Android пишется небольшая библиотека-обёртка, инъектируемая в тестовое приложение при помощи LD_PRELOAD, подключающей важные системные вызовы типа ioctl и mmap для анализа взаимодействия пользователя и ядра. После вызова передать буфер команд библиотека может выполнить дамп всей общей памяти (расширенной) для её анализа.

В целом тот же процесс подходит и для M1, но в нём есть особенности macOS, которые нужно учитывать. Во-первых, в macOS нет LD_PRELOAD; её аналогом является DYLD_INSERT_LIBRARIES, имеющая дополнительные функции защиты, которые для выполнения нашей задачи можно достаточно легко отключить. Во-вторых, хотя в macOS существуют стандартные системные вызовы Linux/BSD, они не используются для графических драйверов. Вместо них для драйверов ядра и пространства пользователя используется собственный фреймворк Apple IOKit, критической точкой входа которого является IOConnectCallMethod (аналог ioctl). Такие различия достаточно просто устранить, но они добавляют слой дистанцирования от стандартного инструментария Linux.

Более серьёзной проблемой является ориентирование в мире IOKit. Так как Linux имеет лицензию copyleft, (законные) драйверы ядра выложены в open source, то есть интерфейс ioctl открыт, хотя и зависит от производителя. Ядро macOS (XNU) имеет либеральную лицензию, не обладающую такими обязательствами; интерфейс ядра в нём проприетарен и не задокументирован. Даже после обёртывания IOConnectCallMethod пришлось попотеть, чтобы найти три важных вызова: выделение памяти, создание буфера команд и передача буфера команд. Обёртывание вызовов выделения памяти и создания буфера необходимы для отслеживаемой видимой GPU памяти (а именно это мне было интересно исследовать), а обёртывание вызова передачи необходимо для подбора времени дампа памяти.

Преодолев эти препятствия, мы можем наконец перейти к двоичным файлам шейдеров, которые сами по себе являются чёрными ящиками. Однако далее процесс становится стандартным: начинаем с самого простого фрагментного или вычислительного шейдера, вносим небольшое изменение во входящий исходный код и сравниваем получившиеся двоичные файлы. Многократное повторение этого процесса скучное занятие, но позволяет быстро выявить основные структуры, в том числе и опкоды.

Открытия, сделанные в задокументированном процессе изучения при помощи свободного дизассемблера ПО, подтверждают наличие у GPU следующих особенностей:

Во-первых, архитектура скалярна. В отличие от некоторых GPU, которые являются скалярными для 32 бит, но векторизованными для 16 бит, GPU процессора M1 скалярен при всех битовых размерах. Хотя на ресурсах по оптимизации Metal написано, что 16-битная арифметика должна быть значительно быстрее, кроме снижения использования регистров она ведёт к повышению количества потоков (занятости процессора). Исходя из этого, можно предположить, что оборудование является суперскалярным и в нём больше 16-битных, чем 32-битных АЛУ, что позволяет получать большее преимущество от графических шейдеров низкой точности, чем у чипов конкурентов, одновременно значительно снижая сложность работы компилятора.

Во-вторых, архитектура, похоже, выполняет планирование аппаратно это часто встречается среди десктопных GPU, но менее распространено во встроенных системах. Это тоже упрощает компилятор ценой большего количества оборудования. Похоже, команды минимально тратят лишние ресурсы при кодировании, в отличие от других архитектур, вынужденных перегружать команды nop для того, чтобы уместиться в сильно ограниченные наборы инструкций.

В-третьих, поддерживаются различные модификаторы. АЛУ с плавающей запятой могут выполнять модификаторы clamp (насыщенность), операций НЕ и абсолютных значений бесплатно, без лишних затрат распространённая особенность архитектуры шейдеров. Кроме того, большинство (или все?) команды позволяют бесплатно выполнять преобразование типов между 16-битными и 32-битными значениями и для адресата, и для источника, что позволяет компилятору более агрессивно использовать 16-битные операции, не рискуя тратить ресурсы на преобразования. Что касается целочисленных значений, то для некоторых команд есть различные бесплатные побитовые отрицания и сдвиги. Всё это не уникально для оборудования Apple, но заслуживает упоминания.

Наконец, не все команды АЛУ имеют одинаковые тайминги. Команды типа imad (используется для перемножения двух целых чисел и прибавления третьего) по возможности избегаются и вместо них используются многократные команды целочисленного сложения iadd. Это тоже позволяет предположить наличие суперскалярной архитектуры; оборудование с программным планированием, с которым я взаимодействую на своей повседневной работе, не может использовать различия в длине конвейеров, непреднамеренно замедляя простые команды для соответствия скорости сложных.

По своему предыдущему опыту работы с GPU я ожидала найти какой-нибудь ужас в наборе инструкций, повышающий сложность компилятора. Хотя написанное выше охватывает только небольшую площадь поверхности набора инструкций, пока всё кажется разумным и логичным. Отсутствуют сложные трюки для оптимизации, однако отказ от трюков позволяет создать простой, эффективный дизайн, выполняющий одну задачу, и справляющийся с ней хорошо. Возможно, проектировщики оборудования Apple поняли, что простота превыше всего.

Часть вторая


В первой части я начала изучать GPU Apple M1, надеясь разработать бесплатный драйвер с открытым исходным кодом. Теперь мне удалось достичь важного этапа: отрисовать треугольник с помощью собственного кода в open source. Вершинные и фрагментные шейдеры написаны вручную на машинном коде, а взаимодействие с оборудованием выполняется с помощью драйвера ядра IOKit, подобно тому, как это происходило в системном драйвере пользовательского пространства Metal.


Треугольник, отрендеренный на M1 кодом в open source

Основная часть нового кода отвечает за построение различных буферов команд и дескрипторов, находящихся в общей памяти и используемых для управления поведением GPU. Любое состояние, доступное из Metal, соответствует битам в этих буферах, поэтому следующей важной задачей будет их анализ. Пока меня больше интересует не содержимое, а связи между ними. В частности, структуры, содержащие указатели друг на друга, иногда встроенные на несколько слоёв вглубь. Процесс подготовки треугольника в моём проекте позволяет взглянуть с высоты птичьего полёта на то, как взаимодействуют все эти отдельные части в памяти.

Например, предоставляемые приложением данные вершин хранятся в собственных буферах. Внутренняя таблица в ещё одном буфере указывает на эти буферы вершин. Эта внутренняя таблица передаётся непосредственно на вход вершинного шейдера, заданного в другом буфере. На это описание вершинного шейдера, в том числе и на адрес кода в исполняемой памяти, указывает ещё один буфер, на который сам ссылается основной буфер команд, на который ссылается вызов IOKit на передачу буфера команд. Ого!

Другими словами, код демо пока не предназначен для демонстрации понимания мелких подробностей буферов команд, а скорее служит для демонстрации того, что ничто не упущено. Так как виртуальные адреса GPU меняются при каждом запуске, демо подтверждает, что идентифицированы все необходимые указатели и их можно свободно перемещать в памяти с помощью нашего собственного (тривиального) распределителя. Так как в macOS присутствует некоторая магия, связанная с распределением памяти и буферов команд, наличие этого работающего кода позволяет нам спокойно двигаться дальше.

Я использовала поэтапный процесс подготовки. Поскольку моя обёртка IOKit располагается в то же адресном пространстве, что и приложение Metal, обёртка способна модифицировать буферы команд непосредственно перед передачей в GPU. В качестве первого hello world я задала кодирование в памяти цвета очистки render target и показала, что могу изменять этот цвет. Аналогично, узнав о наборе инструкций для вывода дизассемблера, я заменила шейдеры написанными самостоятельно эквивалентами и убедилась, что могу исполнять код в GPU, доказать, что написала машинный код. Однако мы не обязаны останавливаться на этих нодах листьев системы; изменив код шейдера, я попыталась загрузить код шейдера в другую часть исполняемого буфера, модифицировав указатель командного буфера на код, чтобы компенсировать это. После этого я смогу попробовать самостоятельно загружать команды для шейдера. Проводя разработку таким образом, я смогу создать все необходимые структуры, тестируя каждую из них по отдельности.

Несмотря на затруднения, этот процесс оказался гораздо более успешным, чем попытка перейти непосредственно к построению буферов, например, при помощи воспроизведения. Я использовала этот альтернативный способ несколько лет назад для создания драйверов Mali, однако у него есть серьёзный недостаток чудовищно сложная отладка. Если в пяти сотнях строк магических чисел присутствует хотя бы одна опечатка, то никакой обратной связи, кроме ошибки GPU, вы не получите. Однако при последовательной работе можно выявлять причины ошибок и немедленно их исправлять, что оказывается быстрее и удобнее.

Однако затруднения всё-таки были! Моё временное ликование, вызванное возможностью изменения цветов очистки, пропало, когда я попыталась выделить буфер для цветов. Несмотря на то, что GPU кодировал те же биты, что и раньше, ему не удавалось корректно выполнить очистку. Думая, что где-то ошиблась в способе модификации указателя, я попыталась поместить цвет в неиспользованную часть памяти, уже созданную драйвером Metal, и это сработало. Содержимое осталось тем же, как и способ модификации указателей, но GPU почему-то не нравилось моё распределение памяти. Я думала, что как-то неправильно распределяю память, но использованные для вызова распределения памяти IOKit были побитово идентичны тем, что использовались Metal, что подтверждалось wrap. Моей последней отчаянной попыткой стала проверка, должна ли память GPU отображаться явным образом через какой-то побочный канал, например, через системный вызов mmap. У IOKit есть устройство-независимый вызов memory map, но никакие трассировки не позволили обнаружить свидетельств отображений через сторонние системные вызовы.

Появилась проблема. Утомившись от потраченного на устранение невозможного бага времени, я задалась вопросом, нет ли чего-то магического не в системном вызове, а в самой памяти GPU. Глупая теория, потому что если это так, то появляется серьёзная проблема курицы и яйца: если распределение памяти GPU должно быть одобрено другим распределением GPU, то кто одобряет первое распределение?

Чувствуя себя глупо и ощущая отчаяние, я решила протестировать теорию, вставив вызов распределения памяти посередине потока выполнения приложения, чтобы каждое последующее распределение находилось по другому адресу. Выполнив дамп памяти GPU до и после этого изменения и изучив их отличия, я обнаружила свой первый кошмар: наличие вспомогательного буфера в памяти GPU, отслеживающего все требуемые распределения. В частности, я заметила, что значения в этом буфере увеличиваются на единицу с предсказуемым смещением (через каждые 0x40 байт), и это намекает о содержании в буфере массива дескрипторов распределений. И в самом деле, эти значения точно соответствовали дескрипторам, возвращаемым из ядра при вызовах распределения памяти GPU.

Закрыв глаза на очевидные проблемы этой теории, я всё равно её протестировала, модифицировав эту таблицу и добавив в конец дескриптор моего нового распределения, а также изменив структуру данных заголовка так, чтобы увеличить количество элементов на единицу. Это не помогло. Несмотря на разочарование, это всё равно не позволяло полностью отказаться от теории. На самом деле, я заметила в элементах таблицы нечто любопытное: не все они соответствовали действительным дескрипторам. Действительными были все элементы, кроме последнего. Диспетчеры ядра имеют индексацию с 1, однако в каждом дампе памяти последний дескриптор всегда был 0, несуществующим. Вероятно, он используется как контрольное значение, аналогично NULL-terminated string в C. Однако при таком объяснении возникает вопрос: почему? Если заголовок уже содержит количество элементов, то контрольное значение избыточно.

Я продолжила разбираться дальше. Вместо добавления ещё одного элемента с моим дескриптором, я скопировал последний элемент n в дополнительный элемент n + 1 и переписала элемент n (теперь второй с конца) новым дескриптором.

Внезапно отобразился нужный мне цвет очистки.

Итак, загадка решена? Код заработал, так что в каком-то смысле да. Но едва ли это объяснение может нас удовлетворить; на каждом этапе непонятное решение будет создавать новые вопросы. Проблему курицы и яйца решить проще всего: эта таблица отображений вместе с корневым буфером команд распределяется специальным селектором IOKit, не зависящим от распределения общего буфера, а дескриптор таблицы отображений передаётся с селектором буфера команд. Более того, идея передачи требуемых дескрипторов вместе с передачей буфера команд не уникальна; подобный механизм используется в стандартных драйверах Linux. Тем не менее, обоснование для использования 64-байтных элементов таблицы в общей памяти вместо простого массива на стороне CPU остаётся совершенно непонятной.

Но даже оставив позади проблемы с распределением памяти, двигаться вперёд пришлось не без труда. Однако благодаря терпению мне удалось полностью воссоздать память GPU параллельно с Metal, используя проприетарное пространство пользователя только для инициализации устройства. Наконец, остался последний прыжок веры отказ от синхронизации с IOKit, после чего мне удалось получить свой первый треугольник.

Для второй части статьи пришлось внести в код изменения объёмом примерно 1700 строк кода, сам код выложен на GitHub. Я собрала простое демо, анимирующее на экране треугольник с помощью GPU. Интеграция с оконной системой на этом этапе практически отсутствует: требуется XQuartz, а в ПО с наивным скалярным кодом возникает detiling буфера кадров. Тем не менее, скорости CPU M1 с лихвой хватает, чтобы с этим справиться.

Теперь, когда готова начальная загрузка каждой части драйвера пространства пользователя, двигаясь дальше, мы сможем по отдельности работать над набором инструкций и буферами команд. Можно будет разобрать мелкие подробности и побитово преобразовать код из сотен необъяснимых магических констант в настоящий драйвер.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru