Все проблемы давно известны и исследованы, есть масса способов их решения в зависимости от конкретных условий и ограничений. Изучать эти решения/способы лучше начиная с понимания внутренностей СУБД, так как для "больших датасетов" все методы не опирающиеся на этот фундамент становятся неприемлемыми.
При этом возникают две отдельные под-темы:
обозначенная проблема произвольной сортировки, которую в результате допускают только для ограниченной подвыборки;
согласованность страничных подвыборок при волатильности данных, включая проблему "распухания" БД при длительной читающей транзакции.
Анастасия, а можно чуть подробнее о причинах побудивших задействовать clangd?
Спрашиваю потому, что давным-давно (кажется в FB) я советовал вам идти этим путем, а вы не соглашались…
Идея ваша вполне понятна, не плоха и хорошо известна, но подана очень плохо.
Все результат действия прагм примерно аналогичен созданию нескольких таблиц связанных по IDENTITY/ROWID. В MySQL это можно воспроизвести буквально, в СУБД с ROWID (PostresSQL) будет несколько иначе и примерно медленнее.
Производительность этой схемы прежде всего зависит от отношения селектов/апдейтов, в том числе для отдельных полей. Этот момент как-то совсем не рассмотрен. Более того, это imho примерно единственная точка, с которой можно без усложнений и полноценно рассмотреть все плюсы-минусы.
Добавлены отсылки к колоночным БД с их массовым перечислением, но при этом внезапно никак не упомянуты главное принципиальное отличие: Колоночные базы ориентированны на другой набор операций, поэтому как-правило не поддерживают апдейты, либо делают их крайне дорогими и без ACID. Соответственно, за счет этого могут использовать совсем другие индексы (примерно не b-tree, а зональные, битовые маски и column imprints).
В сухом остатке выходит, что в статье:
описание well-known модели нескольких b-tree с общим PK;
это описание завуалированно и подано как новый велосипед с расширением синтаксиса SQL:
модель нескольких b-tree с общим PK сопоставляется с колоночной, без рассмотрения самых главных отличий.
Вишенкой выглядит отсылка к колоночным индексам MS SQL. В целом складывается впечатление, что автор "поймал идею", но не достаточно осведомлен чтобы сопоставить её с уже существующим в индустрии и критически оценить.
Адекватный BIOS не должен оставлять на выходе разрешенные MMIO регионы, обмен с которыми (запись или чтение) может привести к side effects. Если не ошибаюсь это один из пунктов спецификаций PCI и PnP.
Вторая «любимая» ошибка — когда протокол взаимодействия с EC (и прочими так называемыми Super-I/O) требует монопольного доступа к шине. Например, когда парой OUTB специфических значений в специфические порты открывается «секретный» доступ к Super-IO контроллеру.
Для исключения конфликтов, в таких случаях на время обращения к Super-IO приходиться «глушить» все ядра на всех CPU и запрещать прерывания (15 лет назад пришлось повозиться с подобным в специфической драйвере, чтобы безопасно включать «турбо-режимы» на COM-портах).
На x86, как и на многих других архитектурах на шине CPU есть еще один сигнал, который явно показывает куда обращается CPU: к портам ввода-вывода (инструкции IN/OUT) или к памяти. Соответственно, в обязательном порядке этот сигнал должен использоваться в схеме декодирования адреса.
Поэтому "просто так" memtest не мог что-либо записать в регистры EC. Однако, ему в этом мог помочь BIOS. Сценарий такой помощи примерно всегда работает через PCI, но тут нужно кое-что пояснить:
есть PCI CONFIG SPACE (обращение со стороны процессора только посредством IN/OUT).
этот CONFIG SPACE отвечает за конфигурирование всех PCI-устройств (и всех устройств на всех логически совместимых шинах).
конфигурирование PCI-устройства предполагает:
выделение участков адресного пространства на шине в адресации CPU, но так чтобы эти адреса не были занять чем-либо другим.
в зависимости от потребностей и возможонстей PCI-устройства, таких адресных диапазонов может быть несколько, как в I/O SPACE (через IN/OUT), так и в MEM SPACE; с разным режимом допуска: R/O, R/W, non-cacheable, write-combite...
разрешение работы устройства на шине = после выделения адресов и записи в соответствующие места PCI CONFIG SPACE, должен быть выставлен еще один ENABLE бит; При этом PCI-устройство будет подключено к шине, точнее говоря начнет работать его логика декодирования адреса и станет вырабатывать чип-селекты и RDY.
Самое худшее, что может сделать гадкий BIOS = плохо сконфигурировать устройства (с перекрытием адресов) и тем более оставить подключенным в MEMORY SPACE что-то опасное. Тогда ничего не подозревающий о сюрпризе memtest может вляпаться.
В контексте статьи уместно упомянуть о libmdbx и libfpta.
libmdbx — легковесный встраиваемый key-value движок хранения. В промышленной эксплуатации с 2015 года (продукты Петер-Сервис, инфраструктура МегаФон):
не LSM, а B+Tree с отображением всех данных в память.
рой процессов может читать и обновлять данные с выполнением ACID.
wait-free для чтения, параллельно на каждом ядре CPU, без использования атомарных операций и/или примитивов синхронизации.
стоимость всех операций Olog(N) при минимальном overhead.
serializability изменений и согласованность данных после аварий.
На самом деле libmdbx — это существенно переработанная легендарная LMDB. Доработок много, все перечислены в README. Устранен либо смягчен ряд архитектурных проблем. В частности, движок обеспечивает динамическое изменения размера БД "на ходу" даже для Windows (эта мега-проблема для исходной LMDB).
libfpta — это надстройка над libmdbx, которая поверх key-value реализует таблицы со схемой, колонками, NIL-значениями и всяческими индексами, в том числе составными. В целом libfpta выполняет много рутины и предлагает более развитую модель данных. В промышленной эксплуатации libmdbx с весны 2017 года (продукты Positive Technologies).
Проблема не в TLB, а в спекулятивном выполнении с неявным кешированием.
На схеме TLB нарисован не совсем адекватно, точнее очень упрощенно-условно.
TLB также управляет кешированием (noncached, write combine) и конечно работает как при чтении, так и при записи. Поэтому корректней было-бы обозначить его "прокладкой-слоем" вокруг всей подсистемы кеширования.
Тем не менее, промах в TLB дороже промаха в кеше. Проще говоря, TLB-промахи легче заметить и они мешают увидеть кеш-промахи. Что оказывает соответствующее влияние на реализацию атак. Поэтому не 1 мегабайт, а 2.
В продолжение темы: Есть unstable microcode от Intel, можно пробовать лечиться и/или баловаться.
На всякий обращу внимание:
1) Это НЕ официальный и НЕ финальный microcode, выпущенный в конце ноября и начале декабря (Intel в курсе проблем с начала лета).
2) LFENCE в Changelog упоминается в контексте "Spectre variant #2". Тогда как в публикации Intel (по ссылке выше) в контексте "Bounds Check Bypass Mitigation", т.е. "Spectre variant #1".
Отсюда напрашивается предположения:
либо в Changelog очепятка (2 вместо 1) и на разных моделях было отличие в поведении LFENCE, которое исправлено в этом микрокоде;
либо поведение LFENCE всё-таки имеет какой-то эффект на "Spectre variant #2", но в публикации Intel это упустили в спешке.
Упоминания о LFENCE в Changelog не моего авторства, поэтому пока могу только предполагать.
Тем не менее, стоит обратить внимание, что LFENCE в Changelog упоминается в контексте "Spectre variant #2". Тогда как в публикации Intel в контексте "Bounds Check Bypass Mitigation", т.е. "Spectre variant #1".
Поэтому напрашивается предположения:
либо в Changelog очепятка (2 вместо 1) и на разных моделях было отличие в поведении LFENCE, которое исправлено в этом микрокоде;
либо поведение LFENCE всё-таки имеет какой-то эффект на "Spectre variant #2", но в публикации Intel это упустили в спешке.
Руслан, финально выскажусь чуть позже, когда закончится "голосование".
Но в целом — прилетит, ибо в сухом остатке "rocks не всех победил" и конкуренты (показывающие лучшие показатели) почему-то не используют rocks. Вот и… будем разбиться отчего, зачем и почему )
Пожалуйста, найдите время углубится в тему и матчасть, чтобы стоящее отвечать без "рука лицо".
P.S.
Жаль, что из-за проблем не смог присутствовать на вашем докладе.
Немного обижен не выполненным обещанием выслать слайды.
ID нужен чтобы отличать экземпляры, а защиту нужно делать отдельно.
С точки зрения изменяемости (или не изменяемости) запроса/ответа я вас не понял. Перепрошивку идентификатора можно разрешить или запретить, PUF всегда фиксирован. Разные запросы/ответы, то тут у вас какое-то недопонимание. Во-первых есть схемы обмена ключами и получения временных уникальных ключей по исходной соли без раскрытия секрета. При этом для PUF потребуются "отбеливание" (например посредством SHA256). Иначе будет кране высокая степень получения вырожденных преобразований и/или крайне низкая стоцкру к ряду аттак (т.е. взломщик сможет лекго восстановить функцию и заместить PUF).
Ну тут PUF совсем не обязателен. Нужен некий ID, который хранится и используется безопасным образом. Поэтому что-нибудь типа DS28E01 может быть более предпочтительным решением.
На всякий поясню:
PUF даст вам некий фиксированный случайный ID для каждого устройства, при этом значение каждого такого ID неконтролируемое (случайное).
в DS28E01 вы можете записать что хотите, в том числе более удобный (последовательный) серийный номер и один или несколько секретных ключей для расшифровки и т.д.
суть такой защиты в использовании ID, который может хранится и без PUF.
т.е. можно исключить из схемы PUF как пятое колесо.
Андрей, ну ерунду вы написали, если разобраться.
Все проблемы давно известны и исследованы, есть масса способов их решения в зависимости от конкретных условий и ограничений. Изучать эти решения/способы лучше начиная с понимания внутренностей СУБД, так как для "больших датасетов" все методы не опирающиеся на этот фундамент становятся неприемлемыми.
При этом возникают две отдельные под-темы:
Спрашиваю потому, что давным-давно (кажется в FB) я советовал вам идти этим путем, а вы не соглашались…
Судя по иллюстрациям, где прямоугольные треугольники, размером в 2 градуса по широте, наложены на поверхность земли, можно сделать вывод:
Идея ваша вполне понятна, не плоха и хорошо известна, но подана очень плохо.
Все результат действия прагм примерно аналогичен созданию нескольких таблиц связанных по IDENTITY/ROWID. В MySQL это можно воспроизвести буквально, в СУБД с ROWID (PostresSQL) будет несколько иначе и примерно медленнее.
Производительность этой схемы прежде всего зависит от отношения селектов/апдейтов, в том числе для отдельных полей. Этот момент как-то совсем не рассмотрен. Более того, это imho примерно единственная точка, с которой можно без усложнений и полноценно рассмотреть все плюсы-минусы.
В сухом остатке выходит, что в статье:
Вишенкой выглядит отсылка к колоночным индексам MS SQL. В целом складывается впечатление, что автор "поймал идею", но не достаточно осведомлен чтобы сопоставить её с уже существующим в индустрии и критически оценить.
Вторая «любимая» ошибка — когда протокол взаимодействия с EC (и прочими так называемыми Super-I/O) требует монопольного доступа к шине. Например, когда парой OUTB специфических значений в специфические порты открывается «секретный» доступ к Super-IO контроллеру.
Для исключения конфликтов, в таких случаях на время обращения к Super-IO приходиться «глушить» все ядра на всех CPU и запрещать прерывания (15 лет назад пришлось повозиться с подобным в специфической драйвере, чтобы безопасно включать «турбо-режимы» на COM-портах).
Не могу согласиться что memtest виноват.
На x86, как и на многих других архитектурах на шине CPU есть еще один сигнал, который явно показывает куда обращается CPU: к портам ввода-вывода (инструкции IN/OUT) или к памяти. Соответственно, в обязательном порядке этот сигнал должен использоваться в схеме декодирования адреса.
Поэтому "просто так" memtest не мог что-либо записать в регистры EC. Однако, ему в этом мог помочь BIOS. Сценарий такой помощи примерно всегда работает через PCI, но тут нужно кое-что пояснить:
Самое худшее, что может сделать гадкий BIOS = плохо сконфигурировать устройства (с перекрытием адресов) и тем более оставить подключенным в MEMORY SPACE что-то опасное. Тогда ничего не подозревающий о сюрпризе memtest может вляпаться.
Переформулирую. Для многозальных мероприятий Сколково хуже ада.
Последнее, что мне понравилось, при твоей гигантомании — это торговый на Пресне. Вчера там на PHD выступал, вспомнились хорошие времена )
Переформулирую. Для многозальных мероприятий Сколково хуже ада.
Последнее, что мне понравилось, при твоей гигантомании — это торговый на Пресне. Вчера там на PHD выступал, вспомнились хорошие времена )
Олежик, давай НЕ в Сколково.
Не достойная внимания малограмотнач хрень
В контексте статьи уместно упомянуть о libmdbx и libfpta.
libmdbx — легковесный встраиваемый key-value движок хранения. В промышленной эксплуатации с 2015 года (продукты Петер-Сервис, инфраструктура МегаФон):
На самом деле libmdbx — это существенно переработанная легендарная LMDB. Доработок много, все перечислены в README. Устранен либо смягчен ряд архитектурных проблем. В частности, движок обеспечивает динамическое изменения размера БД "на ходу" даже для Windows (эта мега-проблема для исходной LMDB).
libfpta — это надстройка над libmdbx, которая поверх key-value реализует таблицы со схемой, колонками, NIL-значениями и всяческими индексами, в том числе составными. В целом libfpta выполняет много рутины и предлагает более развитую модель данных. В промышленной эксплуатации libmdbx с весны 2017 года (продукты Positive Technologies).
Извините, но в статье написана примерно неправда, а гонор совершенно не оправдан.
В этом несложно убедиться https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf
--
Проблема не в TLB, а в спекулятивном выполнении с неявным кешированием.
На схеме TLB нарисован не совсем адекватно, точнее очень упрощенно-условно.
TLB также управляет кешированием (noncached, write combine) и конечно работает как при чтении, так и при записи. Поэтому корректней было-бы обозначить его "прокладкой-слоем" вокруг всей подсистемы кеширования.
Тем не менее, промах в TLB дороже промаха в кеше. Проще говоря, TLB-промахи легче заметить и они мешают увидеть кеш-промахи. Что оказывает соответствующее влияние на реализацию атак. Поэтому не 1 мегабайт, а 2.
CR3 перезагружается не для сброса TLB, а для KPTI.
И не только в обработчике исключения, а при каждом переключении user-mode/kernel-mode.
И не против Spectre, а только против Meltdown.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5aa90a84589282b87666f92b6c3c917c8080a9bf
--
В продолжение темы:
Есть unstable microcode от Intel, можно пробовать лечиться и/или баловаться.
На всякий обращу внимание:
1) Это НЕ официальный и НЕ финальный microcode, выпущенный в конце ноября и начале декабря (Intel в курсе проблем с начала лета).
2) LFENCE в Changelog упоминается в контексте "Spectre variant #2". Тогда как в публикации Intel (по ссылке выше) в контексте "Bounds Check Bypass Mitigation", т.е. "Spectre variant #1".
Отсюда напрашивается предположения:
Changelog:
2018-01-04 — Henrique de Moraes Holschuh hmh@debian.org
intel-microcode (3.20171215.1) unstable; urgency=high
New upstream microcodes to partially address CVE-2017-5715
sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552
sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432
sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792
sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528
sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328
sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648
sig 0x00050654, pf_mask 0xb7, 2017-11-21, rev 0x200003a, size 27648
sig 0x000506c9, pf_mask 0x03, 2017-11-22, rev 0x002e, size 16384
sig 0x000806e9, pf_mask 0xc0, 2017-12-03, rev 0x007c, size 98304
sig 0x000906e9, pf_mask 0x2a, 2017-12-03, rev 0x007c, size 98304
mitigation, indirect branches). Support is exposed through cpuid(7).EDX.
mitigation, conditional branches).
https://debian.pkgs.org/sid/debian-nonfree-amd64/intel-microcode_3.20171215.1_amd64.deb.html
Упоминания о
LFENCEв Changelog не моего авторства, поэтому пока могу только предполагать.Тем не менее, стоит обратить внимание, что
LFENCEв Changelog упоминается в контексте "Spectre variant #2". Тогда как в публикации Intel в контексте "Bounds Check Bypass Mitigation", т.е. "Spectre variant #1".Поэтому напрашивается предположения:
LFENCE, которое исправлено в этом микрокоде;LFENCEвсё-таки имеет какой-то эффект на "Spectre variant #2", но в публикации Intel это упустили в спешке.У кого горит CVE-2017-5715, aka #Spectre branch target injection.
Есть unstable microcode от Intel, можно пробовать лечиться и баловаться.
Changelog:
2018-01-04 — Henrique de Moraes Holschuh hmh@debian.org
intel-microcode (3.20171215.1) unstable; urgency=high
New upstream microcodes to partially address CVE-2017-5715
sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552
sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432
sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792
sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528
sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328
sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648
sig 0x00050654, pf_mask 0xb7, 2017-11-21, rev 0x200003a, size 27648
sig 0x000506c9, pf_mask 0x03, 2017-11-22, rev 0x002e, size 16384
sig 0x000806e9, pf_mask 0xc0, 2017-12-03, rev 0x007c, size 98304
sig 0x000906e9, pf_mask 0x2a, 2017-12-03, rev 0x007c, size 98304
mitigation, indirect branches). Support is exposed through cpuid(7).EDX.
mitigation, conditional branches).
https://debian.pkgs.org/sid/debian-nonfree-amd64/intel-microcode_3.20171215.1_amd64.deb.html
Руслан, финально выскажусь чуть позже, когда закончится "голосование".
Но в целом — прилетит, ибо в сухом остатке "rocks не всех победил" и конкуренты (показывающие лучшие показатели) почему-то не используют rocks. Вот и… будем разбиться отчего, зачем и почему )
Пожалуйста, найдите время углубится в тему и матчасть, чтобы стоящее отвечать без "рука лицо".
P.S.
Жаль, что из-за проблем не смог присутствовать на вашем докладе.
Леонид (MDBX и libmdbx).
ID нужен чтобы отличать экземпляры, а защиту нужно делать отдельно.
С точки зрения изменяемости (или не изменяемости) запроса/ответа я вас не понял. Перепрошивку идентификатора можно разрешить или запретить, PUF всегда фиксирован. Разные запросы/ответы, то тут у вас какое-то недопонимание. Во-первых есть схемы обмена ключами и получения временных уникальных ключей по исходной соли без раскрытия секрета. При этом для PUF потребуются "отбеливание" (например посредством SHA256). Иначе будет кране высокая степень получения вырожденных преобразований и/или крайне низкая стоцкру к ряду аттак (т.е. взломщик сможет лекго восстановить функцию и заместить PUF).
Ну тут PUF совсем не обязателен. Нужен некий ID, который хранится и используется безопасным образом. Поэтому что-нибудь типа DS28E01 может быть более предпочтительным решением.
На всякий поясню: