• Odesk закрывает аккаунты пользователей в Крыму и замораживает средства
    0
    Расскажите, пожалуйста, варианты решения проблемы.
  • Роскомнадзор заблокировал 7 страниц GitHub
    +3
    Смешные же тексты. Теперь читать уже незаконно?
  • Будущее [отсутствие] интерфейсов браузеров от Яндекса
    +2
    Не у всех панель задач снизу. У меня, вот, слева.
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    0
    Я создаю раздел в 80 гигабайт и забиваю его данными. После этого я все их удаляю и заливаю ещё 30 гигов.

    30 ГБ заливаются в те же самые секторы, где раньше лежали 80 ГБ. Таким образом контроллер понимает, что раз в тот же сектор пишут второй раз, то его можно стереть. В результате на диске будет 30 ГБ нужных данных, 50 ГБ ненужных данных, но про них контроллер не знает, что можно стереть, и будет сохранять, и 20 ГБ свободного места.

    В случае рейда надо оставлять область не размеченной каким методом: не включать в рейд или можно уже внутри рэйда создавать партицию на часть диска?

    У меня сработал способ с разделом внутри RAID. Но я не смог это объяснить, поскольку при синхронизации массива все диски будут записаны, кроме одного, надеюсь, что в комментариях прояснится.
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    –1
    настоятельная рекомендация про необходимость 10-15% свободного места на SSD

    Всё верно, за исключением того, что в некоторых случаях этого недостаточно (когда нет TRIM). Об этих случаях и статья.

    точный объём «микросхем флеш-памяти» не равен заявленному, а больше. Так же, резервная область диска вообще не может использоваться, кроме как для замены «сбойных участков»

    Я смотрю микросхемы памяти, на диске в моём примере напаяно 8 микросхем K9PHGY8U7A-CCK0 по 512 Гбит каждая, это составляет 512,00 ГБ. Может ли в микросхеме K9PHGY8U7A-CCK0 быть больше 512 Гбит? Не могу сказать достоверно, я не встречал data sheet на неё. В спецификации указано: User-Addressable Sectors: 1,000,215,216. То есть на каждый указанный сектор можно записать данные. Один сектор LBA — это 512 байт, соответственно доступно пользователю 476,94 ГБ. Получается недоступный пользователю резерв в 35,06 ГБ.

    Я не называю этот резерв over-provisioning, потому что скорее всего часть из него используется как подменный фонд для изношенных ячеек. В тесте на износ видно, что при 3500 переназначенных секторах использовано 40% резерва блоков. Если предположить, что под сектором здесь подразумевается один блок (1 МБ), то общий объём блоков, которые контроллер может переназначить — 8,54 ГБ. То есть не весь объём резервной области. Также из принципа работы видно, что совсем без свободных блоков диск бы не смог писать после полного заполнения.
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    –1
    Я не говорю, что этого не бывает. Я бы очень хотел верить, что какие-то диски сами анализируют файловую систему и очищают мусор, и вообще не заморачиваться с другими методами. Но я говорю, что:
    — это приведёт к проблемам в RAID из-за того, что данные в читаемых секторах будут меняться в непредсказуемое время,
    — нет адекватных тестов, которые покажут работу такого интеллектуального сборщика мусора. Пока все тесты показывают только обратное. Даже нет списка поддерживаемых таблиц разделов и файловых систем. Поддерживается ли GPT и HFS+, например?
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    +1
    ZFS по-умолчанию поддерживает TRIM начиная с версии FreeBSD 9.2:
    # sysctl -a | grep -i 'zfs.*trim'
    

    GEOM RAID gmirror поддерживает TRIM с FreeBSD 9.1:
    gstat -d
    
    колонка «d/s» — BIO_DELETE/second.
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    0
    т. е. при каждом чтении виртуального сектора возвращаются разные данные.

    Из-за этого не сойдётся контрольная сумма и RAID контроллер выкинет диск из массива, или будет восстанавливать. Чтобы этого избежать, каждый диск сообщает, что он поддерживает Deterministic Trim. В одном из его вариантов, запрос на чтение в любой сектор после TRIM должен вернуть 0x00, даже если сборщик мусора ещё этот сектор не трогал. Но это всё будет работать, только если все диски массива получат команду TRIM одновременно, без команды TRIM каждый будет очищать секторы в произвольное время.

    DualWrite – сжатие данных, Garbage Collection – высвобождение данных без Trim.

    Слайды показывают, что без TRIM помогает именно DuraWrite (слайд 13), сжимая и дедуплицируя. Каких-то подтверждений, что Garbage Collection самостоятельно очищает «занятые» секторы, я не нашёл.

    Цитаты в комментарии выше большей частью про работающий TRIM: в этом случае сборщику мусора нужно проделать меньше работы, если данные сжаты DuraWrite. Тест без TRIM довольно сомнительный, особенно без указаний, какие файловые системы поддерживаются контроллером.
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    0
    Протестируйте, работает ли TRIM. Если нет, то попробуйте запустить его вручную (возможно, контроллер в боксе поддерживает SCSI ATA PASS-THROUGH). Если нет, то сделайте Secure Erase и раздел для over-provisioning.

    USB 2.0 BOT (Bulk Only Transport) по стандарту не поддерживает команды ATA. Но у каждого контроллера есть свои расширения стандартов, поэтому есть возможность добыть, скажем, данные S.M.A.R.T.

    USB 3.0 UAS (USB Attached SCSI) позволят посылать команды SCSI и поддерживает TRIM и NCQ.

    ОС посылает SCSI UNMAP, которая должна транслироваться USB контроллером в боксе в ATA TRIM. И также контроллер должен сообщить ОС, что он поддерживает UNMAP. Обычно это не реализовано контроллером.

    Контроллер также поддерживает SCSI команду ATA PASS THROUGH (которую также использует hdparm -I), которая может быть использована для передачи диску ATA TRIM. Но ОС часто не умеет так делать, а общается с диском как с SCSI устройством (посылает UNMAP). В этом случае можно посылать TRIM самостоятельно программно, например, при помощи hdparm --trim-sectors.
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    0
    Да, в работе утверждается, что Corsair P64 самостоятельно очищает NTFS после Quick Format под Windows XP. В первом эксперименте после Quick Format диск начал очищаться после 300 секунд анализа, было очищено 100%. Во втором эксперименте после Quick Format диск подключили по USB (блокируя TRIM), было очищено 0,06%. В третьем эксперименте диску дали дополнительно постоять 20 минут, было очищено 18,74%. Авторы остались в недоумении.

    Вообще, Quick Format посылает команду TRIM, но Windows XP не поддерживает TRIM. С другой стороны, Windows XP не блокирует команду TRIM, и её может посылать сам драйвер или специальная утилита. Поэтому нельзя исключать, что в процессе Quick Format диску был послан TRIM, и дальше сборщик мусора ждал idle чтобы приступить к очистке.

    Corsair P64 использует контроллер Samsung, если предположить, что это из тех ранних серий, когда экспериментировали с распознаванием NTFS, то непонятно, почему в обновлённой прошивке добавляется поддержка именно "Windows 7 Trim Support on NTFS-formatted SSDs". Современные контроллеры Samsung, по моим тестам, самостоятельно не очищают блоки. Кстати, что бы сказал RAID контроллер на то, что во время очередной проверки дисков он бы увидел несовпадающие данные (RAID 1) или некорректную контрольную сумму (RAID 6), если сборщики мусора каждого диска будут работать каждый сам по себе?

    На слайде 6 сказано: «Some SSDs have tried to work around lack of Trim by trying to interpret and understand the file system format such that they can free blocks when a file is marked deleted. Works for FAT since it’s a published spec. Does not work well for NTFS: NTFS structures are much more complex than FAT, NTFS structures are not published and will change in the future.» — что можно понять как не реализовано для NTFS. И вообще большие проблемы с этим подходом, ведь не NTFS единым…

    Также есть слайды про DuraWrite, где про пользовательский раздел для over-provisioning сказано: «During initial setup and formatting, allocate a smaller partition (don’t use the full space). SSD must be either “Fresh Out of Box” (FOB) or secure erased. Leave the extra space unallocated. The SSD controller automatically uses this as additional dynamic OP» — это указывает на то, что самостоятельно диск не распознаёт и не очищает страницы.
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    0
    Я не нашёл там новых фактов. Напишите модели, где теоретически или практически подтверждено, что они понимают файловые системы, и какие именно файловые системы.
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    +3
    Да, TRIM поддерживается, но обычно не включается по соображениям безопасности. Если включить TRIM, то на диске будет видно, какие страницы удалялись, будут очерчены контуры файлов и структур файловой системы. Также не стоит включать TRIM, если внутри контейнера есть второй скрытый контейнер (для plausible deniability), поскольку либо будут видны его очертания, либо он будет поверждён (в зависимости от реализации).
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    0
    Windows Dynamic Disks и Storage Spaces скорее всего поддерживают TRIM, как и другие программные RAID сегодня.

    Также поддержка TRIM есть и в Intel RST RAID 0 — только этот тип массива в качестве исключения. Для включения нужно убедиться, что драйвер Intel RST версии 11 и выше, и прошивка OROM (Legacy boot) или SataDriver (UEFI boot) версии 11 и выше, или старая версия, но пропатченная.
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    0
    Samsung экспериментировал с поддержкой NTFS, но отказались из-за потерь данных. SandForce DuraWrite единственное что делает — это сжимает и дедуплицирует данные, стараясь, чтобы было меньше занято физических страниц. На сколько я могу судить, ни один из массовых SSD не понимает файловые системы.
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    0
    Да, задача выглядит неплохо. Показало, что TRIM для sda должен работать.
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    +1
    Вам нужно либо добавить «discard» в /etc/fstab и перезагрузиться, либо запускать «fstrim» вручную или по крону. Это не сделано по-умолчанию из-за потенциальных проблем с производительностью или потерями данных у разных контроллеров.
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    0
    Да, затирание работало для OCZ, но, скорее всего, не работает для других контроллеров, поскольку они расценивают любую запись как полезные данные, которые надо беречь.
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    0
    TRIM в реальном времени включается опцией «discard» при монтировании диска:
    # grep -i discard /etc/fstab
    # mount | grep -i discard
    

    TRIM для файловых систем и одиночных дисков поддерживается с ядра Linux 2.6.33. TRIM для mdraid поддерживается с ядра Linux 3.7. Но может быть портирован и на старые версии ядра, например, поддерживается в CentOS 6.

    По-умолчанию Ubuntu делает TRIM раз в неделю при помощи fstrim только для следующих производителей: Intel, Samsung, OCZ, SanDisk и Patriot.
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    +2
    # lsblk -D
    

    Колонки DISC-GRAN и DISC-MAX обе должны быть больше 0 для всех участвующих компонентов.

    Альтернативный вариант:
    # dd if=/dev/urandom of=tempfile bs=1M count=3
    # hdparm --fibmap tempfile
    # hdparm --read-sector [ADDRESS] /dev/sda
    # rm tempfile && sync && sleep 120
    # hdparm --read-sector [ADDRESS] /dev/sda
    

    После удаления файла на диске должны быть 0x00 или 0xFF, но это недостоверный способ: разные диски ведут себя по-разному.
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    +2
    Это не перевод, это я так выразился.
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    0
    Логика работы сборщика мусора — загадка и нигде не описана. По одним только данным тестов очень сложно сделать reverse engineering. Я думаю, что кроме паттерна «случайная запись блоками по 4 КБ и QD 32» есть и другие, более популярные паттерны, и сборщик мусора больше ориентируется на них. Также, согласен с комментарием выше.
  • Почему по мере заполнения SSD падает скорость записи в RAID, или зачем нужен TRIM
    0
    Без команды TRIM диск никогда не узнает, что страница освободилась, и сборщик мусора будет бесконечно её копировать. У Plextor M5M на борту 256 ГБ двоичных, пользователю доступны 256 ГБ десятичных, соответственно размер резервной области примерно 6,87%. Это очень мало для высокой скорости записи: полностью заполненный диск даёт максимум 6000 IOPS, если сделать 25% over-provisioning, то получим 25000 IOPS.
  • Разъяснение http2
    0
    DNS-based Authentication of Named Entities (DANE) должен решить эту проблему.
  • Справочник по уязвимости OpenSSL Heartbleed
    0
    Я уже упоминал SRP. SCRAM — это более простой и наглядный алгоритм, который может защитить процесс авторизации от прослушивания канала. Если есть ещё алгоритмы с такими же свойствами, которые ещё не упоминались, то напишите.
  • Справочник по уязвимости OpenSSL Heartbleed
    0
    Да, это минус этого алгоритма.

    Улучшим. DK рассчитывается как и ранее, но в БД сохраняем хеш от него: на сервере храним "PBKDF2-HMAC-SHA512":"1000":salt:H(DK).
    1) Клиент передаёт на сервер: логин.
    2) Сервер передаёт клиенту: случайный session_id, salt, 1000 — из БД.
    3) Клиент рассчитывает DK и HMAC и передаёт серверу XOR этих двух значений: response = HMAC(H(DK), session-id) XOR DK.
    4) Сервер также рассчитывает HMAC и делает XOR с ответом клиента, чтобы восстановить DK': DK' = HMAC(H(DK), session-id) XOR response, при этом H(DK) сервер берёт из БД. Дальше сервер рассчитывает H(DK') и сравнивает со значением в БД.

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

    Также в этот алгоритм можно добавить не только авторизацию клиента, но и авторизацию сервера: клиент убеждается, что сервер знает какой-то секрет, хранимый в БД. Подробнее такая реализация описана в RFC 5802: SCRAM.

    Слабое место алгоритма: если скомпрометирована БД, и при этом подслушан трафик настоящего клиента, то можно восстановить DK, а значит и авторизоваться как этот клиент. Но это будет работать только для этого конкретного сайта. Ещё одна угроза: если злоумышленник подслушает трафик, он может начать offline brute force атаку с целью поиска пароля, но от этого защищают только упоминавшиеся ранее алгоритмы SRP или EKE.
  • Справочник по уязвимости OpenSSL Heartbleed
    0
    Попробуем собрать полную схему из криптографических примитивов.

    Существует стандартная схема PBKDF2, которой на вход передаётся пароль, соль и число итераций, на выходе получаем хеш много раз от пароля с солью. Используем DK = PBKDF2(HMAC−SHA512, passphrase, salt, 1000 /* число итераций */, 512 /* длина результата */), при регистрации пользователя в БД сохраняем строку PBKDF2-HMAC-SHA512:1000:salt:DK.

    При логине клиенту передаём строку из БД, кроме самого хеша: PBKDF2-HMAC-SHA512:1000:salt. Клиент рассчитывает DK, зная алгоритм, число итераций, соль, и пароль, введённый пользователем. Полученное значение уже можно передавать на сервер и сравнивать с БД, но тогда любой, кто сможет один раз подслушать канал связи, сможет авторизоваться любое число раз.

    Поэтому пусть сервер сначала придумает случайный session_id, запомнит его и передаст клиенту: session_id и PBKDF2-HMAC-SHA512:1000:salt. Клиент не будет передавать DK, а рассчитает HMAC-SHA512(DK, session_id) и передаст результат. Сервер рассчитает ту же самую функцию и сравнит с данными, полученными от клиента.
  • Справочник по уязвимости OpenSSL Heartbleed
    0
    Можно хранить хеш на сервере, и его же рассчитывать на клиенте — этот хеш будет ключом.
  • Справочник по уязвимости OpenSSL Heartbleed
    0
  • Справочник по уязвимости OpenSSL Heartbleed
    0
    Для аутентификации теоретически не нужно передавать пароль, достаточно дать знать, что и сервер и клиент знают один и тот же пароль, канал передачи данных не получает никакой информации о пароле. Для этого существуют протоколы Zero-knowledge password proof: Secure Remote Password protocol (внизу практические реализации) и Encrypted key exchange.

    Если таких строгих требований — не выдать ни бита информации — нет, то можно придумать что-то проще: сервер генерирует случайное число и передаёт в браузер, браузер рассчитывает HMAC от пароля (ключ k) и полученного числа (сообщение m), сервер рассчитывает то же самое от известного пароля и сверяет с полученным от браузера.

    По сети ходит только хеш, каждый раз новый, и два раза один и тот же хеш не подходит (защита от replay attack), активный атакующий также не сможет собрать достаточно информации, поскольку, зная много пар (m, t), невозможно вычислить ключ k, удовлетворяющий условию HMAC(k, m) = t.
  • Справочник по уязвимости OpenSSL Heartbleed
    0
    Возможно, проблема самого сервиса: filippo.io/Heartbleed/faq.html
  • Справочник по уязвимости OpenSSL Heartbleed
    +1
    FreeBSD 8 и 9 не подвержены уязвимости, если, конечно, не устанавливался OpenSSL из портов или пакетов. По первой ссылке указаны и старые версии, поскольку этот advisory про две уязвимости в OpenSSL. На heartbleed.com были ошибочно указаны и версии 8 и 9, потом исправили.
  • Справочник по уязвимости OpenSSL Heartbleed
    +1
    1. Спасибо, исправил.
    2. В этом контексте нет MITM, а есть утечка приватного ключа. Используя только приватный ключ нельзя расшифровать пакеты при PFS.
    3. Верно, исправил.
    4. Вообще, да, но ECDHE считается более производительным, чем DHE.
  • Справочник по уязвимости OpenSSL Heartbleed
    0
    Спасибо, исправил.
  • Многоязыковая проверка орфографии для программ, использующих Hunspell
    0
    … и так же Miranda IM.
  • Многоязыковая проверка орфографии для программ, использующих Hunspell
    0
    Отлично, то, что я искал. Спасибо.
    Использую в Windows для Firefox, Thundebrird, Skype и Emacs.
  • Немного о хэшах и безопасном хранении паролей
    +2
    Не нужно изобретать собственные алгоритмы. Используйте:

    bcrypt,
    PBKDF2 с HMAC-SHA256 (рекомендовано NIST в SP 800-132),
    scrypt.

    Рекомендованная длина хеша.

    Множественное хеширование слегка замедляет подбор пароля, но и снижает криптографическую стойкость (сужает выходное множество значений).
  • Простой индикатор раскладки клавиатуры в курсоре на С++
    +4
    Для Chrome не знаю, но вот расширение для Firefox.
  • Debian и Ubuntu удаляют реализации jvm от oracle и sun из дистрибутивов
    0
    Раньше были проблемы, но постепенно исправляются. Сейчас у меня работает без нареканий.
  • Про догмы в криптографии
    0
    За аргументами ходить далеко не надо. Очень часто, когда программист говорит, что он лучше знает, и реализовывает криптографию самостоятельно, находятся ошибки. Даже у экспертов.

    Например, автор scrypt недавно ошибся в реализации AES-CTR и поставил под серьёзную угрозу безопасность чужих данных.
  • Про догмы в криптографии
    +4
    Не нужно изобретать собственные алгоритмы, нет, правда.

    Используйте:
    Рекомендованная длина хеша.

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