[WitFed 1]

Перекиньте этот запрос в более подходящую ветку, если я пока что не нашёл её. Наверняка, с этим уже кто-то сталкивался и как-то порешал.

Глобально -- есть устройство на PCI, управляемое через ПЛИС, ты ходишь в тестовом ПО по шагам, и в BAR-ы прилетают обращения R/W по дурацким адресам, которые ну никак не следуют из кода исполнения.

Ассемблер смотришь -- нет там ничего опасного. Но виснет регулярно напрочь, ибо это не предусмотрено алгоритмами работы.

Если обходить это место выше уровнем функций, то ничего страшного не происходит.

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

И в MS VS это бывает под Винду, и под Линуксом в MS Code, лет 10 точно эффект встречается, во всех версиях отладочного ПО MS.

Не помогает удаление Autos, Locals, Memory, Call Stack, чтобы на каждом шаге отладчик не лез по записанным там адресам, которые, в принципе, и не глядели в наш BAR.

Отладить отладчик -- дело немыслимое, но вдруг ключ в опциях кто-то нашёл, который выключает "левый интеллект" у него ?

В старших MS Студиях я видел оценку времени исполнения следующей строки кода, это как-то заставляет отладчик "помудрить", но и в младших попроще всё падало давно.

Какие методы лечения наработаны ?

Оно же левое не предусмотрено никакими ТЗ, читает/пишет, что захочет, и нарушает алгоритм функционирования.

[makc 192]

Из какой ОС и как именно вы обращаетесь по физическим адресам, которые определяются значениями BAR?

[WitFed 1]

Вин7 сейчас, драйвер выдал отмапленный адрес BAR-а AC0000 в моё пространство адресов размером 4 М. Просто читаю из VS.2012 по указателю, сформированному из базы виртуального адреса и смещения внутри.

Но глючит не при обращении в BAR -- оно честно происходит, а где-то рядом.

Прилетают или чтения по 4 байта из адресов 18, 10, 08, или из какого-то мусорного типа В31870, в зависимости от места, но первые 3 чаще. Это автор прошивки видит в ЛА.

В принципе, там выше/ниже в памяти всё от моего процесса, стек, данные, код, но пересекаться они не должны. Тем более, что обход "страшных" мест выше уровнем всё нивелирует.

Из Убунты на другой плате ребята тоже "делали" 4 чтения, которых не хотели -- VS Code.

Долго разбирались, концов в коде не нашли, тем более, что дизассемблера там нет, и с ним всё тоже у меня меняется...

[makc 192]

4 минуты назад, WitFed сказал:

Вин7 сейчас, драйвер выдал отмапленный адрес BAR-а AC0000 в моё пространство адресов размером 4 М. Просто читаю из VS.2012 по указателю, сформированному из базы виртуального адреса и смещения внутри.

Не знаю, на сколько это корректно в рамках винды, но вообще такой подход используется только в контексте драйвера. Где гарантия, что этот мэппинг будет жить продолжительное время в ОС, если это нештатный для ОС подход?

6 минут назад, WitFed сказал:

Но глючит не при обращении в BAR -- оно честно происходит, а где-то рядом.

Если почему-то портятся мэппинги, то обрушиться может всё что угодно.

В любом случае информации недостаточно, чтобы вам можно было посоветовать что-то конкретное. Поэтому делайте всё правильно, а неправильно не делайте. 😉

8 минут назад, WitFed сказал:

Из Убунты на другой плате ребята тоже делали 4 чтения, которых не хотели -- VS Code.

Под Linux я использовал описанный вами подход через mmap и никогда таких проблем не было. Поэтому ищите проблему в логике ПО и взаимодействия с ОС (драйвере?), а не в физике шины и логике ПЛИС.

[WitFed 1]

😉 Драйвер нам вначале всё выдал, а потом мы его трогаем в конце, чтобы отдать ресурсы обратно. Или вообще не трогаем, если программа завершается неожиданно. Хотя там тоже что-то ОС вызывает у драйвера, чтобы автоматически отключить устройство.

Макс, подскажи(те) или ссылку дай(те) на теорию, как у вас глобально всё организовано, если вся работа повешена на драйвер. по-штатному.

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

Для того MS с Intel и вводили много уровней привилегий и сертификацию драйверов, чтобы самые опасные действия были под максимальным контролем.

Потому у нас в своём драйвере что-то как-то давно наляпано и отлажено, которое открывает наш девайс, ворует у Винды все BAR-ы и маппит их адреса phis/virt, передаёт на уровень MS VS особым запросом, и там всё в шоколаде для прикладного программиста, порушить уже что-то сложнее.

Закрывается устройство -- всё размапливается и отдаётся системе, никаких признаков проблем не было.

Вот кроме этих спорадических "прилётов" от отладчика, зависящих от траектории хождения по исходнику и портящих жизнь на начальных этапах оживления и разборок, пока всё не полетит.

Вряд ли портятся маппинги, ибо в BAR-ах всё (память и регистры) работает глобально чисто, пока не закроем девайс.

Это у MS (догадываюсь) просто записей по дефолту никуда нет, ибо дело опасное, а любые чтения для своих окон отладчика из любого региона они считают несмертельными, потому много подсматривающих недоотлаженных чтений, которые нам без теории объяснить невозможно -- и когда все-все окна закрыты, всё равно что-то выстреливает и мешает.

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

[makc 192]

8 часов назад, WitFed сказал:

Макс, подскажи(те) или ссылку дай(те) на теорию, как у вас глобально всё организовано, если вся работа повешена на драйвер. по-штатному.

Если брать глобально, то с обращениями по физическим адресам MMIO должен работать только драйвер, но не пользовательские приложения. Как только подобного рода возможности появляются у приложения, то все механизмы защиты операционной системы практически сразу и практически полностью умножаются на ноль.

[WitFed 1]

Макс, это очень серьёзное заявление. Надо подкрепить логикой и конкретикой, чего мы должны бояться. Хотя это уклонение в сторону от нити топика.

Если имеем физический адрес BAR-а в драйвере, отобразим его в виртуальный и дадим пользовательскому уровню для обращений к своему устройству, то что может пользователь поломать больше драйвера в своём устройстве ?

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

И отлаживаться там гораздо сложнее, в ядре, дров можно наломать.

 

...Т.е. никто с такой проблемой "заступов" в продуктах MS не сталкивался ?

Продолжать винить себя можно, искать свои глюки, но сильно непохоже.

Записей таких левых пока не встречалось.

[makc 192]

4 минуты назад, WitFed сказал:

Макс, это очень серьёзное заявление. Надо подкрепить логикой и конкретикой, чего мы должны бояться. Хотя это уклонение в сторону от нити топика.

Безусловно, но вопрос уходит в сторону ИБ и СЗИ.

4 минуты назад, WitFed сказал:

Если имеем физический адрес BAR-а в драйвере, отобразим его в виртуальный и дадим пользовательскому уровню для обращений к своему устройству, то что может пользователь поломать больше драйвера в своём устройстве ?

Если есть возможность гарантировать, что отображение всегда будет безопасным и покрывать только очень ограниченный диапазон физических адресов, то это несколько снижает площадь поверхности возможных атак. Но при этом какими полномочиями должен обладать пользователь ОС, имеющий такую возможность? Если простой пользователь, то где гарантия, что этот пользователь, имея прямой интерфейс с железом (например, возможность настройки DMA), не воспользуется им для модификации памяти ядра с целью повышения своих привилегий или получения недоступных ему данных (например, ключей шифрования диска)? Досрочный ответ: доказать это (дать гарантии) будет очень сложно. Поэтому все идут по другому пути: при работе с железом всё запрещено, кроме непосредственно необходимого для выполнения заданной функции. Т.е. у пользователя не должно быть прямого интерфейса к железу, т.к. это нивелирует (сводит к нулю) роль встроенных в ОС средств контроля и разграничения доступа.

8 минут назад, WitFed сказал:

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

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

9 минут назад, WitFed сказал:

И отлаживаться там гораздо сложнее, в ядре, дров можно наломать.

Проще на начальном этапе, сложнее потом. Вы просто меняете этап, на котором будет большая сложность.

[RobFPGA 27]

1 hour ago, makc said:

Если простой пользователь, то где гарантия, что этот пользователь, имея прямой интерфейс с железом (например, возможность настройки DMA)

Для этого давно уже придумали IOMMU которая виртуализирует физ. адреса для DMA, и соответственно система контролирует доступ к ним.  

[makc 192]

24 минуты назад, RobFPGA сказал:

Для этого давно уже придумали IOMMU которая виртуализирует физ. адреса для DMA, и соответственно система контролирует доступ к ним.  

Совершенно верно, придумали давно. А повсеместно внедрили давно ли? И на сколько надёжно сейчас работает этот механизм?

PS: Речь про Windows 7, если что.

[Мышка_Норушка 1]

10 hours ago, WitFed said:

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

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

Отладчики пишутся с учетом того что всё,  за чем можно наблюдать находится в памяти процесса и это можно читать, а тут херась, какой-то из указателей в окне переменных нацелен на MMIO кусок, которую оказывается нельзя трогать даж на чтение. Варианты 1) менять отладчик 2) пропачить сущ. отладчик (я про GDB) 3) при отладке не спускатся туда,  где обращение к mmio 3) где-то ошибка в вашем коде, вы думаете что отладчик пишет в BAR, но пишет что-то другое или вообще ошибка в реализации PCI шины и т.п.

p.s. Как-то копался в виндовом usb3 драйвере, содержимое mmio выводил в отдельное окно, с железом ничего не происходило, так как на чтение BAR такая железка никак не реагирует и не должна

[WitFed 1]

Ура, Мышка по делу высказалась. СпасиБо за отзывчивость.

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

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

Без отладочных действий, но из Студии по F5, всё работает чисто, и нет ни одного окна, которое можно заподозрить в подсмотрах, и указателей тем более на уровне степанья. Т.е. скомпилированный код сам чист.

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

Сколько любители усложнений на 2-3 порядка ни думают вширь, всё равно вирусов и хакеров меньше не становится, а дырок -- только больше, ибо путь тупиковый.

И всё в зверски мощных гаджетах больше и больше тормозит, что есть маркетинг, основа демо-жизни.

Норушка, есть ещё одно лекарство, но я от своих желязячников его никак не добьюсь за 10+ лет: чтобы запросы чтения в общую шину всегда возвращали хоть FF, и хоть через секунду, это недорого, как бывает обычно устроено в сильнее развитых архитектурах.

Когда-то жареный клюнет наконец, качества и надёжности захочется не только на словах.

MS на этом свойстве Intel базируется, исключения у них могут происходить при обращении не туда, а когда у нас "собирающий" и "окружающий" массу содержимого блок не отвечает за "небазар" своих подчинённых, мы потом неделями отлаживаемся и ловим неописаные глюки отладчиков, в которых логику ещё надо найти.

[Мышка_Норушка 1]

16 hours ago, WitFed said:

MS на этом свойстве Intel базируется, исключения у них могут происходить при обращении не туда, а когда у нас "собирающий" и "окружающий" массу содержимого блок не отвечает за "небазар" своих подчинённых, мы потом неделями отлаживаемся и ловим неописаные глюки отладчиков, в которых логику ещё надо найти.

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

Я бы упрятал обращения к mmio в отдельные процедуры с локальным контекстом, доступным только внутри них, т.е. типа ReadBAR(), WriteBAR(), все поинтеры внутри. Отладчиком внутрь не лезть, содержимое mmio если надо видеть только как результат подобных функций.

[WitFed 1]

Да, была такая функция, но в силу видения "выстрелов в молоко" не сильно верится в её использование.

Хотя и в мою дееспособность тоже, 😉 если ни у кого таких проблем больше нет.

Вот примеры обёрток:

ULL FParamUnit = (ULL)&pUM_local; // Структура с параметрами модуля, это указатель, его память вернута из драйвера, обращение к ней в отладчике почему-то вешает ПЛИС, потому обёрнуто функциями
WCHAR* get_HardwareId() { PPARAM_FOR_USERMODE pu = (PPARAM_FOR_USERMODE)FParamUnit;  return pu->HardwareId; }
ULONG get_vBarMem_Count() { PPARAM_FOR_USERMODE pu = (PPARAM_FOR_USERMODE)FParamUnit;  return pu->vBarMem_Count; }
DEF_DLL_EXP(ULL) get_vBarMem_Size(ULONG i) { PPARAM_FOR_USERMODE pu = (PPARAM_FOR_USERMODE)FParamUnit;  return pu->vBarMem_Size[i]; }
ULL getPhis(ULONG i) { PPARAM_FOR_USERMODE pu = (PPARAM_FOR_USERMODE)FParamUnit;  return pu->memBase[i]; }
ULL getVirt(ULONG i) { PPARAM_FOR_USERMODE pu = (PPARAM_FOR_USERMODE)FParamUnit; return pu->pBarMem_Virt[i]; }
int /*bool*/ isBAR(ui bar) { PPARAM_FOR_USERMODE pu = (PPARAM_FOR_USERMODE)FParamUnit;  if (!pu || bar >= pu->vBarMem_Count) return 0;  return 1; }

pUM_local -- статическая переменная, её заполнение идёт в ините устройства по памяти, выданной нашим драйвером, со всеми добытыми нужными потрохами.

Её адрес кастуется в длинное целое, в обёртках выкастовывается обратно, идут чтения и возврат значений.

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

Там в структуре есть физические и виртуальные адреса, они разыменовываются после получения в других функциях типа:

ULONG getUL(ULL a) { PULONG p = (PULONG)a;  return *p; }
void putUL(ULL a, ULONG d) { PULONG p = (PULONG)a;  *p = d; }
ULL getULL(ULL a) { ULL *p = (ULL*)a;  return *p; }

Но "стреляет" и виснет даже не возле них, а возле первых, вызовы типа:

ULL pB = getVirt(barR) + ofsR;

Что заставляет Студию лазить адресам, соответствующим целым числам, совсем неясно.

Типа очень крутой ИИ, прослеживающий всё на "годы вперёд" и без Релиза, что потом из pB будет скастован указатель, который можно нам показать "ради удобства" незаказанного, или что-то ещё...

И обращения не в саму эту память, а рядом или "в молоко", хотя и повторяемое от зависания к зависанию.

Незря нам Илон Маск (++) предлагает нейросети запретить.

Даже если кнопку "Выкл" к ним прикрутишь, а они её изнутри отгрызут 😉