О чём я и писал в комментарии. Это путь Nero Burning ROM - мегакомбайн со свистелками. Несомненно, у такого софта тоже есть заинтересованные пользователи, но это не моё.
Такое развитие мне нравится. Не когда прога обвешивается свистелками и превращается в Nero Burning ROM или ACDSee7, а когда всё лучше и лучше выполняет базовые функции. С годами MPC-HC научился подгружать все виды субтитров, внутренних и внешних аудио-дорожек, с опциями ручного подгона субтитров и дорожек, если есть рассинхрон. Пользовательские приоритеты субтитров. Например, я могу задать правило, что если есть русская и англ. звук. дорожка, предпочитай вторую. А субтитры предпочитай русские, если звук англ, или выключай совсем, если русский. Ввели поддержку чаптеров (можно одним нажатием кнопки PgDn скипнуть титры/опенинг, если файл размечен). Скопировали с ютюба миниатюры-превьюшки при перемещении мыши над полосой прогресса. Реализовали поддержку кучи видов аппаратного ускорения. У этого софта обновления полезны.
Files may have names ending in .COM, but not be in the simple format described above; this is indicated by a magic number at the start of the file. For example, the COMMAND.COM file in DR DOS 6.0 is actually in DOS executable format, indicated by the first two bytes being MZ (4Dh 5Ah), the initials of Mark Zbikowski.
В плане же системы команд, насколько помню, нет возможности в одной команде прямо указать 64-разрядный адрес. Т.е. в 16- или 32-разрядном коде можно написать что-то вроде MOV EAX, addr32, где addr32 -- полный 32-разрядный адрес памяти; а в 64-разрядном коде такой возможности нет, и сформировать 64-разрядный адрес можно только косвенно -- используя сумму
Такое есть в ARM32/64, по понятной причине: размер инструкции фиксирован, 32 бита, и 32-битный операнд не помещается в инструкцию. Там приходится загружать "половинками".
В x64 нет таких ограничений, можете написать любую программу, оперирующую длинными 64-битными числами, и посмотреть дизассемблер, хоть в оnline на godbolt. Пример кода:
movabs rdx, 0x1234567812345678 # 48 ba 78 56 34 12 78 56 34 12
movabs rax, 0xccccddddeeeeffff # 48 b8 ff ff ee ee dd dd cc cc
чтобы у компилятора была возможность это всё собрать не совсем уж в конченые простынки
А вот не будет такой возможности.
В идеале, в архитектуре должна быть инструкция
INC DS
или
ADD DS, 4
для итерации по 0x40-байтовым структурам. Тогда код получается коротким и оптимальным.
В DOS была чехарда с типами указателей и моделями памяти, но компилятор знал, что массив, переданный через small или far-указатель, не может превышать 64k, и поэтому в цикле мог инкрементировать BX и обращаться через DS:[BX] А если передан huge указатель, то никаких гарантий на размер массива нет, и надо каждый раз пересчитывать сегмент.
В предлагаемой модели все указатели имеют единственный тип, и компилятор теряет ценную для оптимизации информацию.
Проблема в том, что в x86 нет прямой адресации всего доступного 64-битного (точнее 48-битного или сколько там сейчас тянут по максимуму?) адресного пространства ни для кода (прыжки, вызовы), ни для данных
Но обычно все компиляторы настроены на small модель в 64-битах (доступ в пределах 4Гб), редко кому нужна бывает полная адресация
Поясните, что вы имеете в виду. Обычный сишный код
#include <ctype.h>
#include <stdio.h>
#include <array>
char *messages[2] = { "OK", "CANCEL" };
int main() {
for (std::size_t i = 0; i < std::size(messages); i++) {
puts(messages[i]);
}
return 0;
}
Оперирует с полноразмерными 64-битными указателями (sizeof(char*) == 8).
Я могу поправить указатель в массиве куда угодно, за пределы 4GB-окна, и это будет работать (если по указанному адресу есть корректная строка)
messages[1] = (char*)0xAAAABBBBCCCCDDDDEEEEFFFF;
С вызовами чуть сложнее, но тоже нет никакой привязки к "модели памяти". Есть короткая форма переходов, в пределах 256 байт, обычная (в пределах 4GB) и всегда доступна "длинная", по всему 64-битному пространству.
Если говорить о классических трансляторах (компилятор → объектный файл → линковщик → бинарный файл), то в объектном файле должны быть конкретные инструкции переходов (короткие или длинные), которым линковщик подставляет смещения. Но сейчас это всё уходит в историю, потому что новые языки обходятся без объектных файлов, а то и вовсе делают jit-компиляцию. А классические C++ всё больше напирают на Link-time Code Generation оно же Whole Program Optimization, где в объектных файлах нет машинного кода, а он генерится линкером, и таким образом, линковка модулей может быть оптимально выполнена вне зависимости от "расстояния" между функциями.
В случае же динамической линковки, переходы между модулями (меджу программой и ОС, между DLL-модулями) всегда идут по 64-битному адресу, где вы увидели "small" модель?
Идея довольно крутая с точки зрения хранения указателей, мы снова возвращаемся к слову (16 бит) на указатель, отменяем всю чехарду с моделями памяти, приводя всё к этой единой.
Но проблема в том, что это не поддержано архитектурой. Нет команд типа "прибавить константу к сегментному регистру", или "загрузить сегментный регистр из ячейки памяти, напрямую или косвенно". А это значит, что код будет очень раздутым, постоянно перемещая адреса из регистров общего назначения в сегментные, данные из обычных регистры будут постоянно вытесняться этими манипуляциями.
Оверлей - кусок данных/кода, который лежит за пределами структуры exe-файла, или даже в отдельном файле. Компилятор про него ничего не знает, а программист может кусок использовать на своё усмотрение, в любой модели памяти.
Да что там hosts. Список установленного ПО - вот настоящий fingerprint. Человек может сменить фамилию, паспорт. Но привычки его выдадут. И Яндекс не сможет оправдаться тем, что список ПО нужен для фильтрации malware - вирусы себя не прописывают в список установленного ПО.
В случае с Эльбрусом, как я понимаю, государство (основной заказчик всей это эльбрусовской движухи) было против
Именно, что выложили под давлением. А если бы была "полностью независимая" альтернатива, не связанная с опен-сорсом, как пишет комментатор в начале ветки, то вообще бы ничего не выложили.
Android Firewall легковесная надстройка над системным iptables (нужно, чтобы netfilter был в ядре). Галочками можно отмечать приложения, которым разрешен трафик в разрезе интерфейсов (WiFi/LTE/VPN). Если логи, можно посмотреть какое приложение куда ходило (или пыталось) недавно.
Нет такого, как в Outpost, чтобы можно было разрешать приложениям определённые адреса или диапазоны. Но это уже и не актуально в связи в повальными CDN и балансировщиками. Хотя можно в юзер-скриптах дописать правила. Вряд ли это удобно делать с телефона.
я могу доверять своему железу, и при этом абсолютно не могу доверять софту и операционной системе, установленной на моем ПК. И я хочу дать доступ своему железу ко всей информации, которую ПК отдает в сеть
Эта задача алгоритмически неразрешима. На входе у вас заранее неизвестный алгоритм, получающий доступ к чувствительным (конечно, проще надавать программе по рукам и не дать доступ к MAC-адресам, личным файлам и т.п., но по условиям задачи мы этого не делаем). На выходе эта программа общается со своим сервером. Ваш агент, заранее написанный, должен определить утечку и отфильтровать её. В общем случае, это невозможно. Против любого агента можно написать такой алгоритм обфускации, что он ничего не заподозрит и пропустит данные.
И это очень плохо, потому что убьёт нишу систем, открытых к доработкам самим пользователями. "Страны БРИКС" спят и видят, как бы им сделать максимально закрытую ОСь, чтобы пользователь туда не мог залезть своими ручками и повыпиливать все следилки.
Huawei - флагман этого движения с его неразблокируемыми загрузчиками на телефонах, а битва за исходники отечественных Эльбрусов и Астра-линуксов, которые по лицензии (и по духу open-source) должны лежать открыто на сайте, проходит с переменным успехом.
не нравится, как играют актёры дубляжа.
О чём я и писал в комментарии. Это путь Nero Burning ROM - мегакомбайн со свистелками. Несомненно, у такого софта тоже есть заинтересованные пользователи, но это не моё.
Такое развитие мне нравится. Не когда прога обвешивается свистелками и превращается в Nero Burning ROM или ACDSee7, а когда всё лучше и лучше выполняет базовые функции. С годами MPC-HC научился подгружать все виды субтитров, внутренних и внешних аудио-дорожек, с опциями ручного подгона субтитров и дорожек, если есть рассинхрон. Пользовательские приоритеты субтитров. Например, я могу задать правило, что если есть русская и англ. звук. дорожка, предпочитай вторую. А субтитры предпочитай русские, если звук англ, или выключай совсем, если русский. Ввели поддержку чаптеров (можно одним нажатием кнопки PgDn скипнуть титры/опенинг, если файл размечен). Скопировали с ютюба миниатюры-превьюшки при перемещении мыши над полосой прогресса. Реализовали поддержку кучи видов аппаратного ускорения. У этого софта обновления полезны.
Обновился. К счастью, прогресс-бары/слайдеры не превратились в то, что нарисовано в иллюстрации к новости.
У меня отображается. Впрочем, можно пользоваться online-версией, натыкать опции, а скрипт скопировать к себе.
https://winscript.cc/online/
Об этом в википедии написано
Такое есть в ARM32/64, по понятной причине: размер инструкции фиксирован, 32 бита, и 32-битный операнд не помещается в инструкцию. Там приходится загружать "половинками".
В x64 нет таких ограничений, можете написать любую программу, оперирующую длинными 64-битными числами, и посмотреть дизассемблер, хоть в оnline на godbolt.
Пример кода:
А вот не будет такой возможности.
В идеале, в архитектуре должна быть инструкция
или
для итерации по 0x40-байтовым структурам.
Тогда код получается коротким и оптимальным.
В DOS была чехарда с типами указателей и моделями памяти, но компилятор знал, что массив, переданный через small или far-указатель, не может превышать 64k, и поэтому в цикле мог инкрементировать
BX
и обращаться черезDS:[BX]
А если передан huge указатель, то никаких гарантий на размер массива нет, и надо каждый раз пересчитывать сегмент.
В предлагаемой модели все указатели имеют единственный тип, и компилятор теряет ценную для оптимизации информацию.
Поясните, что вы имеете в виду.
Обычный сишный код
Оперирует с полноразмерными 64-битными указателями (
sizeof(char*) == 8
).Я могу поправить указатель в массиве куда угодно, за пределы 4GB-окна, и это будет работать (если по указанному адресу есть корректная строка)
С вызовами чуть сложнее, но тоже нет никакой привязки к "модели памяти". Есть короткая форма переходов, в пределах 256 байт, обычная (в пределах 4GB) и всегда доступна "длинная", по всему 64-битному пространству.
Если говорить о классических трансляторах (компилятор → объектный файл → линковщик → бинарный файл), то в объектном файле должны быть конкретные инструкции переходов (короткие или длинные), которым линковщик подставляет смещения. Но сейчас это всё уходит в историю, потому что новые языки обходятся без объектных файлов, а то и вовсе делают jit-компиляцию. А классические C++ всё больше напирают на Link-time Code Generation оно же Whole Program Optimization, где в объектных файлах нет машинного кода, а он генерится линкером, и таким образом, линковка модулей может быть оптимально выполнена вне зависимости от "расстояния" между функциями.
В случае же динамической линковки, переходы между модулями (меджу программой и ОС, между DLL-модулями) всегда идут по 64-битному адресу, где вы увидели "small" модель?
Идея довольно крутая с точки зрения хранения указателей, мы снова возвращаемся к слову (16 бит) на указатель, отменяем всю чехарду с моделями памяти, приводя всё к этой единой.
Но проблема в том, что это не поддержано архитектурой. Нет команд типа "прибавить константу к сегментному регистру", или "загрузить сегментный регистр из ячейки памяти, напрямую или косвенно". А это значит, что код будет очень раздутым, постоянно перемещая адреса из регистров общего назначения в сегментные, данные из обычных регистры будут постоянно вытесняться этими манипуляциями.
Оверлей - кусок данных/кода, который лежит за пределами структуры exe-файла, или даже в отдельном файле. Компилятор про него ничего не знает, а программист может кусок использовать на своё усмотрение, в любой модели памяти.
Компания собирает тексты, чтобы обучать на них своего чат-бота. Сгенерированные тексты будут только ухудшать качество модели.
Так дело не в галочке и не в жестах. А в том, что не хотят давать исходники. Вероятно, от нашего "как бы чего не вышло".
Да что там hosts. Список установленного ПО - вот настоящий fingerprint. Человек может сменить фамилию, паспорт. Но привычки его выдадут. И Яндекс не сможет оправдаться тем, что список ПО нужен для фильтрации malware - вирусы себя не прописывают в список установленного ПО.
Мда, глаз замылился.
Это не уровень IP (на котором работает netfilter).
DNS сервер же не знает, от какого приложения поступил запрос. Готовых решений не знаю...
Именно, что выложили под давлением. А если бы была "полностью независимая" альтернатива, не связанная с опен-сорсом, как пишет комментатор в начале ветки, то вообще бы ничего не выложили.
Android Firewall легковесная надстройка над системным iptables (нужно, чтобы netfilter был в ядре). Галочками можно отмечать приложения, которым разрешен трафик в разрезе интерфейсов (WiFi/LTE/VPN). Если логи, можно посмотреть какое приложение куда ходило (или пыталось) недавно.
Нет такого, как в Outpost, чтобы можно было разрешать приложениям определённые адреса или диапазоны. Но это уже и не актуально в связи в повальными CDN и балансировщиками. Хотя можно в юзер-скриптах дописать правила. Вряд ли это удобно делать с телефона.
Невычитанный перевод этого материала с кучей ошибок (кавычки превратились в "ёлочки", 0x в Ox и т.п.)
Эта задача алгоритмически неразрешима. На входе у вас заранее неизвестный алгоритм, получающий доступ к чувствительным (конечно, проще надавать программе по рукам и не дать доступ к MAC-адресам, личным файлам и т.п., но по условиям задачи мы этого не делаем). На выходе эта программа общается со своим сервером. Ваш агент, заранее написанный, должен определить утечку и отфильтровать её. В общем случае, это невозможно. Против любого агента можно написать такой алгоритм обфускации, что он ничего не заподозрит и пропустит данные.
И это очень плохо, потому что убьёт нишу систем, открытых к доработкам самим пользователями. "Страны БРИКС" спят и видят, как бы им сделать максимально закрытую ОСь, чтобы пользователь туда не мог залезть своими ручками и повыпиливать все следилки.
Huawei - флагман этого движения с его неразблокируемыми загрузчиками на телефонах, а битва за исходники отечественных Эльбрусов и Астра-линуксов, которые по лицензии (и по духу open-source) должны лежать открыто на сайте, проходит с переменным успехом.