The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Microsoft открыл CHERIoT, аппаратное решение для повышения безопасности кода на языке Си, opennews (??), 01-Мрт-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


3. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +47 +/
Сообщение от Аноним (3), 01-Мрт-23, 10:14 
Настоящий сишник меняет аппаратуру под себя. Диктует свои правила.
Ответить | Правка | Наверх | Cообщить модератору

30. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от Советский инженер (?), 01-Мрт-23, 11:16 
такой же настоящий, как и автолюбитель, который меняет машину когда пепельница переполнилась?
Ответить | Правка | Наверх | Cообщить модератору

42. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от YetAnotherOnanym (ok), 01-Мрт-23, 12:03 
Нет, как автолюбитель, который ставит "карбоновое" антикрыло на багажник и дырявое ведро вместо глушителя.
Ответить | Правка | Наверх | Cообщить модератору

169. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (-), 01-Мрт-23, 20:59 
> Настоящий сишник меняет аппаратуру под себя. Диктует свои правила.

Если посмотреть на то как изменилось современное железо... эээ... вообще-то да, все именно так :).

Процы стали делать удобными для именно сишки, самые видные это Cortex'ы армовские. Железо чего-то стало mem-mapped, без всяких in/out в левых адресных пространствах. И так далее. И чего это они? :)

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

229. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +3 +/
Сообщение от Nope (?), 02-Мрт-23, 13:11 
Главный прогиб под C - это RISC-V, где нет флагов.
Соответственно весь тот геморой, который нужен для сложения числе размера в два раза больше слова реализуется один в один как C код, сложение, сравнение и т.д., без всяких add adc
Ответить | Правка | Наверх | Cообщить модератору

230. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (235), 02-Мрт-23, 13:21 
Уже объясняли о вреде этих флагов на переупорядочивание выполнения команд.
Ответить | Правка | Наверх | Cообщить модератору

244. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +3 +/
Сообщение от непох2 (?), 02-Мрт-23, 14:43 
> Уже объясняли о вреде этих флагов на переупорядочивание выполнения команд.

Стоит уточнить, что мешают не флаги, а только когда эти флаги общие и/или помещены в один логический регистр (который можно push/pop/load/store/move).

А вот отсутствие ADC, SBB и т.п. в RISC-V = это просто сознательная ущербность ради экономии "на спичках", что действительно было разумно для исходного целевого сегмента этой ISA (low-end ЦПУ и микроконтроллеров).

Технически ADC/SBB и прочее прекрасно реализуется без общего флага переноса, просто дополнением каждого регистра своими carry/overflow флагами.
Соответственно, тогда ADD/SUB всегда формируют carry в целевом регистре, а ADC/SBB берут его из источников.
MOV копирует между регистрами, а LOAD очищает...

Поэтому, RISC-V ISA - это недодуманное, недопеределанное УГ, которое более-менее подходит для low-end, а его натягивание на широкий сегмент и high-end создаст массу проблем лет на 20 (как было c x86), в том числе с безопасностью/дырявостью.

Кто-то это уже это понял, но большинство просто потребляют рекламную информацию.

Ответить | Правка | Наверх | Cообщить модератору

246. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +2 +/
Сообщение от Вечно недовольный аноним (?), 02-Мрт-23, 15:31 
> просто дополнением каждого регистра своими carry/overflow флагами.

Это ваши фантазии или это где-то так сделано?

Ответить | Правка | Наверх | Cообщить модератору

251. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от x3who (?), 02-Мрт-23, 19:03 
Если это нигде не сделано - это не значит, что не нужно. Реализация этих флагов проста, а выподвыверты чтобы их обойти будут стоить дополнительных тактов ЦПУ.
Ответить | Правка | Наверх | Cообщить модератору

297. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от аффтар (?), 03-Мрт-23, 12:53 
Штеуд сделал это 10 лет назад в таком виде https://en.wikipedia.org/wiki/Intel_ADX

Как-то иначе в рамках x86 примерно не возможно.

Ответить | Правка | К родителю #246 | Наверх | Cообщить модератору

307. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от Аноним (307), 04-Мрт-23, 09:13 
Ты сам-то эту страницу читал? Где там написано про бред анона с кэри\оверфлоу флагом для каждого регистра.
Ответить | Правка | Наверх | Cообщить модератору

331. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 08-Мрт-23, 08:43 
> Ты сам-то эту страницу читал? Где там написано про бред анона с
> кэри\оверфлоу флагом для каждого регистра.

Кэри и оверфлоу флаги явно проверять - это лишние команды. Т.е. нафиг надо, скорость угробит и никто это делать не будет. Вот хардварный эксепшн как в сабже это еще куда ни шло. Дожили - майкрософт адекватней экспертов опеннета.

Ответить | Правка | Наверх | Cообщить модератору

272. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от _kp (ok), 02-Мрт-23, 21:29 
Ну и много ли хотя бы  в 32х битном коде на ассемблере работы с флагами вне операций сравнения? Если без них можно обойтись, то и проблемы нет.

Для многих процессоров, возьмем для примера cortex m3 stm33, можно написать весь код на Си, включая таблицы векторов прерываний. Единственное останется несколько ассемблерных макросов для барьеров, прерываний, и подобных мелочей.

Сейчас на ассемблере не пишут, и вполне можно оптимизировать процессор под код из под компилятора.

Ответить | Правка | К родителю #244 | Наверх | Cообщить модератору

296. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от аффтар (?), 03-Мрт-23, 12:49 
Как уже многократно было сказано: RISC-V ISA исходно проектировалась для low-end ЦПУ и микроконтроллеров.
Для этого она (система команд) неплохо.
Собственно, привыкши к мопедам m3 и stm, вы не видите проблем и не чувствуете дискомфорта.

Но для high-end ЦПУ, без необходимости экономии на спичках, система команд RISC-V неудобна, мягко говоря. И жизнь продолжает это иллюстрировать/доказывать.

--

Ассемблер тут не критерий, и по-сути вообще не причем.
В актуальных компиляторах есть развитые интринсики, поэтому всё чаще можно написать переносимый код, при этом не менее эффективный/быстрый чем на asm.

Аналогично с флагами - важны не сами флаги, а наличие в ISA и железе эффективного механизма контроля переполнений, сложения/вычитания "столбиком" (с переносом/заёмом), широкого умножения и деления. Поэтому у штеуда, кроме унаследованной ADC есть новая ADX, а в компиляторах всяческие __builtin_add_overflow(), __builtin_addcll() и _addcarry_u64().

Но обойтись можно, проблем нет, просто работает медленнее.
В этом весь RISC-V = много чего недодумано, недопеределано, а тут мы рыбу заворачивали, но хайпово...

Ответить | Правка | Наверх | Cообщить модератору

332. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 08-Мрт-23, 08:47 
> Но для high-end ЦПУ, без необходимости экономии на спичках, система команд RISC-V
> неудобна, мягко говоря. И жизнь продолжает это иллюстрировать/доказывать.

Для high-end cpu мы никогда не видим их систему команд и нам так то похрен. И для компилера это лишь некий интерфейс а реально это бэкэнд. И никакие carry флаги нам нахрен не вперлись, их проверка требует команды добавлять и код тормозит.

> код, при этом не менее эффективный/быстрый чем на asm.

Ну и вот у RISCV тоже всякие SIMD расширения появляются.

> ADC есть новая ADX, а в компиляторах всяческие __builtin_add_overflow(), __builtin_addcll()
> и _addcarry_u64().

Нюансик в том что это __builtin* напрочь не портабельно, еще хуже интринсиков.

> В этом весь RISC-V = много чего недодумано, недопеределано, а тут мы
> рыбу заворачивали, но хайпово...

Зато в x86 столько всего напродумано что до сих пор сотни легаси таскают, вплоть до 16 битного режима и чудесатых надписей в UEFI-программах о том что они в DOS работать не могут. Правда UEFI и сам то этот DOS запустить иной раз уже и не может для начала, но легаси штука злая.

Ответить | Правка | Наверх | Cообщить модератору

341. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от аффтар (?), 08-Мрт-23, 23:43 
> Для high-end cpu мы никогда не видим их систему команд и нам
> так то похрен. И для компилера это лишь некий интерфейс а
> реально это бэкэнд. И никакие carry флаги нам нахрен не вперлись,
> их проверка требует команды добавлять и код тормозит.

Не стоит повторять/пересказывать чужие пояснения, не понимая их сути и/или контекста.

Без carry и overflow флагов вы не сможете эффективно реализовать ни арифметику с широкими числами, ни контроль переполнения.
Конечно можно с дополнительными командами, проверками и ветвлениями - просто медленнее.
Либо можно сказать что это редкие кейсы и нам на них плевать, и для low-end и микроконтроллеров это действительно почти не нужно.

И мешают флаги OoO-выполнению, только если являются общими, т.е. вносят дополнительные "спайки" в зависимости.
Если же флаги персонализировать для каждого регистра (в ISA, либо в микроархитектуре), то никакой код они тормозить не будут (кроме явных зависимостей, например при условных переходах или сложении с переносом).

> Ну и вот у RISCV тоже всякие SIMD расширения появляются.

И что?
Но в бижутерии всегда широкий ассортимент, в том числе бус.

>> ADC есть новая ADX, а в компиляторах всяческие __builtin_add_overflow(), __builtin_addcll()
>> и _addcarry_u64().
> Нюансик в том что это __builtin* напрочь не портабельно, еще хуже интринсиков.

Отсылка к нюансам предполагает знание матчасти, хотя-бы базовой формальной части.
Для понимания, исторически префикс __builtin используется в GCC для встраиваемых псевдо-функций (интринсиков), поддержка которых реализуется внутри компилятора.
А термин intrinsic был введен с подачи штеуда и мелко-мягких, при рекламе компиляторов умеющих в MMX без asm-вставок.

Как правило, интринсики жестко привязаны к конкретной архитектуре.
А builtin-ы является формой реализации интринсиков в GCC и clang, при этом существенная их часть переносима между архитектурами (в особенности те, о которых весь речь).

>> В этом весь RISC-V = много чего недодумано, недопеределано, а тут мы
>> рыбу заворачивали, но хайпово...
> Зато в x86 столько всего напродумано что до сих пор сотни легаси
> таскают, вплоть до 16 битного режима и чудесатых надписей в UEFI-программах
> о том что они в DOS работать не могут. Правда UEFI
> и сам то этот DOS запустить иной раз уже и не
> может для начала, но легаси штука злая.

Так в этом-то и дело, что для RISC-V декларируется что пытались допеределать по-уму.
А получилось недодуманное УГ для low-end, которое всячески пиарят, разукрашивают и впаривают под вывеской "гениальной простоты".

Ответить | Правка | Наверх | Cообщить модератору

346. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 13-Мрт-23, 17:10 
> Не стоит повторять/пересказывать чужие пояснения, не понимая их сути и/или контекста.

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

> Без carry и overflow флагов вы не сможете эффективно реализовать ни арифметику
> с широкими числами, ни контроль переполнения.

Я кроме всего прочего самолично накодил вот это самое. А прям на сишечке. С достаточно непозорной эффетивностью, кстати. Не, копаться в carry флагах конкретного проца я не собираюсь даже если вы тут такие красивые полопаетесь тут все.

> Конечно можно с дополнительными командами, проверками и ветвлениями - просто медленнее.

Вообще-то сколь-нибудь явные проверки этих флагов и различение разных случаев как раз и требуют добавочных команд впихнуть. А прикиньте, код который допустим жестко задефайнил что там урезается по mod 2^N так то сильно оптимальнее выходит, как ни крути. И половине кода вот именно этого и хотелось. Самого критичного как раз, типа кодеков, крипты, и тому подобной интенсивной математики - вот как раз чтобы там не было лишних операций. Но это вон те хотели, а вот эти - простреливали пятки такой механикой не специально. Просто не было халявного способа проверить переполнение типа. Даже в хрусте не смогли, так что это в дебаг билдах только, с соответствующей просадкой перфоманса. Да и в сях это поймать можно но только *san всякими, которые тоже по скорости ни разу не халявны.

> Либо можно сказать что это редкие кейсы и нам на них плевать,
> и для low-end и микроконтроллеров это действительно почти не нужно.

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

> И мешают флаги OoO-выполнению, только если являются общими, т.е. вносят дополнительные
> "спайки" в зависимости.

Опять же хорошая штука должна быть масштабируемой. ARM это очень наглядно показал. У этих есть все - от 8 ногого таракана до серверных процов. При том весьма непозорно. RISCV пытается быть чем-то таким, но более opensource friendly. Это - масштабирауемая экосистема.

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

Это какая-то конкретика частной реализации. Проьлема в том что желание сделать это "экосистемой", да еще "вертикально масштабируемой" в эту формулу не входит. А, у x86 кстати с этим ломовые проблемы, например. Атомы получились ни то ни се. Интел из кожи вон лез чтобы таблет пц сделать. Но нет, вместо этого появился андроид и армовские планшетки. А кто виноват что они в разы дольше от той же батарейки работают и система проще в имплементации в разы?

> И что?
> Но в бижутерии всегда широкий ассортимент, в том числе бус.

Ну вот и то. Один размер всем не подходит. А экосистема это круто. Представляешь, когда можно привычным тулчейном вранглить все, от своих наручных часов до сервака это круто и удобно. Это серьезное преимущество платформы. RISCV тоже так хочет. Это логичный и правильный виш, дающий им шанс. Они может не будут лучшими - но они будут универсальными, повсеместными, а толпа народа будет знать этот тулчейн. Поэтому оно даже и не помрет. Сказал бы "подвинет интел" но оный из половины ниш армов нельзя подвинуть за его отсутствием, x86 везде кроме переростков из себя вообще ничего не представляет. А рынок мелочи так то измеряется в миллиардах юнитов и забивать на него - интель поди уже сто раз пожалел что продал продвинутую лицензию на армы марвелу.

> Отсылка к нюансам предполагает знание матчасти, хотя-бы базовой формальной части.

А это все есть, внезапно. Builtin это загоны конкретного компилера. На это вообще нет ни малейших намеков на стандарты. С интринсиками хоть какое-то подобие потуг этого, не то чтобы сильно успешное но не builtin'ам про это вещать.

> (интринсиков), поддержка которых реализуется внутри компилятора.

Исторически, SIMD вообще не существовал, если уж ворошить прошлое. Точнее, существовал  но совсем не так как вы себе это представляете, венцом творения был SWAR, который так то не требует никаких интринсиков вообще.

> А термин intrinsic был введен с подачи штеуда и мелко-мягких, при рекламе
> компиляторов умеющих в MMX без asm-вставок.

Представляете, даже эта парочка изредка может выдавать довольно здравые идеи?!

> Как правило, интринсики жестко привязаны к конкретной архитектуре.

Сама по себе задумка такая что в принципе если есть из чего это сделать - берут и делают. Если совсем нету - ну тогда или плохонькая эмуляция или фэйл если совсем уж фигово, чтоб переписывали иначе.

> А builtin-ы является формой реализации интринсиков в GCC и clang, при этом
> существенная их часть переносима между архитектурами (в особенности те, о которых
> весь речь).

И тем не менее это нестандартно от слова вообще и лок на 2 конкретных компилера, что не круто.

> Так в этом-то и дело, что для RISC-V декларируется что пытались допеределать по-уму.

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

> А получилось недодуманное УГ для low-end, которое всячески пиарят, разукрашивают и впаривают
> под вывеской "гениальной простоты".

Да вот понимаете, если что-то в low end хорошо работает, с должным обвесом и апгрейдами оно потом и в десктопно-серверном достаточно непозорно смотрится по мипсам на ватт и прочем. А обрубить допустим x86 до мелочи - интель с таблет пц сколько пытался? Лет 20? А воз и ныне там. За это время ARM и Goole нишу заняли и поделили без вон тех. От чего у wintel'а плохо скрываемый батхерт. Что атомы, что винмобил, два фэйла, но пыхтели знатно.

Ответить | Правка | Наверх | Cообщить модератору

337. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 08-Мрт-23, 10:26 
> Главный прогиб под C - это RISC-V,

Да вот кстати Cortex M для сишника так то поудобней RISCV. Я так понимаю что RISCV совсем без асмового стартапа тяжко поднять, а Cortex M вполне реально - я еще и проверял. Да в самом самом начале сишка нестандартный, пока он (сам себе!) BSS/RWDATA не инициализирует. Но сам чип операбелен и ничего враждебного сишке не делает. И сразу юзабелен сишным кодом.

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

> где нет флагов.

Да и болт с ними, обычно ими никто все равно не пользовался в арифметике особо, потому что их проверка время и код требует.

> Соответственно весь тот геморой, который нужен для сложения числе размера в два
> раза больше слова реализуется один в один как C код, сложение, сравнение и т.д.,
> без всяких add adc

А вы мне в XXI веке на асме чтоли прогать предлагаете? Ага, вот ща. Сейчас даже фирмварь китайского фонарика на аттини - на сишке, и ниипет. Это при том что там флеша 4-8 кило на все.

Ответить | Правка | К родителю #229 | Наверх | Cообщить модератору

221. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (221), 02-Мрт-23, 11:11 
> Настоящий сишник меняет аппаратуру под себя. Диктует свои правила.

правила диктует прогресс а он сдерживается рынком. Появился запрос на использование общих сетей передачи данных и всплыл вопрос о безопасном их использовании - на начальном этапе начали использовать псевдобезопасные языки но в конечном итоге всё равно перейдут на безопасные процессоры потому что без доверенной аппаратной платформы на которой  исполняется код никакой безопасности нет в принципе.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

228. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +4 +/
Сообщение от Вечно недовольный аноним (?), 02-Мрт-23, 12:34 
Как рынок сдерживает прогресс?
Ответить | Правка | Наверх | Cообщить модератору

234. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (221), 02-Мрт-23, 13:32 
> Как рынок сдерживает прогресс?

инновационные продукты из-за высокой цены могут себе позволить единицы -> производство не окупается а все R&D сидят на дотациях -> тем кто дотирует требуется время чтобы окупить  вложения -> сдерживают конкуренцию огораживанием разработок патентами.

Если ты не заметил - рынок десятилетиями был огорожен дырявыми процессорами интеля.

Ответить | Правка | Наверх | Cообщить модератору

263. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (265), 02-Мрт-23, 20:05 
Unix захватил мир процессоров вместе с С. Мелкомягкие писали свой первый код на С. Всё это предопределило архитектуру процессора. Дальше легаси вступило в действие.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

314. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от adolfus (ok), 04-Мрт-23, 21:49 
С был спроектирован так, чтобы эффективно отображаться на две существующие на тот момент времени архитектуры -- гарвардскую и фоннеймановскую, снабженные стеком. Поскольку других архитектур не появилось и не появится в обозримом времени, этот язык переживет всех.
Ответить | Правка | Наверх | Cообщить модератору

338. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 08-Мрт-23, 10:31 
> С был спроектирован так, чтобы эффективно отображаться на две существующие на тот
> момент времени архитектуры -- гарвардскую и фоннеймановскую, снабженные стеком. Поскольку
> других архитектур не появилось и не появится в обозримом времени, этот
> язык переживет всех.

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

Если кто хочет посмотреть как си на гарварде - вон авр есть. Весь мозг сломаешь с тамошними указателями. То-есть они как бы и так указатели и сяк, но вот тут такие а вот тут не такие, и не сойти с ума при этом - не очень просто.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру