Настройка BGP для обхода блокировок, или «Как я перестал бояться и полюбил РКН»

451. Помянем.

Роскомнадзор пытается решить проблему с механизмом блокировки «белыми списками»

Еще один вариант — использовать IPv6 DNS (например 2001:4860:4860::8888)
А вообще с вариантами выкручивания помогает вот эта вещь

Эволюционные вычисления: учим табуретку ходить

Скорее всего не учтены особенности MonoGame, там же один Update() — один кадр, а за один кадр не всё можно успеть так-то. Можно было бы делать вычисления в отдельном потоке, а MonoGame оставить только UI да отрисовку всяких особей.

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

Есть ещё всякие SmallVector'ы которые при малом размере хранят данные inline и прибегают к куче только когда значений много

Disney лишился авторских прав на Винни Пуха

Там скорее всего что-то вроде

#define RED_FLAG(x) (1U << ((unsigned)(x)))

Не знаю насколько это нетривиальная реализация, но позволяет использовать каждый элемент маски отдельно =)

Disney лишился авторских прав на Винни Пуха

По-моему это не уровни, а битовая маска. Каждый из флагов может быть включен и выключен независимо

Нельзя копировать код с помощью memcpy, всё намного сложнее

Ну вообще так вполне можно написать. Просто собрать отдельный испольняемый файл, position-independent, в каком-нибудь flat binary формате, подключить его как ресурс и будет счастье. А так получается да, выстрел в ногу

Почему я перепроверяю записанные данные, или История одного расследования

Нужен был простой советский...

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

Как по мне эта самая слежка — большое преимущество ютуба. Рекомендации, всё-такое

GitHub отчитался о причинах неполадок 27 ноября

Текст, вроде адекватный. Видимо, при переводе была попытка упростить его для понимания, но без знания области что-то получилость неоч

Вирус-шифровальщик для GitLab CE

Seems fun (опять eval): devcraft.io/2021/05/04/exiftool-arbitrary-code-execution-cve-2021-22204.html

DIY-фермы из смартфонов Android снова в строю

Business gonna do business. Если это выгодно (учитавая в т.ч. и законность) — это будут делать. Скрапинг тут не исключение

Вирус-шифровальщик для GitLab CE

Как-то куцо. Ожидаж увидеть в статье побольше про то, как шифровальщик вообще попал на сервер, кому платить просят, что сделать, чтобы защититься?

Встречаем ровер третьего поколения: история создания робота-курьера Яндекса

Arm поэффективнее по метрике «попугаи/Ватт». Можно было просто поставить arm побольше в случае чего

Неожиданные причины торможения программ и систем

Вот что мне подсказали знающие люди:

---

Мне известно несколько проектов, которые заменили FindFirstFileExW(, FindExInfoBasic,, FindExSearchNameMatch,, FIND_FIRST_EX_LARGE_FETCH) на вызов NtQueryDirectoryFile() напрямую, и получили прирост производительности:

• chromium/vs-chromium@ca8e2f5 — быстрее на 30-40%;
• git-for-windows/git@b69c08c — быстрее на 18%.

Но при таком низкоуровневом программировании (снятие слоёв абстракций) появляются дополнительные нюансы. Вот парочка из них:

• Нужно помнить, что багнутый драйвер может переполнить переданный в NtQueryDirectoryFile() буфер — Crash on VirtualPC (Virtual Machine Folder Sharing Driver):
  
  • основные моменты первого сообщения:
    

    So: we detected a heap corruption during freeing a block of heap memory — inside FindClose API call.
    …
    8-byte header + 0x1000 requested bytes + 16-byte footer
    …
    Library ntdll.dll checks footer bytes before freeing a heap block — values other than 0xAB mean that a buffer overflow has occurred
    …
    After few calls to NtQueryDirectoryFile I noticed that the footer of our 0x1000-byte block of memory has been overwritten with four zeroes

  • продолжение:
    

    Now some details:
    As I checked in the code of mrxvpc.sys, the bug is specific to ntdll.dll!NtQueryDirectoryFile function, no other functions are affected. NtQueryDirectoryFile calls a filesystem driver, in our case — for shared drive letters — the buggy mrxvpc.sys, which may overflow data buffer supplied by NtQueryDirectoryFile.

  
  Следовательно, необходимо аккуратно выбирать местоположение буфера в памяти:
  
  • хранение буфера в стеке нити — это очень плохая идея;
  • при использовании VirtualAlloc() (гранулярность 64 KiB) — позаботиться о корректной обработке переполнения буфера;
  • при использовании готовых (сторонних) аллокаторов памяти — включить проверку переполнения буфера.
• Если посмотреть на официальное описание функции NtQueryDirectoryFile() (MSDN Microsoft Docs), и сравнить его с описанием и кодом этой же функции в Windows Research Kernel (WRK v1.2), то внимание привлечет различие в описании параметра RestartScan:
  
  • Microsoft Docs (GitHub):
    

    RestartScan [in]
    Set to TRUE if the scan is to start at the first entry in the directory. Set to FALSE if resuming the scan from a previous call.
    When the NtQueryDirectoryFile routine is called for a particular handle, the RestartScan parameter is treated as if it were set to TRUE, regardless of its value. On subsequent NtQueryDirectoryFile calls, the value of the RestartScan parameter is honored.

  • WRK v1.2:
    

    RestartScan — Supplies a BOOLEAN value that, if TRUE, indicates that the
    scan should be restarted from the beginning. This parameter must be
    set to TRUE by the caller the first time the service is invoked.

    NtQueryDirectoryFile() → BuildQueryDirectoryIrp():
    

        if (RestartScan) {
            irpSp->Flags = SL_RESTART_SCAN;
        }
    

    т.е. флаг SL_RESTART_SCAN устанавливается только при явном задании.
  
  Возможно, где-то дальше FileHandle проверяется на «новизну» (первое использование в «service»), и устанавливается SL_RESTART_SCAN, т.е. в WRK v1.2 дано некорректное описание. Но возможно, и что в какой-то момент поведение функции NtQueryDirectoryFile() изменилось (в Microsoft Docs описано новое поведение). К сожалению, основываясь только на информации из документации, не получится определить версию системы, в которой изменилось поведение:
  
  • в Microsoft Docs написоно только:
    

    Minimum supported client: Available starting with Windows XP.

  • WRK v1.2 — это NT 5.2:
    

    The Windows Research Kernel v1.2 contains the sources for the core of
    the Windows (NTOS) kernel and a build environment for a kernel that will run on
    x86 (Windows Server 2003 Service Pack 1) and
    amd64 (Windows XP x64 Professional)

  
  Можно посмотреть, как используют NtQueryDirectoryFile() в сторонних проектах:
  
  • ReactOS при первом вызове NtQueryDirectoryFile(…,TRUE) (в FindFirstFileExW()) следует описанию из WRK v1.2;
  • а упомянутые выше git-for-windows и vs-chromium — следуют описанию из Microsoft Docs, т.е. всегда вызывают NtQueryDirectoryFile(…,FALSE):
    
    • git-for-windows: fscache.c:261-262,285-286;
    • vs-chromium: NativeFile.cs:142-159.
    
    То есть, возможно, они не смогут корректно работать ни под ReactOS, ни под WRK v1.2, ни …
    
    Возвращаясь к 18%, 30-40% приросту производительности — надеюсь, что при замерах производительности они проверили, что обработалось столько же файлов/директорий, сколько было при использовании FindFirstFileExW() …
  
  

---

…, но есть вариант прочитать все имена файлов сразу.

FindNextFile() тоже читает (во внутренний буфер) сразу несколько «файловых записей» — столько, сколько поместится в буфер:

• Windows: в обычном случае — 4 KiB;
  если FindFirstFileEx() был вызван с FIND_FIRST_EX_LARGE_FETCH — 64 KiB;
• ReactOS: 16 KiB (FindDataHandle = RtlAllocateHeap(,,…+sizeof(FIND_FILE_DATA)) ← typedef struct _FIND_FILE_DATA{…; BYTE Buffer[FIND_DATA_SIZE];} ← #define FIND_DATA_SIZE 0x4000).

---

И ещё один часто задаваемый вопрос (обычно его задают те, кто пишет драйверы, т.е. те, кто часто работают с Zw* и Nt* функциями):
Почему FindFirstFileEx() запрашивает только одну «файловую запись» (NtQueryDirectoryFile() вызывается с (,,,,,,,,ReturnSingleEntry=TRUE,,))? То есть вместо того, чтобы прочитать всё содержимое небольшой директории в первом же вызове FindFirstFileEx() (за минимум 2 переключения контекста: user_space→kernel_space→user_space) приходится вызывать FindFirstFileEx();FindNextFile(); (за минимум 4 переключения контекста: user_space→kernel_space→user_space→kernel_space→user_space)⁉︎

Оказывается, что в прикладном ПО FindFirstFileEx() часто используется, чтобы определить, пуста ли директория. Поэтому для уменьшения задержки (если в директории есть файлы, то из MFT считывается только одна запись ^{(соответствующая первому файлу)}, вместо чтения множества записей, раскиданных по разным местам внутри MFT) добавили эту оптимизацию. Также бонусом это уменьшило количество используемой памяти при рекурсивном обходе директорий, в случае, если в директории находится только одна поддиректория, например: <несколько директорий>\<одна директория>\<несколько директорий>\<одна директория>\….

А необходимость определить «пуста ли директория» чаще всего возникает при отображении TreeView элемента — нужно определить, показывать ли значок ⊞ рядом с папкой или нет.

---

Начиная с Windows 8¹ для user-space в Win32 появилась универсальная функция GetFileInformationByHandleEx() (директория — это тоже «файл»; некоторые возвращаемые ею структуры аналогичны структурам NtQueryDirectoryFile()) — см. раздел «Remarks»: любой FileInformationClass (File*Info), который имеет пару в виде класса File*RestartInfo, перечисляет содержимое дирректории.
Краткое описание всех FileInformationClass, включая поведение функции при их использовании, находится здесь.

Кстати, в описании структуры FILE_FULL_DIR_INFO описано отличие класса FileFullDirectoryInfo от FileIdBothDirectoryInfo с точки зрения задержек доступа к данным:

The FILE_FULL_DIR_INFO structure is a subset of the information in the FILE_ID_BOTH_DIR_INFO structure. If the additional information is not needed then the operation will be faster as it comes from the directory entry;

FILE_ID_BOTH_DIR_INFO contains information from both the directory entry and the Master File Table (MFT).

¹ — сама функция доступна начиная с Windows Vista (…, Windows Server 2003 и Windows XP), но некоторые классы (в частности FileFullDirectory*) доступны только начиная с Windows 8:

Windows Server 2008 R2, Windows 7, Windows Server 2008, Windows Vista, Windows Server 2003 and Windows XP: This value is not supported before Windows 8 and Windows Server 2012

Ультимативный гайд по созданию CI/CD в GitLab с автодеплоем в Kubernetes на голом железе всего за 514$ в год ( ͡° ͜ʖ ͡°)

Ещё гитлаб можно бесплатно селф-хостить (правда, не уверен насчёт интеграции с кубером)

UPD: А, ну в статье про это есть.

Как спарсить любой сайт?

По стандарту — да, но некоторые ушлые провайдеры выдают /64 на абонента, где прячется несколько компов.

Я нашел 18K+ игр в NVIDIA GeForce NOW

На девкитах не запускаются retail версии игр, насколько я знаю, там набор ключей другой. И не очень понятно почему NVIDIA будет тестировать нинтендовские приставки… Их дело сделать SoC, а помимо него там ещё много всего…

Блокировка Роскомнадзором VPN-сервисов затронула UDP-порты World of Warships

Стандарт де-факто — тоже стандарт ;)

Чуть подробнее о настройке среды разработки esp-idf для разработки приложений Esp32

А ещё очень похоже, что espressif подзабили на софтовую поддержку esp8266. По-идее в планах смержить его SDK с esp-idf, но сейчас он находится в каком-то лимбо с отдельным SDK, и неактуальными доками, но API похожим на esp-idf. Лучше к 8266 не лезть ИМХО