[Gorby 6]

2 hours ago, makc said:

будут требовать совпадения результатов сборки с эталоном, предоставленным разработчиком или объяснить почему именно наблюдаются несовпадения.

Позвольте с Вами не согласиться.

Собственно, Вы со мной соглашаетесь с оговорками :) Ну и ладно, здесь не ристалище  

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

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

 

 

[Baser 5]

48 минут назад, Gorby сказал:

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

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

А как это происходит сейчас, когда память программ внутри контроллера и защищена лок-битами?
Мы на эти требования пока "кладем" (лет 20 уже...), но могут же и придраться...

[makc 207]

27 минут назад, Baser сказал:

А как это происходит сейчас, когда память программ внутри контроллера и защищена лок-битами?

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

[ViKo 1]

1 час назад, makc сказал:

В идеале эта контрольная сумма должна формироваться с использованием переданного при запросе параметра (условного ключа).

Начальное значение при расчёте контрольной суммы. Дёшево и сердито.

[Baser 5]

2 часа назад, makc сказал:

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

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

Тем более, что такие вещи должны быть стандартизированы, а то мало ли что придет в голову проверяющим.
Мы вот столкнулись недавно с проблемами с продлением сертификата на ATEX. У них поменялись люди, и ушел человек, который подписывал старый сертификат. А новый говорит: "В стандарте сказано Zener barrier, а вы применили Transil (TVS) - это не годится!" И уперся рогами...

[makc 207]

15 минут назад, Baser сказал:

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

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

18 минут назад, Baser сказал:

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

Скорее не стандартизированы, а согласованы с органами по сертификации и лабораториями.

1 час назад, ViKo сказал:

Начальное значение при расчёте контрольной суммы. Дёшево и сердито.

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

[Baser 5]

3 часа назад, makc сказал:

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

Я действительно не понимаю смысл этих требований в современных условиях. Для "Описания типа средства измерения" от нас требовали "Цифровой идентификатор ПО (контрольная сумма исполняемого кода)", алгоритм расчета и номер версии ПО. Это все указано в сертификате. При этом нет возможности эту контрольную сумму как-то проверить (и это никто не требовал). И в сертификате есть примечание, что номера версий приборов могут быть больше указанной, и с другими контрольными суммами.
Так что я вижу тут один формализм.

[Darth Vader 0]

11 часов назад, Arlleex сказал:

как Вы вообще планировали проходить сертификацию, разрабатывая на коммерческом платном ПО?

Уже выше ответили, что платность/бесплатность компилятора никак не влияет на сертификацию. Единственная моя проблема сейчас, это как не передавать наш лицензионный ключ третьим лицам.

Удалось сгенерировать пакетный файл сборки проекта (Options->Output->Create Batch File) и собрать его в произвольном месте. Но вот выделить отдельно компилятор и заставить его работать из произвольного места - нет. Ругается, что нет лицензии. Не понимаю, откуда он берет лицензию, работая в своей родной папке, и почему не может найти её, работая в другой.

[makc 207]

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

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

https://docs.microsoft.com/en-us/sysinternals/downloads/procmon Вам в помощь

[Arlleex 160]

15 минут назад, Darth Vader сказал:

Уже выше ответили, что платность/бесплатность компилятора никак не влияет на сертификацию...

Я акцент на другом сделать хотел. Мне было интересно, как Вы планировали ее (сертификацию) проходить. Вы же (надеюсь) прекрасно понимали, что с Keil-ом у сертифицирующего органа могут возникнуть проблемы? Так почему нельзя было сразу разрабатывать на том, что будет доступно и Вам, и им без лишних танцев с бубном? Или это банально незапланированная движуха с сертификацией? А у Вас на рабочем компе лицензия платная? Может, обратиться прямиком к Keil-девелоперам? Мне кажется, Вы далеко не первый с такой проблемой

[one_eight_seven 6]

On 4/25/2021 at 8:55 PM, Forger said:

 Купить лицензию тестировщикам, это ж не проблема для серьезной организации ))

Причëм тут лицензия? Автотесты - это программа, а не обезьяна, ей ни к чему гуи с кнопочками. А лицензии - это про другое.

[Arlleex 160]

9 часов назад, Gorby сказал:

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

Ну, такое У меня после заливки прошивки внутренний загрузчик блокирует доступ отладчика на чтение памяти, поэтому простыми средствами эту самую прошивку не получить. Заложить в протоколе обмена возможность "выкачать" содержимое всей Flash можно, но это потенциальная уязвимость для любителей клонировать, поэтому такой возможности я не закладываю априори. К тому же (я не компетентен, но мне рассказывали якобы умные дядьки) некоторые специалисты из того же ФСБ могут подобного рода уязвимости считать некой "закладкой" и, отстегнув лещей разработчикам, заставить убрать. Кроме того, после заливки прошивки некоторые мои девайсы должны пройти этап конфигурирования - назначение всяких MAC/ID и т.д. Поэтому итоговый бинарный образ может быть совершенно не тем, что ожидается. Вдогонку сюда же - у меня запускаются специальные пост-утилиты, которые над выходным hex-файлом осуществляют некоторые манипуляции (считают и вставляют в нужное место некоторые атрибуты образа - CRC32, размер и т.д.). Поэтому, ИМХО, филькина грамота она - сертификация по соответствию чего-то чему-то. Может, правда, когда-то это и было актуально.

[Forger 20]

1 hour ago, Darth Vader said:

Ругается, что нет лицензии.

Я предупреждал ))

[Harbinger 10]

9 часов назад, Baser сказал:

Для "Описания типа средства измерения" от нас требовали "Цифровой идентификатор ПО (контрольная сумма исполняемого кода)", алгоритм расчета и номер версии ПО. Это все указано в сертификате. При этом нет возможности эту контрольную сумму как-то проверить (и это никто не требовал). И в сертификате есть примечание, что номера версий приборов могут быть больше указанной, и с другими контрольными суммами.

Сталкивались с тем же (именно метрология). Номер версии разрешили менять, а вот изменение КС (строго говоря - CRC32) чревато повторной процедурой сертификации. Пришлось при выпуске новых версий её подгонять с помощью небольшого блока с "левым" содержимым. 

Из кода был предоставлен алгоритм CRC32, больше ничего.

[Arlleex 160]

2 часа назад, Harbinger сказал:

Пришлось при выпуске новых версий её подгонять с помощью небольшого блока с "левым" содержимым. 

А не проще было прописать любую нужную CRC32 в нужное место и не париться на этот счет никогда более?