> Странно, что компания подумала о чем-то вроде unrestricted guest так поздно.
Истинных причин я не знаю, но у меня есть чувство, что к первому VT-x релизу Unrestricted Guest просто не успели доделать.
> но работа эта неблагодарная и разрушает психику
…но очень интересная!
> То ли дело SVM у AMD, все несколько проще, не считаете?
Увы, на данный момент мои собственные познания в SVM ещё более скромные, чем в VMX. Когда-нибудь, когда мне будет что сравнивать, я, может быть, попытаюсь это сделать.
> а обобщенных хотя бы на верхнем уровне решений в области той же безопасности до сих пор нет.
ISA — это то, что производители процессоров используют для дифференциаций своих продуктов, поэтому от них ждать согласия в этом вопросе не приходится. А вот вендоры ПО могут попробовать обернуть всё в один общий интерфейс и вывести его на стандартизацию. И таких примеров уже немало.
Дополню список софта для чтения CPUID: Sysinternals Coreinfo
Утилита с довольно подробным выводом, умеющая читать также информацию из некоторых MSRов, связанных с поддержкой виртуализации. Например, на моей системе выдача следующая:
Ниже тов. CleverMouse совершенно правильно всё описал. Вообще в документации Intel вполне ясно это всё описывается, однако не объясняется, почему всё так, а не иначе.
Я планирую написать отдельную заметку про преобразования адресов IA-32 и в ней краешком упомянуть сегментацию. Но если этот вопрос интересен, то можно сделать и отдельный (и наверное довольно длинный) пост про сегментацию.
В документации говорится, что для стека можно использовать сегменты, растущие как вверх, так и вниз. Разница только в том, что expand-down удобнее для стеков, ёмкость которых планируется динамически изменять. Для статически выделенных оба значения бита E хороши.
Вот выдержка из Intel SDM, том 3A, глава 3, секция 3.4.5.1 «Code- and Data-Segment Descriptor Types», страницы 1997 и 1998:
If the size of a stack segment needs to be changed dynamically, the stack segment can be an expand-down data segment (expansion direction flag set). Here, dynamically changing the segment limit causes stack space to be added to the bottom of the stack. If the size of a stack segment is intended to remain static, the stack segment may be either an expand-up or expand-down type.
Я удивлён, что ни в статье, ни в обсуждении никто не упомянул средство создания mindmap для самых упоротых стойких поклонников TeX, а именно mindmap из пакета TikZ/PGF.
Если я правильно понимаю, то в этой статье вы проверяли Userspace-часть кода Vbox. Но ведь там есть и модуль ядра для использования возможностей аппаратной виртуализации. На него будете «покушаться» в дальнейшем? Было бы очень интересно, т.к. я сам работаю над похожим проектом, и интересует возможность проверки модулей ядра.
Интересный подход и интересная статья, спасибо. Хотя (и это уже заметили в обсуждении) терминология в статье немного нетрадиционная.
Если по сути, то вот такой вопрос: есть ли возможность из cpmoptimize выдавать диагностику? Т.е. в случаях, если не удалось оптимизировать конкретный цикл, то куда-нибудь пишется сообщение, почему (какие переменные помешали, настройки лимита циклов, несделанная функциональность и т.п.). Конечно, можно запускать с strict = True и ловить исключения, но часто хочется получить отчёт по всей программе в целом, не прерывая её работу, например, если вместе с профилировщиком запускать, чтобы понять, а какие циклы вообще стоит оптимизировать. Примерно так делается в компиляторах в автопараллелизаторах кода на C/C++/Fortran.
Кстати, тем, кому интересно более глубоко заглянуть в мир алгоритмов сжатия без потерь, рекомендую книгу: Lossless Compression Handbook // Khalid Sayood, editor — 2003 — ISBN-13: 978-0126208610 — ISBN-10: 0126208611
В ней разбирается всё: от теории через Колмогоровскую сложность, через LZ, BWT, арифметическое кодирование до алгоритмов TIFF, PNG и аспектов реализации аппаратных ускорителей сжатия.
Огромный плюс. Я сам эту фразу говорю в ответ на каждый, наверное, третий вопрос, который мне задают про дизайн проектов, в которых я участвую. Не всегда это означает, что всё плохо, но почти всегда означает, что, раз новому человеку непонятно, почему сделано именно так, то и самому стоит призадуматься — а стоит ли дальше так жить.
Это просто некоторые дети инстинктивно тянутся к функциональному подходу, наверное :-). Никакого мутабельного состояния, только функции и константы. Вообще очень интересное наблюдение, интересно было бы изучить, каков процент таких детей.
Спасибо! Продолжение про ГПСЧ пока не планирую, но от меня будут другие статьи. А ещё мои коллеги черкнули мне, что я забыл про RNG из состава Intel MKL, каюсь, да. Но, с другой стороны, кто лучше напишет про MKL, как не сами его авторы, так что сам жду ответного поста от них.
В этом плане наука статистика очень хорошо отражает суть позитивизма в естественнонаучном принципе познания — нельзя доказать гипотезу, но можно попытаться её опровергнуть.
В нашем случае можно попытаться огромным числом различных способов найти неслучайность в выходе ГПСЧ и потерпеть неудачу, при этом зная, что это — именно ГПСЧ. Этим мы не докажем случайность последовательности, но и не опровергнем её. Когда, например, изменятся инструменты (новые алгоритмы, больше памяти, быстрее компы), доказательство неслучайности, может быть, и будет найдено, вот тогда можно будет сказать «ага!» и выкинуть конкретный алгоритм ГПСЧ на свалку.
Очень многие проблемы возникают как раз из-за непонимания этого основного принципа как статистики, так и строгой науки в целом.
Моя гипотеза, почему некоторые тесты из TestU01 стабильно не проходят, связана с особенностями эксперимента и организации кода. А именно, оригинальный фреймворк заточен (или это я только это в нём нашёл) на тестирование 32-битных (а точнее, int) генераторов. Хотя отдельный класс для тестирования 64-битных целых (а точнее long int) там есть, похоже, что он не очень отлажен — у меня падал с ошибками, которые я хоть и исправил, но не отладил до конца (если будут силы, свяжусь с автором и попрошу совета). Однако есть работающий класс для тестирования 64-битных чисел с плавающей запятой, к коим я и привёл выводы своих генераторов (к отрезку от 0.0 до 1.0). В double-ах всего 53 бита мантиссы, т.е. 11 бит исходного числа мы теряем. Вот здесь и лежит слабое место, и возможно, что тесты это «почувствовали».
По этой причине в настоящее время генераторы с размером состояния 32 бита (и периодом 2^32) уже неактуальны.
> у «правильного» рандома из примерно 2**17 выходов хотя бы два должны совпасть
Ваш анализ правильный (и подобный тест наверняка включён в TestU01), но нужно учесть объёмы памяти и времени, необходимый для его проведения, ведь надо хранить все уже сгенерированные числа и сравнивать новые поступающие с каждым из них. Для 32-битного генератора это будет порядка 2^17 * 4 = 0.5 Мбайт, а вот для 64-битного, по аналогии, это будут уже гигабайты. Ну и время будет расти экспоненциально.
А Вы, случайно, название книги не помните, с такой табличкой? А то я только эту фотографию страницы нашёл. Хотелось бы для учебных целей и первоисточник узнать.
> Изобретать своё конечно полезно,
Ничего своего тут и не изобретено — алгоритмы давно известные, параметры для них подобраны не нами.
> но гораздо проще взять любой современный хэш\алгоритм шифрования
Он будет существенно сложнее, чем a*x + c (поправьте, если это не так). Это значит, что придётся или писать нечто более сложное самому, или завязываться на внешние библиотеки типа OpenSSL, внимательно сидеть и думать над их лицензией, над экспортным контролем и т.п.
> с гарантированной рендомностью
Ничто не гарантированно, как известно. Хочется знать ограничения выбранного решения, а не надеяться на авось.
> если совсем паранойя объяла
Тут дело не в том. Для нашей ситуации даже последовательность 1, 2,3, 4… подошла бы лучше, чем rand(), потому что она повторяема.
И тем не менее, практически всегда разрядность не больше ширины адреса. Было бы странно, если бы RISC-система, про которую утверждается, что она учла ошибки прошлого, имела 64-битные регистры, но 32-битные адреса. Если посмотреть хотя бы в легенду таблицы 4 оригинальной статьи, то можно увидеть, что обязательной базой является именно RV32I и её 32-битные по ширине регистры.
Table 4. RISC-V Integer Base Instructions (RV32I/64I/128I) and instruction formats. The base has 40 classic RISC
integer instructions, plus 10 miscellaneous instructions for synchronization, system calls, and counters. All RISC-V
implementations must include these base instructions, and we call the 32-bit version RV32I. The 64-bit and 128-bit
versions (RV64I and RV128I) expand all the registers to those widths and add 10 instructions for new data transfer
and shift instructions of the wider formats. It also shows the optional compressed instruction extension: those 12
instructions with Cx formats, which are 16 bits long. There are other optional instruction extensions defined so far:
Multiply-Divide, SP/DP/QP Floating Point, and Atomic. To learn more, see www.riscv.org
>> Включение излишнего: встроенный сдвиг в инструкциях ARM и регистровые окна SPARC
У меня наоборот чувства — за регистровые окна SPARC обидно. Их идея мне кажется здравой.
> Dhrystone, к общей убогости этого «теста»
Согласен, благо уже существуют и получше наборы тестов. Пора бы и забыть про Dhrystone, по крайней мере перестать им мериться.
Они предлагают архитектуру, которая может иметь совместимые на уровне ISA реализации с использованием только 32-битного, 64-битного или 128-битного режима адресации. Если конкретный тип систем (IoT) не требует/не может поддержать больше 32 бит, то от него не требуется реализовывать ненужные для него опциональные части.
Спасибо, очень понравилось! Отмечу, что некоторые девелоперы, ранее работавшие в Parallels и пришедшие к нам, притащили за собой и часть вашего жаргона.
Истинных причин я не знаю, но у меня есть чувство, что к первому VT-x релизу Unrestricted Guest просто не успели доделать.
> но работа эта неблагодарная и разрушает психику
…но очень интересная!
> То ли дело SVM у AMD, все несколько проще, не считаете?
Увы, на данный момент мои собственные познания в SVM ещё более скромные, чем в VMX. Когда-нибудь, когда мне будет что сравнивать, я, может быть, попытаюсь это сделать.
> а обобщенных хотя бы на верхнем уровне решений в области той же безопасности до сих пор нет.
ISA — это то, что производители процессоров используют для дифференциаций своих продуктов, поэтому от них ждать согласия в этом вопросе не приходится. А вот вендоры ПО могут попробовать обернуть всё в один общий интерфейс и вывести его на стандартизацию. И таких примеров уже немало.
Утилита с довольно подробным выводом, умеющая читать также информацию из некоторых MSRов, связанных с поддержкой виртуализации. Например, на моей системе выдача следующая:
c:\bin> Coreinfo.exe
Coreinfo v3.31 — Dump information on system CPU and memory topology
Copyright © 2008-2014 Mark Russinovich
Sysinternals — www.sysinternals.com
Intel® Core(TM) i5-4300U CPU @ 1.90GHz
Intel64 Family 6 Model 69 Stepping 1, GenuineIntel
Microcode signature: 00000017
HTT * Hyperthreading enabled
HYPERVISOR — Hypervisor is present
VMX * Supports Intel hardware-assisted virtualization
SVM — Supports AMD hardware-assisted virtualization
X64 * Supports 64-bit mode
SMX * Supports Intel trusted execution
SKINIT — Supports AMD SKINIT
NX * Supports no-execute page protection
SMEP * Supports Supervisor Mode Execution Prevention
SMAP — Supports Supervisor Mode Access Prevention
PAGE1GB * Supports 1 GB large pages
PAE * Supports > 32-bit physical addresses
PAT * Supports Page Attribute Table
PSE * Supports 4 MB pages
PSE36 * Supports > 32-bit address 4 MB pages
PGE * Supports global bit in page tables
SS * Supports bus snooping for cache operations
VME * Supports Virtual-8086 mode
RDWRFSGSBASE * Supports direct GS/FS base access
FPU * Implements i387 floating point instructions
MMX * Supports MMX instruction set
MMXEXT — Implements AMD MMX extensions
3DNOW — Supports 3DNow! instructions
3DNOWEXT — Supports 3DNow! extension instructions
SSE * Supports Streaming SIMD Extensions
SSE2 * Supports Streaming SIMD Extensions 2
SSE3 * Supports Streaming SIMD Extensions 3
SSSE3 * Supports Supplemental SIMD Extensions 3
SSE4a — Supports Streaming SIMDR Extensions 4a
SSE4.1 * Supports Streaming SIMD Extensions 4.1
SSE4.2 * Supports Streaming SIMD Extensions 4.2
AES * Supports AES extensions
AVX * Supports AVX intruction extensions
FMA * Supports FMA extensions using YMM state
MSR * Implements RDMSR/WRMSR instructions
MTRR * Supports Memory Type Range Registers
XSAVE * Supports XSAVE/XRSTOR instructions
OSXSAVE * Supports XSETBV/XGETBV instructions
RDRAND * Supports RDRAND instruction
RDSEED — Supports RDSEED instruction
CMOV * Supports CMOVcc instruction
CLFSH * Supports CLFLUSH instruction
CX8 * Supports compare and exchange 8-byte instructions
CX16 * Supports CMPXCHG16B instruction
BMI1 * Supports bit manipulation extensions 1
BMI2 * Supports bit manipulation extensions 2
ADX — Supports ADCX/ADOX instructions
DCA — Supports prefetch from memory-mapped device
F16C * Supports half-precision instruction
FXSR * Supports FXSAVE/FXSTOR instructions
FFXSR — Supports optimized FXSAVE/FSRSTOR instruction
MONITOR * Supports MONITOR and MWAIT instructions
MOVBE * Supports MOVBE instruction
ERMSB * Supports Enhanced REP MOVSB/STOSB
PCLMULDQ * Supports PCLMULDQ instruction
POPCNT * Supports POPCNT instruction
LZCNT * Supports LZCNT instruction
SEP * Supports fast system call instructions
LAHF-SAHF * Supports LAHF/SAHF instructions in 64-bit mode
HLE * Supports Hardware Lock Elision instructions
RTM * Supports Restricted Transactional Memory instructions
DE * Supports I/O breakpoints including CR4.DE
DTES64 * Can write history of 64-bit branch addresses
DS * Implements memory-resident debug buffer
DS-CPL * Supports Debug Store feature with CPL
PCID * Supports PCIDs and settable CR4.PCIDE
INVPCID * Supports INVPCID instruction
PDCM * Supports Performance Capabilities MSR
RDTSCP * Supports RDTSCP instruction
TSC * Supports RDTSC instruction
TSC-DEADLINE * Local APIC supports one-shot deadline timer
TSC-INVARIANT * TSC runs at constant rate
xTPR * Supports disabling task priority messages
EIST * Supports Enhanced Intel Speedstep
ACPI * Implements MSR for power management
TM * Implements thermal monitor circuitry
TM2 * Implements Thermal Monitor 2 control
APIC * Implements software-accessible local APIC
x2APIC * Supports x2APIC
CNXT-ID — L1 data cache mode adaptive or BIOS
MCE * Supports Machine Check, INT18 and CR4.MCE
MCA * Implements Machine Check Architecture
PBE * Supports use of FERR#/PBE# pin
PSN — Implements 96-bit processor serial number
PREFETCHW * Supports PREFETCHW instruction
Maximum implemented CPUID leaves: 0000000D (Basic), 80000008 (Extended).
Logical to Physical Processor Map:
**-- Physical Processor 0 (Hyperthreaded)
--** Physical Processor 1 (Hyperthreaded)
Logical Processor to Socket Map:
**** Socket 0
Logical Processor to NUMA Node Map:
**** NUMA Node 0
No NUMA nodes.
Logical Processor to Cache Map:
**-- Data Cache 0, Level 1, 32 KB, Assoc 8, LineSize 64
**-- Instruction Cache 0, Level 1, 32 KB, Assoc 8, LineSize 64
**-- Unified Cache 0, Level 2, 256 KB, Assoc 8, LineSize 64
**** Unified Cache 1, Level 3, 3 MB, Assoc 12, LineSize 64
--** Data Cache 1, Level 1, 32 KB, Assoc 8, LineSize 64
--** Instruction Cache 1, Level 1, 32 KB, Assoc 8, LineSize 64
--** Unified Cache 2, Level 2, 256 KB, Assoc 8, LineSize 64
Logical Processor to Group Map:
**** Group 0
c:\bin> Coreinfo.exe -v
Coreinfo v3.31 — Dump information on system CPU and memory topology
Copyright © 2008-2014 Mark Russinovich
Sysinternals — www.sysinternals.com
Intel® Core(TM) i5-4300U CPU @ 1.90GHz
Intel64 Family 6 Model 69 Stepping 1, GenuineIntel
Microcode signature: 00000017
HYPERVISOR — Hypervisor is present
VMX * Supports Intel hardware-assisted virtualization
EPT * Supports Intel extended page tables (SLAT)
Я планирую написать отдельную заметку про преобразования адресов IA-32 и в ней краешком упомянуть сегментацию. Но если этот вопрос интересен, то можно сделать и отдельный (и наверное довольно длинный) пост про сегментацию.
Вот выдержка из Intel SDM, том 3A, глава 3, секция 3.4.5.1 «Code- and Data-Segment Descriptor Types», страницы 1997 и 1998:
упоротыхстойких поклонников TeX, а именно mindmap из пакета TikZ/PGF.Взято из www.texample.net/tikz/examples/computer-science-mindmap/
Я сам для рисования именно mindmap этот пакет не использую (предпочитаю листок бумаги), но вот деревья изображать иногда получается удобно.
Если по сути, то вот такой вопрос: есть ли возможность из cpmoptimize выдавать диагностику? Т.е. в случаях, если не удалось оптимизировать конкретный цикл, то куда-нибудь пишется сообщение, почему (какие переменные помешали, настройки лимита циклов, несделанная функциональность и т.п.). Конечно, можно запускать с strict = True и ловить исключения, но часто хочется получить отчёт по всей программе в целом, не прерывая её работу, например, если вместе с профилировщиком запускать, чтобы понять, а какие циклы вообще стоит оптимизировать. Примерно так делается в компиляторах в автопараллелизаторах кода на C/C++/Fortran.
Lossless Compression Handbook // Khalid Sayood, editor — 2003 — ISBN-13: 978-0126208610 — ISBN-10: 0126208611
В ней разбирается всё: от теории через Колмогоровскую сложность, через LZ, BWT, арифметическое кодирование до алгоритмов TIFF, PNG и аспектов реализации аппаратных ускорителей сжатия.
Ответ про гипотезу чуть ниже.
В нашем случае можно попытаться огромным числом различных способов найти неслучайность в выходе ГПСЧ и потерпеть неудачу, при этом зная, что это — именно ГПСЧ. Этим мы не докажем случайность последовательности, но и не опровергнем её. Когда, например, изменятся инструменты (новые алгоритмы, больше памяти, быстрее компы), доказательство неслучайности, может быть, и будет найдено, вот тогда можно будет сказать «ага!» и выкинуть конкретный алгоритм ГПСЧ на свалку.
Очень многие проблемы возникают как раз из-за непонимания этого основного принципа как статистики, так и строгой науки в целом.
Моя гипотеза, почему некоторые тесты из TestU01 стабильно не проходят, связана с особенностями эксперимента и организации кода. А именно, оригинальный фреймворк заточен (или это я только это в нём нашёл) на тестирование 32-битных (а точнее, int) генераторов. Хотя отдельный класс для тестирования 64-битных целых (а точнее long int) там есть, похоже, что он не очень отлажен — у меня падал с ошибками, которые я хоть и исправил, но не отладил до конца (если будут силы, свяжусь с автором и попрошу совета). Однако есть работающий класс для тестирования 64-битных чисел с плавающей запятой, к коим я и привёл выводы своих генераторов (к отрезку от 0.0 до 1.0). В double-ах всего 53 бита мантиссы, т.е. 11 бит исходного числа мы теряем. Вот здесь и лежит слабое место, и возможно, что тесты это «почувствовали».
> у «правильного» рандома из примерно 2**17 выходов хотя бы два должны совпасть
Ваш анализ правильный (и подобный тест наверняка включён в TestU01), но нужно учесть объёмы памяти и времени, необходимый для его проведения, ведь надо хранить все уже сгенерированные числа и сравнивать новые поступающие с каждым из них. Для 32-битного генератора это будет порядка 2^17 * 4 = 0.5 Мбайт, а вот для 64-битного, по аналогии, это будут уже гигабайты. Ну и время будет расти экспоненциально.
Ничего своего тут и не изобретено — алгоритмы давно известные, параметры для них подобраны не нами.
> но гораздо проще взять любой современный хэш\алгоритм шифрования
Он будет существенно сложнее, чем a*x + c (поправьте, если это не так). Это значит, что придётся или писать нечто более сложное самому, или завязываться на внешние библиотеки типа OpenSSL, внимательно сидеть и думать над их лицензией, над экспортным контролем и т.п.
> с гарантированной рендомностью
Ничто не гарантированно, как известно. Хочется знать ограничения выбранного решения, а не надеяться на авось.
> если совсем паранойя объяла
Тут дело не в том. Для нашей ситуации даже последовательность 1, 2,3, 4… подошла бы лучше, чем rand(), потому что она повторяема.
Table 4. RISC-V Integer Base Instructions (RV32I/64I/128I) and instruction formats. The base has 40 classic RISC
integer instructions, plus 10 miscellaneous instructions for synchronization, system calls, and counters. All RISC-V
implementations must include these base instructions, and we call the 32-bit version RV32I. The 64-bit and 128-bit
versions (RV64I and RV128I) expand all the registers to those widths and add 10 instructions for new data transfer
and shift instructions of the wider formats. It also shows the optional compressed instruction extension: those 12
instructions with Cx formats, which are 16 bits long. There are other optional instruction extensions defined so far:
Multiply-Divide, SP/DP/QP Floating Point, and Atomic. To learn more, see www.riscv.org
У меня наоборот чувства — за регистровые окна SPARC обидно. Их идея мне кажется здравой.
> Dhrystone, к общей убогости этого «теста»
Согласен, благо уже существуют и получше наборы тестов. Пора бы и забыть про Dhrystone, по крайней мере перестать им мериться.