Тема от Neekeetos (2012-03-25 09:55:51 отредактировано Neekeetos)

  • Neekeetos
  • Посетитель
  • Неактивен

Ресурс перезаписи ячеек ключа

Приветствую,

Некоторое время назад возник вопрос насколько часто можно перезаписывать ячейки в ключах gurdant code нового поколения. Я направил письмо с вопросом в техподдержку, на что мне был дан следующий ответ от Антона Тихиенко:

Общий ресурс памяти ключа Code позволяет перезаписывать ее примерно 50000 раз. Операции (и соответствующие API-функции) записи и перезаписи данных в ключ описаны в документации (см. справочную систему по Guardant API и руководство пользователя).

и

Уточняю по поводу EEPROM - памяти в ключах Code (где собственно и хранятся защищенные ячейки, алгоритмы и.тд). Данная память имеет ресурс перезаписи минимум 1 000 000 раз и изнашивается равномерно независимо от того один участок памяти перезаписывается постоянно или разные.
Предыдущие данные (50 000) относились именно к Flash – памяти ключей Code.

Поскольку алгоритм, который я хочу использовать, критичен к количеству перезаписей ячеек, я попробовал проверить данные утверждения, и вот что получил:
Судя по тому что видно через прозрачный пластик ключа, он использует один мк, внешние микросхемы епром отсутствуют.  Я скачал даташит на данный мк (LPC1768FET), в нем отсутствует встроенный EEPROM и есть лишь flash память с гарантированным ресурсом в 10000 перезаписей. Для эмуляции EEPROM с ресурсом в 1миллион перезаписей, как заявил Антон, требуется 1000000/10000 = 100 ячеек на каждый байт, для заявленного размера еепром в 4к получается нужно 409600 байт в случае идеальной реализации wear levelling, этот объем ненамного меньше всей присутствующей в мк памяти. В виду того, что большАя ее часть уже гарантированно отдана под код пользователя, обеспечить ресурс ЕЕПРОМ формально нельзя.  Поскольку хочется обеспечить беспроблемную работу ключей, я вынужден уточнить следующие вопросы еще раз (на форуме, поскольку данный вопрос может быть интересен всем пользователям ключей code):

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

PS: попытался прикрепить изображение, но почему то не удалось. Вот оно http://neekeetos.narod.ru/code2.jpg

Ответ от Neekeetos

  • Neekeetos
  • Посетитель
  • Неактивен

Re: Ресурс перезаписи ячеек ключа

Очень радует оперативная поддержка на форуме. Тем не менее я не теряю надежды :).
Та часть задачи, которая меня сейчас волнует это создание надежного генератора случайных чисел, для этого необходимо сохранять состояние внутри ключа. Это именно та причина по которой меня интересует ресурс ключа. Я знаю сколько требуется сохранений в сутки, но не знаю сколько может выдержать ключ, а это требуется для расчета времени жизни. Вариант с сохранением врЕменных данных вне ключа, предложеный мне Антоном в почте, не подходит по вполне понятной причине - если ключ не запоминает состояние, то данные, сохраненные на компьютере можно легко подменить старыми, что недопустимо. Соотв даже сохранение данных на компьютере не убирает проблемы с ресурсом записи.
В принципе подожду еще недельку и возможно уничтожу один ключ для объективного выяснения этого вопроса, раз уж даже поддержка не в состоянии ответить ничего кроме неких придуманых сведений. Тут подсказывают еще хороший вариант с написанием после статьи на хабре, новые проблемы всегда самые интересные.

Ответ от AndreyStepin

  • AndreyStepin
  • Техническая поддержка
  • Неактивен

Re: Ресурс перезаписи ячеек ключа

Здравствуйте,

Приношу извинения за задержку с ответом. К сожалению, специалисты компетентные по данным вопросам были временно недоступны.

Мы дадим Вам ответ в понедельник.

С уважением,
Степин Андрей

Ответ от AndreyStepin

  • AndreyStepin
  • Техническая поддержка
  • Неактивен

Re: Ресурс перезаписи ячеек ключа

Отвечаю на Ваши вопросы:

1. Информация про 1 миллион циклов перезаписи маски ключа корректна. Именно на этот ресурс можно рассчитывать. Обратите внимание, здесь речь идет именно о перезаписи маски, т.е. операции в целом. Если при перезаписи КАЖДЫЙ раз маска меняется на 90% (что фактически невозможно) то ресурс будет меньше, но в усредненном случае можно открыть GrdUtil, поправить какую то информацию в маске (добавить, удалить, изменить что-то), записать маску и повторить это 1 миллион раз.

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

2. Фактически никак не влияет, общий миллион циклов все равно актуален.

3. Нет, состояние GcaGetRandom в flash не хранится, ресур памяти она не истощает.

Ответ от Neekeetos

  • Neekeetos
  • Посетитель
  • Неактивен

Re: Ресурс перезаписи ячеек ключа

AndreyStepin пишет:

Отвечаю на Ваши вопросы:
1. Информация про 1 миллион циклов перезаписи маски ключа корректна. Именно на этот ресурс можно рассчитывать. Обратите внимание, здесь речь идет именно о перезаписи маски, т.е. операции в целом. Если при перезаписи КАЖДЫЙ раз маска меняется на 90% (что фактически невозможно) то ресурс будет меньше, но в усредненном случае можно открыть GrdUtil, поправить какую то информацию в маске (добавить, удалить, изменить что-то), записать маску и повторить это 1 миллион раз.

Андрей, спасибо большое за подробный ответ!
Правильно ли я понимаю, что это касается также записей отдельных ячеек через gca(из кода пользователя) ?  Если записывать, скажем, счетчик, у которого редко когда меняется несколько байт сразу, даст ли это преимущество в ресурсе?

Ответ от AndreyStepin

  • AndreyStepin
  • Техническая поддержка
  • Неактивен

Re: Ресурс перезаписи ячеек ключа

Да, это касается и записей ячеек через GcaXXX.

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

Ответ от Neekeetos

  • Neekeetos
  • Посетитель
  • Неактивен

Re: Ресурс перезаписи ячеек ключа

AndreyStepin пишет:

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

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

Заранее спасибо!

Ответ от AndreyStepin

  • AndreyStepin
  • Техническая поддержка
  • Неактивен

Re: Ресурс перезаписи ячеек ключа

С точки зрения количества вызовов GrdWrite (GrdPI_Update) до появления первых сбоев памяти - разницы не будет. И в том и в том случае ресурс примерно 1 миллион - неважно сколько за раз байтов вы меняете - 16 или всего 1.

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