The OpenNET Project / Index page

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



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

"Microsoft открыл CHERIoT, аппаратное решение для повышения безопасности кода на языке Си"  +/
Сообщение от opennews (??), 01-Мрт-23, 10:12 
Компания Microsoft открыла наработки, связанные с проектом CHERIoT (Capability Hardware Extension to RISC-V for Internet of Things), нацеленным на блокирование проблем с безопасностью в существующем коде на языках C и С++. CHERIoT предлагает решение, позволяющее защитить существующие кодовые базы на С/C++ без необходимости их переработки. Защита реализуется через применение модифицированного компилятора, использующего специальный расширенный набор процессорных инструкций (ISA), предоставляемых процессором и на аппаратном уровне отслеживающих доступ к памяти, проверяющих корректность работы с указателями и обеспечивающих изоляцию блоков кода...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=58726

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

Оглавление

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


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

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

51. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +2 +/
Сообщение от Товарисч (?), 01-Мрт-23, 12:34 
Звучит инфантильно.
Ответить | Правка | Наверх | Cообщить модератору

81. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от YM2608 (?), 01-Мрт-23, 14:18 
а почему тебе Rust не нравится ɁɁɁ
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

159. Скрыто модератором  +1 +/
Сообщение от Аноним (-), 01-Мрт-23, 20:06 
Ответить | Правка | Наверх | Cообщить модератору

173. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (173), 01-Мрт-23, 21:14 
а почему раст должен кому-то нравиться?
Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

235. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (235), 02-Мрт-23, 13:37 
А почему лично мне он обязательно должен нравиться?
Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

247. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от YM2608 (?), 02-Мрт-23, 15:46 
так я не спрошивал, почему он должен тебе нравиться, а спросил почему он не нравится
Ответить | Правка | Наверх | Cообщить модератору

158. Скрыто модератором  –1 +/
Сообщение от Аноним (-), 01-Мрт-23, 20:03 
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

8. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +9 +/
Сообщение от pda (ok), 01-Мрт-23, 10:22 
А читаем мы по диагонали...

"Проблема может быть решена использованием языков программирования, гарантирующих безопасную работу с памятью, или обвязок с дополнительными проверками"

"уже существующие проекты на С/C++ переработать достаточно проблематично, особенно если они предназначены для выполнения в окружениях с ограниченными ресурсами, таких как встраиваемые системы и устройства интернет-вещей"

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

282. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Odalist (?), 02-Мрт-23, 22:30 
У меня потерялся Фрактал... Никто его не видел?
Ответить | Правка | Наверх | Cообщить модератору

317. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Глашатый (?), 05-Мрт-23, 11:00 
И много таких решений Вам известно? Java, да?
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

9. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Проффесорemail (?), 01-Мрт-23, 10:24 
>Ну зачем аппаратный огород городить когда уже Rust есть?

Где скачать Rust под Cortex-M0 ?

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

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

25. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +7 +/
Сообщение от НяшМяш (ok), 01-Мрт-23, 11:01 
Опять в гугле забанили, уже 5 лет как есть.

https://github.com/rust-embedded/cortex-m-quickstart
https://docs.rust-embedded.org/book/intro/install.html

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

174. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (173), 01-Мрт-23, 21:17 
А ты точно внимательно прочитал то, на что попытался ответить?

> Где скачать Rust под Cortex-M0 ?

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

220. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от Аноним (220), 02-Мрт-23, 10:39 
тут есть всего лишь две проблемы:

1. rust для ARM ничего не сможет собрать без GCC и binutils
2. все его разпиаренные либы слинкованы, угадай с чем ? glibc

... 1 ...
# cargo build
    Updating crates.io index
  Downloaded void v1.0.2
  Downloaded vcell v0.1.3
  Downloaded nb v1.0.0
  Downloaded nb v0.1.3
  Downloaded embedded-hal v0.2.7
  Downloaded volatile-register v0.2.1
  Downloaded bitfield v0.13.2
  Downloaded critical-section v1.1.1
  Downloaded 8 crates (104.4 KB) in 1.00s
   Compiling nb v1.0.0
   Compiling void v1.0.2
   Compiling cortex-m v0.7.4 (/root/cortex-m)
   Compiling vcell v0.1.3
   Compiling volatile-register v0.2.1
   Compiling critical-section v1.1.1
   Compiling nb v0.1.3
   Compiling bitfield v0.13.2
   Compiling embedded-hal v0.2.7
error: linker `cc` not found
  |
  = note: No such file or directory (os error 2)
...


... 2 ...
readelf -a /root/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/libstd-349359eac2fa563a.so|grep NEEDED
0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

...

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

28. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от Советский инженер (?), 01-Мрт-23, 11:04 
если тебе такой раст, чтобы код кросскомпилять - то на https://www.rust-lang.org/
а если такой, что б прям запускать коспилятор на кортексе - то там же где и С-компилятор, т.е. нигде.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

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

131. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (131), 01-Мрт-23, 17:57 
Где скачать rust под avr
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

157. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от topin89 (ok), 01-Мрт-23, 19:58 
детали тут:
https://book.avr-rust.com/001-introduction.html

Как я понял, идёт в комплекте к обычному расту

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

217. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от Аноним (220), 02-Мрт-23, 09:57 
я тебя огорчу:

...
Based on components for the Arduino Uno
Needs AVR-GCC on the system for linking
Needs AVR-Libc on the system for support libraries
...

растаманы недалеко ушли от go-пошников - тупо шмаляют обертки вокруг C и бьют себя пяткой в грудь.

много вам г#вна придется сьесть, чтобы написать компилятор для другой архитектуры

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

243. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от topin89 (ok), 02-Мрт-23, 14:42 
А тебе шашечки или ехать?
Писать на расте можно? Можно. А линковка на любых платформах, кроме может redox, берётся системная, а не самописная
Ответить | Правка | Наверх | Cообщить модератору

265. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (265), 02-Мрт-23, 20:32 
> тупо шмаляют обертки вокруг C и бьют себя пяткой в грудь.

И что тут преступного? Придумать концепцию, подходящий синтаксис, внедрить хуки. Предварительно обработать свой код и передать сишному компилятору. Коллекция GCC так и строится.
В инструкции по установки rustc прямо написано что нужен компилятор плюсов вроде (или библиотека плюсов).

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

16. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (16), 01-Мрт-23, 10:39 
Проблемы и приватности и тивоизации.

Как на устройстве запускать и свои сервисы работы с деньгами и одновременно неизвестный любой другой код и чтобы не поломали.

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

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

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

183. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от YetAnotherOnanym (ok), 01-Мрт-23, 21:46 
Невелика тяжесть :Ь

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

236. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (235), 02-Мрт-23, 13:40 
Был бы предмет таскания, а карманы уж найдутся.
Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

180. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от A (?), 01-Мрт-23, 21:42 
Вам-то - да. Но они-то мыслят: через банкомат ты много не продашь книг, кино, музла, фуфлоты и др. цифро-услуг.
Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

184. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от YetAnotherOnanym (ok), 01-Мрт-23, 21:49 
Да просто экономят. Банкомат требует техобслуживания, инкассаторская служба тоже недешёвое удовольствие, с владельцем помещения надо договариваться, питание, связь, вот это всё. Ну, и впаривать фуфло, да.
Ответить | Правка | Наверх | Cообщить модератору

345. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от 2studentemail (?), 13-Мрт-23, 16:32 
когда были онлайновые магазины с CD программ, кино и музыки было ответственней, потому-что приходилось за этим ходить пешком, и сто раз думал что купить и на что потратить деньги.
Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

260. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (265), 02-Мрт-23, 19:45 
Тут антимаркетинговые факторы начинают работать. Дождь, вечер, лень, очередь, не всегда за углом и тд. Да и банкам накладно ставить банкоматы на каждом шагу.
Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

162. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от kusb (?), 01-Мрт-23, 20:12 
Полный сброс контекста, чтобы даже ОС не была задействована в это время. Всё состояние ОС сохраняется, запускается программа для работы с деньгами из шифрованного места, расшифровывает себя и дальше...
Главное не давать основной ОС трогать в том числе незашифрованную часть программы для работы с деньгами.
Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

181. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от A (?), 01-Мрт-23, 21:43 
Вот и изобретают - как именно не давать.
Ответить | Правка | Наверх | Cообщить модератору

238. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (235), 02-Мрт-23, 13:52 
>Главное не давать основной ОС трогать в том числе незашифрованную часть программы
>расшифровывает себя и дальше...

Дальше известно как. Ищет бинарники и модифицирует их добавлением своей копии.

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

266. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (265), 02-Мрт-23, 20:39 
Контейнеры, виртуальные машины, контрольные группы, разделение пространства имен, песочницы, работа в другом профиле, использование аппаратных токенов и многое другое. Если не изменяет память, то вкладки современных браузеров разделеня как песочницы. Главное не пускать грязь на системный уровень и многофакторная авторизация.
Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

285. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Neon (??), 02-Мрт-23, 22:42 
И для обработки 1 Мб уже не хватает десятков Гб))).
Ответить | Правка | Наверх | Cообщить модератору

24. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от _kp (ok), 01-Мрт-23, 10:52 
Там же сказали, для использования существующей кодовой базы без переписывания, ибо объёмы весьма внушительны.
Rust тут ни причём, ибо даже никак не относится к решению задачи - использования, того что уже есть.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

255. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от ЗанудаВФорточке (?), 02-Мрт-23, 19:33 
Адепты раста не упускают возможности попиариться. )) Своего кода крохи. Натолкнулся что раст в работе используют менее 10%. остальные для развлечения. Go, например, рядом на сайте используют на работе 70 процентов.    
Ответить | Правка | Наверх | Cообщить модератору

31. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (31), 01-Мрт-23, 11:32 
Чтобы раст прорекламировать. Мелкософт главный (наравне с гуглом) зачинщиков раси оманми
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

259. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (265), 02-Мрт-23, 19:41 
Штат понабрали "с улицы" и торопят, поэтому надо предохранятся.
Ответить | Правка | Наверх | Cообщить модератору

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

177. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (177), 01-Мрт-23, 21:29 
Хруст их очень устраивает. Их не устраивает переписывать миллиарды строк кода _старого барахла_. Плюс это они делают не только для своего старого барахла, но и для твоего, наСИльник, ибо лицензия BSD. Ты то  раст ни в жисть не выберешь, а ошибки как делал так и продолжишь штамповать. Даже если тебе пригрозят отрезать выступающие части тела, ибо клиника.
Ответить | Правка | Наверх | Cообщить модератору

195. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 02-Мрт-23, 02:12 
Ты в своем праве отправиться курить бамбук и не пользоваться сишным софтом. Можешь начать с операционки и кернела, редокс ждет тебя.
Ответить | Правка | Наверх | Cообщить модератору

224. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (224), 02-Мрт-23, 11:48 
Конечно, по своей воле я Rust не выберу, ибо есть более красивые альтернативы.
Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

64. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от warlock66613email (ok), 01-Мрт-23, 13:24 
Так этот аппаратный огород отлично работает в паре с Rust (фича strict_provenance и связанные).
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

93. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от anonymous (??), 01-Мрт-23, 15:38 
> нацеленным на блокирование проблем с безопасностью в существующем коде на языках C и С++.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

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

269. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от _kp (ok), 02-Мрт-23, 21:16 
> Мне, с моим отсутствующим мозгом, кажется что проверка каждого обращения к памяти
> настолько сильно уронит производительность, что пользоваться ей будет почти невозможно

Есть же тестовые и отладочные сборки.
Эту среду можно рассматривать и как средство обнаружения проблем, что бы подправить исходник, и он точно стабильно работал в нативном виде.

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

123. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от ptr (??), 01-Мрт-23, 16:59 
Как Вы представляете себе Rust, например, для CH32V003?
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

161. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от topin89 (ok), 01-Мрт-23, 20:10 
Там вроде RISC-V. Как я понял, поддержка на ранней стадии, но в планах точно есть.
https://github.com/rust-embedded/riscv-rt
Ответить | Правка | Наверх | Cообщить модератору

321. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от ptr (??), 06-Мрт-23, 14:18 
Поддержку то можно наваять. Но когда у тебя только 2К оперативки, даже если поддержка будет кушать 500 байт, желания ее использовать - никакого
Ответить | Правка | Наверх | Cообщить модератору

194. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 02-Мрт-23, 02:11 
> Как Вы представляете себе Rust, например, для CH32V003?

А это что за зверь? Клон GD32 с RISCV ядром и прочим обвесом "как у STM32"?

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

226. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (224), 02-Мрт-23, 12:09 
http://www.wch-ic.com/products/categories/47.html?pid=5
Ответить | Правка | Наверх | Cообщить модератору

336. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (335), 08-Мрт-23, 10:19 
> http://www.wch-ic.com/products/categories/47.html?pid=5

Похоже на RISCV с обвесом "как у STM32". Но, кажется, все ж не классическим F103 в 103-й версии, это фэйл. И у катайцев есть какие-то устаканившиеся клоны которые 1 в 1 совпадают? F103 на ARM например штук пять фирм минимум гонит и они более-менее совместимы и по ядру и по регистрам, вплоть до вливки 1 и того же бинаря во все и даже работать будет, правда не факт что идеально точно, но лучше чем нифига.

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

219. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним Ваноним (?), 02-Мрт-23, 10:26 
ну я так понимпю, тут и на си не сахар: или мимикрия апи под stm32(с надеждой, что китайцы все нормально сделали) или самому по даташиту и riscv асмом сидеть разбираться. Да господи, офф доки по avr  и stm бывают нерабочими. Так что не понимаю, что уже там на раст бухтеть, все мы сидим и пользуемся откровенным говном.
Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

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

Он так то тоже далеко не все в рантайме проверять может - некоторые проверки не халявные по скорости, увы. Скажем integer overflow.

Одно дело если железка в рантайм эксепшн кидает что переполнение математики, это не требует кода на проверки. Совсем другое если надо нормальную математику проверками carry-флагов разбавить, скорость всякого крипто и мультимедии резко упадет в разы если так сделать. А оно такое надо? Это даже из си можно сделать подцепив ubsan и особенно asan но это будет мало чем лучше Java какой-нибудь.

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

257. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (265), 02-Мрт-23, 19:39 
Топик для Аудита (тестирования) кода на Си и плюсах. Причем тут раст? Если удастся внедрить контроль владения данными в компилятор Си то раст станет не нужен. Причем речь идет о владение динамически выделенными данными в куче.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +16 +/
Сообщение от Кровосток (ok), 01-Мрт-23, 10:13 
Решение прямо как из песенки: "Ключик золотой... В ж... себе вставь! Покрути немного, для работы тебе надо!"
Ответить | Правка | Наверх | Cообщить модератору

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ообщить модератору

4. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от Аноним (5), 01-Мрт-23, 10:18 
Неужели раст не помог и пришлось всё делать правильно? Кто бы мог подумать.  
Ответить | Правка | Наверх | Cообщить модератору

18. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от пох. (?), 01-Мрт-23, 10:44 
так он бы смог, конечно, смог бы - но пока на эту архитектуру кроме readme.md ничего толком портировать не удалось.
(отдельно станет интересненько когда выяснится что милиард взаимозависящих крейтов неведомых авторов на ней компилируютца...только не совсем работают)

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

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

49. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (46), 01-Мрт-23, 12:31 
>кроме readme.md ничего толком портировать не удалось

Как так? А CoC.md?

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

83. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 01-Мрт-23, 14:52 
> пришлось всё делать правильно

В рантайме проверять лайфтаймы и выходы за границы, это уже "правильно"?

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

89. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от Аноним (-), 01-Мрт-23, 15:04 
Хотя, если так подумать, в рантайме лайфтаймы и выходы за границы отслеживать проще. В том же расте, если перенести лайфтаймы в рантайм при помощи RefCall и Arc, то компилятор перестаёт ругаться. Паники иногда в рантайме случаются, правда. Но зато думать не надо, прям как в C.
Ответить | Правка | Наверх | Cообщить модератору

97. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от непох (?), 01-Мрт-23, 15:58 
> зато думать не надо

Если вы не думаете, то вы трупп.

Поэтому стремление к "поменьше думать" несколько удручает.

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

170. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 01-Мрт-23, 21:01 
> Хотя, если так подумать, в рантайме лайфтаймы и выходы за границы отслеживать проще.

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

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

241. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 02-Мрт-23, 14:18 
> в рантайме без поддержки железом не халявно получается

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

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

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

264. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (265), 02-Мрт-23, 20:11 
переполнение int в рантайме - это логическая ошибка. Поэтому компилятор и не поможет.
Ответить | Правка | К родителю #170 | Наверх | Cообщить модератору

283. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (-), 02-Мрт-23, 22:40 
Для процессора переполнение int'а это не ошибка вовсе. Для задумки программиста это может быть ошибкой. А компилятор вполне может помочь, если задумка программиста будет закодирована в коде. Когда ты используешь + для любого сложения, то происходит потеря информации о задумке, при передачи из головы компилятору, потому что разные идеи кодируются одинаково. Если же их кодировать по-разному, то компилятор может помочь.

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

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

290. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от Аноним (265), 03-Мрт-23, 00:41 
#include <stdio.h>
#include <inttypes.h>

int main(){
uint8_t a=255,b=255;
uint8_t c;
c=a+b;
printf("%d\n",c);

И здесь я Явно указал значения операндов. Компилятор GCC даже не предупредил.

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

325. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Совершенно другой аноним (?), 07-Мрт-23, 17:03 
> #include <stdio.h>
> #include <inttypes.h>
> int main(){
> uint8_t a=255,b=255;
> uint8_t c;
> c=a+b;
> printf("%d\n",c);
> И здесь я Явно указал значения операндов. Компилятор GCC даже не предупредил.

#include <stdio.h>

int main(int argc, char* argv[])
{
  unsigned char a = 255, b = 255, c;

  if (__builtin_add_overflow(a, b, &c) == 0)
    printf("%d\n", c);
  else
    printf("owerflow\n");

  a = 254;
  b = 1;

  if (__builtin_add_overflow(a, b, &c) == 0)
    printf("%d\n", c);
  else
    printf("owerflow\n");

  a = 255;
  b = 1;

  if (__builtin_add_overflow(a, b, &c) == 0)
    printf("%d\n", c);
  else
    printf("owerflow\n");

  return 0;
}

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

326. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (-), 07-Мрт-23, 22:08 
Эй лолки, man 3 printf для начала. С вашим %d вы такие забавные. А builtin это прекрасно но не по стандарту и специфично для компилера, увы. Для unsigned вполне конкретно определено что они врапаются по своей ширине, это well defined behavior как раз таки, им можно пользоваться и дофига алгоритмики типа крипто, операций с битами и проч этим пользуется - экономя команды проца в критичных к скорости местах лопатящих порой сотни мегов в секунду (шифрование или хеширование чего-то по сетке например).

В мане для вас, анонимов, про %d так то написано что это спецификатор для ЗНАКОВЫХ десятичных чисел! Вы же взяли 2 беззнаковых, для начала. Если вы ЭТОМУ uint скармливаете от большого ума - там так то и отрицательное число может нарисоваться в принципе. Но вы ж сами попросили этим спецификатором рассмотреть вон то, на входе, как знаковое. Разумеется конверсия uint -> signed в недрах printf это нечто implementation defined.

Чисто теоретически компилер мог бы и предупредить что вы какую-то хрень printf дали. Для некоторых наиболее очевидных даже и предупреждает, но до вот этого видимо не добрались еще. Или вы не включили всякие -Wall -Wextra -Wconversion чтобы узнать о себе и своих кодинг скилах кое-что новое.

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

334. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Совершенно другой аноним (?), 08-Мрт-23, 10:03 
> Эй лолки, man 3 printf для начала. С вашим %d вы такие
> забавные.

В данном случае рояля не играет, т.к. unsigned char расширится до unsigned int со значением 255, и всё будет выведено корректно, как Вы знаете, на стек char положить никак нельзя, кладётся (ну или ложится) только словами.

> А builtin это прекрасно но не по стандарту и специфично
> для компилера, увы.

Я в курсе, по стандарту именно как Вы написали - переполнение беззнаковых вполне себе определено.

>[оверквотинг удален]
> начала. Если вы ЭТОМУ uint скармливаете от большого ума - там
> так то и отрицательное число может нарисоваться в принципе. Но вы
> ж сами попросили этим спецификатором рассмотреть вон то, на входе, как
> знаковое. Разумеется конверсия uint -> signed в недрах printf это нечто
> implementation defined.
> Чисто теоретически компилер мог бы и предупредить что вы какую-то хрень printf
> дали. Для некоторых наиболее очевидных даже и предупреждает, но до вот
> этого видимо не добрались еще. Или вы не включили всякие -Wall
> -Wextra -Wconversion чтобы узнать о себе и своих кодинг скилах кое-что
> новое.

$ gcc -Wall -Wextra -Wconversion q.c
q.c: In function 'main':
q.c:3:14: warning: unused parameter 'argc' [-Wunused-parameter]
    3 | int main(int argc, char* argv[])
      |          ~~~~^~~~
q.c:3:26: warning: unused parameter 'argv' [-Wunused-parameter]
    3 | int main(int argc, char* argv[])
      |                    ~~~~~~^~~~~~

$ gcc --version
gcc.exe (MinGW.org GCC Build-2) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -Wall -Wextra -Wconversion q.c
q.c: In function ‘main’:
q.c:3:14: warning: unused parameter ‘argc’ [-Wunused-parameter]
    3 | int main(int argc, char* argv[])
      |          ~~~~^~~~
q.c:3:26: warning: unused parameter ‘argv’ [-Wunused-parameter]
    3 | int main(int argc, char* argv[])
      |                    ~~~~~~^~~~~~

$ gcc --version
gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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

339. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 08-Мрт-23, 10:44 
> В данном случае рояля не играет, т.к. unsigned char расширится до unsigned
> int со значением 255, и всё будет выведено корректно,

Зато если это с u32 попробовать... можно нехилый сюрприз поймать :))).

И между прочим, размер char, int и проч - это в сишке тоже очень интересный вопрос! Формально по спекам такие комбо могут быть валидны что охренеть. Скажем оба char и int как 16 битов - вполне валидная идея. А там точно расширение будет? И ничего не предъявите, имели право. А если ваш код на вон то еще и  уповал - ну, ой, а он не обязан работать был, вы какие-то конкретные допущения 1 реализации приняли за истину в последней инстанции.

> как Вы знаете, на стек char положить никак нельзя,

Я знаю что ... в стандарте си ВООБЩЕ СОВСЕМ НЕТ НИЧЕГО ПРО СТЭК. Там просто нет этого слова. Вообще, как категории. Стандарт си не специфицирует как это вообще будет сделано. Какое-то конкретное аби еще может, но это вообше не про си уже.

> кладётся (ну или ложится) только словами.

Словами, словами, какими словами...? Ну вот AVR 8-битный, у него слово в стеке - это хто такое? А чо - там printf тоже можно.

> Я в курсе, по стандарту именно как Вы написали - переполнение беззнаковых
> вполне себе определено.

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

> q.c:3:14: warning: unused parameter 'argc' [-Wunused-parameter]

Э... это был hello world? Терь попробуйте это на реальном коде пожирней и зазырьте как вам оно. Учитывая что вы мне уже сосватали UB и какие-то стеки, возможно что вы кой-что не знаете и о своем коде так то :).

И да, кстати -Wconversion много чего ловит но вот именно приколы printf таки далеко не все. Впрочем это уже и не компилерская штука а библиотечная по большому то счету.

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

186. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –3 +/
Сообщение от Аноним (177), 01-Мрт-23, 22:05 
> Неужели раст не помог

"Компания Microsoft открыла наработки, связанные с проектом CHERIoT ..., нацеленным на блокирование проблем с безопасностью в существующем коде на языках C и С++. CHERIoT предлагает решение, позволяющее защитить существующие кодовые базы на С/C++ без необходимости их переработки"

> в существующем коде на языках C и С++
> защитить существующие кодовые базы на С/C++ без необходимости их переработки

т.е. из твоего мудрого проницательного упрека следует, что раст (компилятор или что по твоему?) должен был переписать старого багованного сишного кода на миллионы человеко-лет? То, что десятилетиями писалось? А не, ну глупость я написал - человеки сами же должны сейчас напрячься и просто переписать тысячи и тысячи старых проектов на раст. Им ведь всё равно нечего делать. Ты заплатишь им или они сами, как во времена СССР, на субботники выходить будут? По ночам кодить? Опять же, а что делать с такими наСИльниками, как ты, которых под угрозой расстрела не заставишь что-то иное чем Си попробовать? Ну не лезет им в голову ничего новое, а ошибки шлёпают по-старому на старом языке и хоть режь ты их. Вот костыли вам и смастерили, ковыляй бодро, с подскоком.

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

214. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от Аноним (214), 02-Мрт-23, 09:25 
До тебя медленно но очень трудно доходит что раст ненужен. А сама идея на него что-то переписывать не имеет смысла.  Продолжай свой путь к просветлению.
Ответить | Правка | Наверх | Cообщить модератору

292. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (177), 03-Мрт-23, 03:54 
> До тебя медленно но очень трудно доходит что раст ненужен.

только "икспертам опеннета"

> А сама идея на него что-то переписывать не имеет смысла.

хорошо что разработчики tor тебя не слышат. Но до тебя не то что медленно, а вообще не доходит, что я и не говорю про необходимость переписывать всё на расте. Наоборот, я и сказал, что не имеет смысла переписывать всё старое барахло.

>  Продолжай свой путь к просветлению.

А тебя уже ничто не спасет, можешь остановиться, никакого просветления тебе не светит.

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

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

232. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от Аноним (235), 02-Мрт-23, 13:25 
>s/человеки/растаманы сами же должны сейчас напрячься и просто переписать тысячи и тысячи старых проектов на раст. __Им ведь всё равно нечего делать__.

Точно подмечено!

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

293. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (177), 03-Мрт-23, 03:59 
А, слово подменил, смысл поменял, смешно получилось. Детский сад, штаны на лямках.

Тонко пошутил!

Пысы: Радует, что реагируешь - значит, у тебя подгорает.

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

6. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +2 +/
Сообщение от Аноним (6), 01-Мрт-23, 10:20 
у Эльбрусов вроде есть защищённый режим где доступ к памяти и исполнение проверяются аппаратно
Ответить | Правка | Наверх | Cообщить модератору

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

54. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +3 +/
Сообщение от непох (?), 01-Мрт-23, 12:38 
Защищенный режим есть во всех Эльбрусах и работает, без "наверное".

Если бы "чубайсы" не мешали Эльбрусам, а дали развиваться, то за прошедшие 20 лет могли бы иметь превосходную архитектуру, а не студенческо-дипломный PoC как сейчас.

Эх, жалко полимеры...

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

145. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от пох. (?), 01-Мрт-23, 19:12 
Прости, а вот при советской власти на которую тут все неистово др-ат им кто мешал - Брежнев, Андропов или Черненко?
А то они так там доразвивались, что на 1045 стояли очереди на год вперед, бэсм уже никто не любил но кому давали - пользовались, см1420 работали неделями, а эта херня только ремонтировалась (наверное, водопроводный интерфейс протек)
Ответить | Правка | Наверх | Cообщить модератору

222. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от U202204161753 (?), 02-Мрт-23, 11:37 
"Эта х-ня" - про Эльбрус-1 или про Эльбрус-2?

Если про первый, то там была неудачная элементная база. Её и заменили в Elbrus-2, получив таки необходимую скорость работы.

( пересказываю, то что читал)

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

171. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –3 +/
Сообщение от Аноним (-), 01-Мрт-23, 21:04 
> Если бы "чубайсы" не мешали Эльбрусам,

О, оказывается в головотяпском управлении зажраной фирмочки чубайс виноват. А он там вообще в этой фирме был?!

> а дали развиваться,

А как он им мешал то? По-моему им свое руководство совкового разлива, не относящееся к чубайсу мешало сильнее.

> то за прошедшие 20 лет могли бы иметь превосходную архитектуру, а не студенческо-
> дипломный PoC как сейчас.

А им и так хорошо было на госзаказиках походу. Даже позволяли себе контракты с госами продалбывать. Представьте себе китайский или американский стартап который рискнет продолбать заказ от госов, если уж обломилось такое?!

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

193. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Rock (?), 02-Мрт-23, 00:07 
> О, оказывается в головотяпском управлении зажраной фирмочки чубайс виноват. А он там вообще в этой фирме был?!

У человека, просто, русский на очень высоком уровне. Обратите, пожалуйста, внимание, что слово Чубайс у автора написано с маленькой буквы, во множественном числе и взято в кавычки. Это означает, что оно играет роль эвфемизма. Я полагаю, что под ним автор имел в виду бандитов, мошенников и воров, которые, по довольно широко распространенному стереотипу, создают российскую бизнес-среду.
Если мое предположение верно, то, действительно, "пилить" бюджеты при каком-то реальном производстве гораздо сложнее и не так эффективно, как если все закупать за нал. Поэтому "недобросовестных" конкурентов, которые не закупают, а пытаются делать сами, стараются убрать.
Обратите, пожалуйста, внимание, что слово "недобросовестных" у меня тоже взято в кавычки. И это неспроста.

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

198. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 02-Мрт-23, 02:27 
> У человека, просто, русский на очень высоком уровне. Обратите, пожалуйста, внимание, что
> слово Чубайс у автора написано с маленькой буквы, во множественном числе

Он уже давно стал нарицательным прозвищем, не отнять. Но у тех по-моему даже таких не было.

> и воров, которые, по довольно широко распространенному стереотипу, создают российскую
> бизнес-среду.

Чубайс и ко - хучшие из лучших. В вон той фирмочке и таких не было. Во всяком случае этот лис проявил таланты менеджера в последний раз - и слился все же вовремя. А как ни крути, плох тот капитан который не понимает что его межгалактический крейсер взорвется, при том - СЕЙЧАААА!!!...

> Обратите, пожалуйста, внимание, что слово "недобросовестных" у меня тоже взято в кавычки.
> И это неспроста.

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

За то же время в других странах развились десятки микропроцессорных стартапов, тиражи RISCV стали исчисляться миллионами. И на их фоне вон то не выглядит круто и офигенно хоть тресни.

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

254. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от ЗанудаВФорточке (?), 02-Мрт-23, 19:19 
> За то же время в других странах развились десятки микропроцессорных стартапов, тиражи RISCV стали исчисляться миллионами. И на их фоне вон то не выглядит круто и офигенно хоть тресни.

В том и роль чубайсов - обеспечивать рынок сбыта в России для чужих стартапов. Еще ода роль - морочить голову прожектами (ну это когда импортозамещение стало наслуху). Как вот они безответственно свалили?...

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

284. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Neon (??), 02-Мрт-23, 22:41 
Ну так чубайсы не из космоса прилетели. Они все бывшие пламенные комсовольцы и верные ленинцы коммунисты. Других чубайсов не было.
Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

216. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от maximnik0 (?), 02-Мрт-23, 09:54 
>Защищенный режим есть во всех Эльбрусах и работает, без "наверное".

Нет, вы ошиблись.Не вовсех.Есть ещё серия Эльбрусов которые де факто Спарк.(серия микро 90 если не подводит память)Да там есть NX бит,защита по некоторым ошибкам но это не то.

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

245. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от непох2 (?), 02-Мрт-23, 15:04 
Да, конечно.

Всегда эта путаница, что называть Эльбрусами - либо только те что на самом деле Эльбрусы, либо еще и те что Спарки...

Лучше-бы МЦСТ назвали свои спарки барсами или казбеками.

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

58. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от maximnik0 (?), 01-Мрт-23, 12:48 
>он наверное был только в ель-брус-1,

Нет, аппаратная защита есть и у Эльбруса ,который wlib.Называеться тегирование-каждое 4 байтное слово сопровождается 3 разрядным тегом.А ещё раньше аппаратные атрибуты были реализованы в Barroughs.Кое какая защита также есть у Ибм майфрэймах-с использованием микрокода.

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

60. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (46), 01-Мрт-23, 12:55 
Т.е., обычные стандартные планки DDR-3, DDR-4 для Эльбруса не годятся?
Ответить | Правка | Наверх | Cообщить модератору

63. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +6 +/
Сообщение от непох (?), 01-Мрт-23, 13:09 
Да, обычные не годятся, нужные "серверные"  DDR-модули с ECC.
Теги хранятся в вместе с контрольно-корректирующими битами, технически решение очевидное до гениальности.
Ответить | Правка | Наверх | Cообщить модератору

172. Скрыто модератором  +1 +/
Сообщение от Аноним (-), 01-Мрт-23, 21:05 
Ответить | Правка | Наверх | Cообщить модератору

199. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 02-Мрт-23, 02:29 
> Теги хранятся в вместе с контрольно-корректирующими битами, технически решение очевидное
> до гениальности.

А ECC при этом нормально работает?

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

242. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от непох2 (?), 02-Мрт-23, 14:24 
> > Теги хранятся в вместе с контрольно-корректирующими битами, технически решение очевидное
> > до гениальности.
> А ECC при этом нормально работает?

Да.

На уровне DDR-модуля ECC это просто дополнительные биты (обычно +1 к восьми).
Контроль и исправление ошибок реализуется "снаружи", а не в самих DDR модулях.

Как много ошибок исправить и обнаружить зависит от размера блока и количества выделяемых в нем "проверочных" бит, погуглите коды Хемминга.

Поэтому если не мельчить с размером читаемого из DDR блока, то пропорция 8+1 обеспечивает достаточно "лишних" бит для хранения тегов, без ущерба коррекции ошибок.

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

349. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 24-Мрт-23, 17:39 
> 8+1 обеспечивает достаточно "лишних" бит для хранения тегов,
> без ущерба коррекции ошибок.

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

Но идея прикольная, не отнять.

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

85. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от анонимуз (?), 01-Мрт-23, 14:56 
Здесь пишут, что в защищенном режиме вылезают приколы в coreutils типа использования неинициализированной памяти и т.д.:

https://blog.handydev.com/

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

88. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +2 +/
Сообщение от непох (?), 01-Мрт-23, 15:04 
Не приколы, а баги.

И подобное всплывает чуть менее чем повсеместно.

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

90. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от анонимуз (?), 01-Мрт-23, 15:11 
В самОм Linux тоже?
Кстати, может ли вообще Linux работать в защищенном режиме?
Ответить | Правка | Наверх | Cообщить модератору

96. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +3 +/
Сообщение от непох (?), 01-Мрт-23, 15:53 
> В самОм Linux тоже?

Да, но...

> Кстати, может ли вообще Linux работать в защищенном режиме?

Да, если переписать.

Защищенный (aka Безопасный) режим на Эльбрусах очень суров, примерно как Rust без unsafe.
В частности, нельзя "просто так" кастить указатели к целым и наоборот, нельзя сделать union с указателем и т.п.

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

119. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (46), 01-Мрт-23, 16:43 
И как процессор различает, что в регистре сейчас целое или указатель?
Ответить | Правка | Наверх | Cообщить модератору

140. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от непох (?), 01-Мрт-23, 18:39 
Упрощенно: у регистра есть скрытые (недоступные погроммисту) биты, благодаря которым процессор отличает указатели от не-указателей.

На самом деле в e2k безопасный режим натянут сверху, как минимум это так выглядит.
Регистры 64-битные, а указатели в безопасном режиме 128-битные.
Поэтому используются регистровые пары, и понеслось...
http://ftp.altlinux.org/pub/people/mike/elbrus/docs/elbrus_p...

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

223. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от anonymous (??), 02-Мрт-23, 11:48 
> Регистры 64-битные, а указатели в безопасном режиме 128-битные.

Никак каждый указатель содержит смещение до начала массива/объекта?
А в начале массива/объекта есть его полный размер?

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

225. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от anonymous (??), 02-Мрт-23, 11:50 
Так и есть, здесь весь этот секурный сетап описан:
http://ftp.altlinux.org/pub/people/mike/elbrus/docs/elbrus_p...
Ответить | Правка | Наверх | Cообщить модератору

239. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (235), 02-Мрт-23, 14:01 
>Для работы программы в РБВ вводятся дополнительные требования к её исходным текстам. Они более жёсткие, чем общие стандарты языков C/C++.

Т.е., без переписывания или, хотя бы, портирования никуда.

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

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

Что имеется ввиду в данном контексте под защищённым режимом? Если Linux (ядро) может работать в Ring0 (x86), то да, он там и работает.

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

295. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от anonymous (??), 03-Мрт-23, 11:57 
Аппаратный РБВ:
http://ftp.altlinux.org/pub/people/mike/elbrus/docs/elbrus_p...
Ответить | Правка | Наверх | Cообщить модератору

167. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от RM (ok), 01-Мрт-23, 20:32 
Пра брусы и вообще очень занимательное чтиво - читать цикл статей задом наперед.

https://topwar.ru/user/Sperry/

Конкретно про Capability Based проэкты и чем закончился например Intel iAPX 432
https://topwar.ru/191202-rozhdenie-sovetskoj-pro-jel-berrouz...

"Все придумано до нас"

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

175. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Tron is Whistling (?), 01-Мрт-23, 21:20 
"Всё продолбано до нас"
fixed
Ответить | Правка | Наверх | Cообщить модератору

179. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от RM (ok), 01-Мрт-23, 21:38 
Ты еще скажи что Бэббидж тоже продолбал.

В смысле просто лазерной резки для шестеренок^W^W^W^W транзисторного бюджета не было.
Вот проверят на новом уровне идею.
И да - Capabilty Based и VLIW - это все про брусы, но одно отрогонально второму.
Хотя и тому и тому желателен язык высокого уровня сразу и компилятор с него нормальный.

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

206. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от maximnik0 (?), 02-Мрт-23, 04:57 
Я вообще восхищён что такое сумело проскочить в непрофильном сайте.Там прямо указывается что и как распилиловась на не имеем аналогов системе ПРО.Как система съедала талантливых людей.При этом объектная защита не имеет смысла-в случае песеца посылается маленький слабенький заряд-подрываеться за 800 км до объекта.Следом 2 заряд уже подрывается за 550-250 км от объекта.Все система Про выведена из строя-из за ионизации атмосферы аппаратура минимум полчаса будет слепа.
Но об этом не хотят распространяется,потому что бабло продолжают пилить.
Ответить | Правка | К родителю #167 | Наверх | Cообщить модератору

132. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (131), 01-Мрт-23, 18:01 
Защищенный режим в котором работает ровно ничего. А тут решение которое работает постоянно
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

249. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от qwe (??), 02-Мрт-23, 18:08 
Мало того, защищенный режим есть и у интелов, в том том числе флаг исполнения для выделяемых блоков памяти. То есть можно аппаратно запретить исполнять код в стеке и данных. Другое дело, использует ли эту фичу операционка.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

261. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (265), 02-Мрт-23, 19:54 
Вопрос: Как освобождать тэгированную память? Надо вайпить (wipe) биты тэга? Ведь не все команды могут работать с ними? Простым изменением указателя стэка не обойдешься.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

7. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (7), 01-Мрт-23, 10:21 
так, погодите-ка. Если Java - это язык, компилящийся для "гипотетических процов, способных исполнять явовский байткод", то сишка - это то же самое, но для гипотетических процов, в которых можно делать use after free и прочие веселухи. Все правильно понял?
Ответить | Правка | Наверх | Cообщить модератору

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

104. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от OpenEcho (?), 01-Мрт-23, 16:12 
Так прям и нет?!
А вот пацанчики пишущие малварь на яве знают про
Unsafe.class.getDeclaredField("theUnsafe");
Ответить | Правка | Наверх | Cообщить модератору

116. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от Аноним (120), 01-Мрт-23, 16:37 
"getDeclaredField

Returns a Field object that reflects the specified declared field of the class or interface represented by this Class object. The name parameter is a String that specifies the simple name of the desired field.

If this Class object represents an array type, then this method does not find the length field of the array type."

Уточните, пожалуйста, где здесь про доступ к памяти? У меня нет мозгов и я не могу понять.
Даже из названия следует что это доступ к полю класса, по имени

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

121. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +2 +/
Сообщение от OpenEcho (?), 01-Мрт-23, 16:46 
> Уточните, пожалуйста, где здесь про доступ к памяти?

Гуглите про sun.misc.Unsafe или проще, - direct memory access java

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

14. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от Аноним (16), 01-Мрт-23, 10:31 
Типа того. Админить руками или скриптами. В Си - руками всё. В Яве и прочих есть "скрипты" - сборщики мусора.


Скрипты отладил один раз, тесты написал. Работает надёжно.
А руки: опечатки, переключался на другое, авто-тестов нет и выходит плохо.

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

41. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (120), 01-Мрт-23, 11:57 
почему не сделают скрипты сборщики мусора на си?
Ответить | Правка | Наверх | Cообщить модератору

52. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (46), 01-Мрт-23, 12:36 
Как сборщик мусора защитит от разыменования указателя, указывающего на произвольный адрес?
Ответить | Правка | Наверх | Cообщить модератору

113. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (120), 01-Мрт-23, 16:31 
А как он защитит? У меня нет мозгов и я не знаю.
Ответить | Правка | Наверх | Cообщить модератору

200. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 02-Мрт-23, 02:31 
> почему не сделают скрипты сборщики мусора на си?

Для сей есть энное количесто сборщиков мусора, какие проблемы?! Можно начать с BOEHM пресловутого, если оно вам надо.

А если вы хотели из си Java сделать -fsanitize=address,undefined и получите примерно этосамое :)

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

62. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +4 +/
Сообщение от _hide_ (ok), 01-Мрт-23, 13:06 
Процессору на ваши use after free и прочие шалости побоку, более того, состояние гонки можно получить просто из-за небрежной работы с памятью без явных ошибок, к примеру, при циклических ссылках и т.п.

Именно поэтому Ява и работает с памятью "безопасно" -- потому что удаляет сама

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

112. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (120), 01-Мрт-23, 16:29 
Уточните, пожалуйста, какое отношение состояние гонки имеет к циклическим ссылкам? У меня просто слишком мало мозгов и не понимаю.


"Состояние гонки (англ. race condition), также конкуренция[1] — ошибка проектирования многопоточной системы или приложения, при которой работа системы или приложения зависит от того, в каком порядке выполняются части кода."

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

218. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от _hide_ (ok), 02-Мрт-23, 10:02 
> "Состояние гонки (англ. race condition), также конкуренция[1] — ошибка проектирования многопоточной системы
> или приложения, при которой работа системы или приложения зависит от того,
> в каком порядке выполняются части кода."

Последовательность действий:

Удаляем объекты в порядке, отличном от порядка создания
Вначале удаляем в одном объекте, потом по ссылке на элемент этого объекта удаляем объект, на который он ссылался (фактически use after free)

Кажется, что такая ситуация очень надуманная, но практика показывает, что нет. В однопоточном приложении проблема может возникнуть только с очень странным менеджером памяти при стечении обстоятельств или при включенном режиме проверки use after free. А вот в многопоточном добавляем состояние гонки, которое срабатывает существенно чаще (раз в несколько недель)

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

279. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (120), 02-Мрт-23, 22:13 
А причем здесь циклические ссылки?
Ответить | Правка | Наверх | Cообщить модератору

286. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от _hide_ (ok), 02-Мрт-23, 22:52 
> А причем здесь циклические ссылки?

Потому что такие вещи часто встречаются именно в реализации объектов, ссылающихся друг на друга.

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

146. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от пох. (?), 01-Мрт-23, 19:16 
и результат - я открыл для себя что у top есть отображение rss в терабайтах.
Так вот оно "удаляет".

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

149. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноньимъ (ok), 01-Мрт-23, 19:36 
Да, правильно, Си процессоры довольно "специфичны" на самом деле.
Было много альтернатив этому бреду, но почти всё закопали.
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

165. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от www2 (??), 01-Мрт-23, 20:21 
На Java бывают утечки памяти, если что. Можно тоже запретить.

А кроме расширения набора команд процессора есть и другие решения - Cyclone, valgrind, MISRA, статические анализаторы кода.

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

Чтобы написать хорошуую программу на Си, нужно уметь проектировать компоненты и архитектуру. У Java-программистов такая культура более распространена, и дело тут на самом деле далеко не только в сборщике мусора или его отсутствии...

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

262. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (265), 02-Мрт-23, 19:58 
Просто здесь исключения при работе с памятью перехватываются аппаратно и видны в явном виде в рантайме.
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

11. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +4 +/
Сообщение от Аноним (16), 01-Мрт-23, 10:27 
> Практика показывает, что даже крупные корпорации, такие как Google и Microsoft, имеющие жёсткую политику рецензирования изменений и применяющие современные методы разработки и инструменты статического анализа, не могут гарантировать отсутствие ошибок при работе с памятью (например, около 70% уязвимостей в программных продуктах Microsoft и Google вызваны небезопасной работой с памятью).

И не смогут крупные корпорации. Пока топят за скорость выдачи результата. Получается: быстро, дешевле, некачественно.

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

15. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +4 +/
Сообщение от Аноним (15), 01-Мрт-23, 10:35 
То ли дело в опенсорсе — медленно, дорого, качественно — баги в Xorg по 20 лет без движения висят
Ответить | Правка | Наверх | Cообщить модератору

19. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +2 +/
Сообщение от Аноним (19), 01-Мрт-23, 10:45 
С опенсорсом в корпорациях проблема таже - корпроативно быстро, подешевле, некачественно.

Опенсорс бывает в корпорациях тоже. Огромное количество.
За пределами коропораций качество софта - лишь мера собственных талантов.

Хочешь быстро - как Убунту. Хочешь - медленно.

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

107. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от OpenEcho (?), 01-Мрт-23, 16:20 
> Опенсорс бывает в корпорациях тоже.

Я бы даже сказал больше, - не было бы корпораций, то весь опенсорс так и застрял бы по большей части на ZX-spectrum, Микрошах и Специалистах. Все что более менее серьезное есть в опен соурсе бладодаря людям работающих за деньги полный рабочий день (или в обмен на блага, как у студентов)

Единичых фанатиков работающих за корочку хлеба можно "по пальцам перещитать"

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

164. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от kusb (?), 01-Мрт-23, 20:17 
Очень спорно, многие проекты начинаются за идею и не финансируются или раньше не финансировались ими, по моему.
Ответить | Правка | Наверх | Cообщить модератору

178. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от OpenEcho (?), 01-Мрт-23, 21:32 
> Очень спорно, многие проекты начинаются за идею и не финансируются или раньше
> не финансировались ими, по моему.

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

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

166. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от www2 (??), 01-Мрт-23, 20:27 
BSD избавлялась от компонентов AT&T Unix на средства университетов. Студентам и учёным нужны проекты, на которых они могут пройти практику, защитить дипломный проект, докторскую диссертацию. Ну а результаты их работ должны становиться общественным достоянием, т.к. делаются на средства налогоплательщиков.

Нужно просто финансировать НИИ и университеты, раздавать гранты на разработку тем. Финансировать может государство, отраслевые объединения и т.п. IEEE, например, по такому принципу отраслевые стандарты ращрабатывает.

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

182. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от OpenEcho (?), 01-Мрт-23, 21:44 
Вот кто, кто, но только лучше не государства, там просто сбросят бабло родственикам и распилят.
К сожалению очень многие не догонят модель опенсоурса. Почему конкурирущие компании вместе разрабатывают ОСС и отдают на халяву народу. Основное в этой модели:
- Вместе развивать продукт на котором делаяются деньги
- второе, - это на халяху получить кучу тестеров и ревьюверов
- ну и не надо забывать что безплатный сыр, - самая лучшая мышеловка.

Так что можно мечтать конечно, про коммунизм в ОСС, но без людей строгающих серьезные продукты 40 часов в неделю, профессионально (т.е за бабло), ОСС просто загнется. Если кто публиковал свой софт который "взлетел", меня поймут, т.к. это занимает огромное количество времени и рано или поздно желудок скажет, - "Алло!!!, ням-ням хочется, идеей питайся сам"

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

188. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от A (?), 01-Мрт-23, 22:13 
> Я бы даже сказал больше, - не было бы корпораций, то весь опенсорс так и застрял бы по большей части на ZX-spectrum, Микрошах и Специалистах. Все что более менее серьезное есть в опен соурсе бладодаря людям работающих за деньги полный рабочий день (или в обмен на блага, как у студентов)
> Единичых фанатиков работающих за корочку хлеба можно "по пальцам перещитать"]

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

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

В общем-то, после интернета только машинное обучение - единственное значимое из сделанного, вроде. Остальное из софта было написано и создано быстро, в бесплатном варианте, в _необходимом_ и _достаточном_ объёме.

Очень мало у Огрызков и Мелкомягких того, что _принципиально_ не может дать Малина с базовым Lялихом.

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

190. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от A (?), 01-Мрт-23, 22:16 
Из приниципиально важного, а не из шелухи.
Ответить | Правка | Наверх | Cообщить модератору

287. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Neon (??), 02-Мрт-23, 22:56 
ZX-spectrum - был вполне коммерческий проект.))) Боюсь, что и его бы в опенсорсе не было бы
Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

298. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от OpenEcho (?), 03-Мрт-23, 14:16 
> ZX-spectrum - был вполне коммерческий проект.))) Боюсь, что и его бы в
> опенсорсе не было бы

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

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

302. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (302), 03-Мрт-23, 14:54 
Де-факто опенсорсные улучшенные версии ZX-Spectrum были в СССР ещё до становления опенсорса как такового.
Ответить | Правка | К родителю #287 | Наверх | Cообщить модератору

26. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (26), 01-Мрт-23, 11:01 
Если не признавать что некачественно тогда прокатит. Как ты в проприетаре определишь что там качественно, а что нет. Работает и ладно.
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

129. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (129), 01-Мрт-23, 17:48 
> например, около 70% уязвимостей в программных продуктах Microsoft и Google вызваны небезопасной работой с памятью

Это потомубчто уних 70% програмистов индусы без профильного образования.

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

168. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от topin89 (ok), 01-Мрт-23, 20:34 
Это ведь процент уязвимостей, а не 70% кода из них состоят. Просто есть такая закономерность -- 70% на память, 30% -- на всё остальное. Если аппаратная платформа поможет быстро их выявлять, то уязвимостей будет в 2-3 раза меньше. Уже хорошо
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Не дидам, а их дегроднутым внучкам.

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

203. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (-), 02-Мрт-23, 02:43 
Диды иногда тоже жгут от души. Вон красавчики, дереференсят массив по входу функции. А там тип int. Ну вы поняли куда оно может там дереференснуть если caller сделает что-то странное. Проверок на это конечно же нет, так что вот вам вулн готовый, может половину памяти промотать вместо этого массива... и послать ее по коммуникационному протоколу, чтоб не скучать... :)

И тут скажите еще спасибо если я каталку пожелаю. А мог бы и катафалк за такое то. А зачем индекс signed делать вообще?! Кто-нибудь объяснит мне это вообще?

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

233. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от RM (ok), 02-Мрт-23, 13:31 
>А зачем индекс signed делать вообще?! Кто-нибудь объяснит мне это вообще?

Диды (K&R) говорили что просто int может быть по умолчанию или signed или unsigned. в зависимости от того, что эффективнее на конкретной платформе. И если нет разницы, то пиши int, будет быстрее, точно не медленнее.
А в эпоху дидов caller был локальным и контролируемым, не то что сейчас - аноним с интернетов

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

333. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 08-Мрт-23, 09:08 
> Диды (K&R) говорили что просто int может быть по умолчанию или signed
> или unsigned. в зависимости от того, что эффективнее на конкретной платформе.

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

И кстати если кто удумает int сделать unsigned по дефолту - он столько нового узнает сразу, когда вон те древние функции if ... < 0 как error использовали, плин. Ах да, ну конечно, структурированые antibug апи и прочие глупости - для лохов и нувориш. Которые так то прочухали что даже на сях можно какой-нибудь return struct забахать и это даже не настолько уж и неэффективно если не борзеть чрезмерно, а вернуть можно и статус операции и какие-то добавочные детали и еще что-то. Без какой-то левой черной магии с if abc > 100500 то это оказывается совсем не result а ашипку так сигналят, дескать, но поди там догадайся еще.

А эффективность это прекрасно но только до того момента когда вон там кодеры делают допущение что int это минимум 32 бита, но тут оказывается что 16 так то тоже формально ладушки - и вооооот вам тут всем дикий багодром. А по стандарту и не подкопаешься, так можно. И если в C89 это еще простительно было то в C99 и тем более 11 такие спеки уже совсем незачет.

> И если нет разницы, то пиши int, будет быстрее, точно не медленнее.

Ага, и оно быстро так оперативку куда-то налево дампит. А чо - caller видит что там int параметром и не парится (a - b) или (b - a), int ведь и отрицательное должен знать. А то что там кто-то массив дереференснет это ж сорц функции читать надо. Агаблин вот все читают сорц подключаяемых либ, от и до. Вот прям из их объектного кода сразу.

> А в эпоху дидов caller был локальным и контролируемым, не то что
> сейчас - аноним с интернетов

Диды не писали сложнее хелло ворлда и либы не признавали в принципе? А как тогда те навороты с линковкой появились? Они ж как раз для вот этого вот.

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

352. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от RM (ok), 04-Апр-23, 20:50 
Я писал в контексте вопроса ">А зачем индекс signed делать вообще?! Кто-нибудь объяснит мне это вообще?"
И написал в том числе "И если нет разницы, то пиши int, будет быстрее, точно не медленнее."
Еще раз - "И если нет разницы" и про (K&R) C.
Т.е. если это индекс массива в аргументе функции и надо hint - так вот и пиши unsigned int, кто ж за руки держит.
И доку/маны тогда все же писали и читали, не то что сейчас "все самодокументировано", действительно замучаешься читать код либ.

А по большому счету - так я с твоими доводами согласен, в смысле что в нынешних условиях можно и получше.
Только когда K&R C придумывали, весь UNIX крутился на 64 KB и не жужжал.

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

358. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (358), 04-Янв-24, 22:32 
>Диды (K&R) говорили что просто int может быть по умолчанию или signed или unsigned.

Мощное заявление, пруфов конечно же не будет.

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

359. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от RM (ok), 04-Янв-24, 23:25 
>>Диды (K&R) говорили что просто int может быть по умолчанию или signed или unsigned.
> Мощное заявление, пруфов конечно же не будет.

Да, память меня подвела, признаю, распространил я в своей голове поведение char на все int (целыe).

Я, когда все это читал, не захотел зазубривать всякие тонкости преобразований по умолчанию и потом при написании кода это еще крутить в голове до/вместо компилятора.
Поэтому вывел для себя это правило - писать как если бы signed или unsigned по умолчанию был не определен.
Вот если уже без конкретного подозрительного преобразования не обойтись - то представлять как процу/компилятору это легче сделать - он скорее всего так и сделает. Или просто смотреть нагенерённый асм.

А вообще там интересна, главная фраза
"The int types all represent signed values unless specified otherwise."
Specified видимо стоит читать как "не написано рядом unsigned спецификатора"
Хотя можно было бы в порядке троллинга и поспорить что мол не специфицировано мануалом на проц/компилятор.

НО, как всегда есть исключение - битовые поля.
Вот тама уже так как я написал.
"A field member (which need not have a declarator and thus may be unnamed) has type int, unsigned int, or signed int, and is interpreted as an object of integral type of the specified length in bits; whether an int field is treated as signed is implementation-dependent."
Ну и "Fields may be declared only as ints; for portability, specify signed or unsigned explicitly"

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

20. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от IdeaFix (ok), 01-Мрт-23, 10:45 
Ждём новостей о том как врырываются из очередной песочницы....
Ответить | Правка | Наверх | Cообщить модератору

27. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (26), 01-Мрт-23, 11:02 
Причем через npm.
Ответить | Правка | Наверх | Cообщить модератору

29. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от IdeaFix (ok), 01-Мрт-23, 11:11 
> Причем через npm.

Не, контент мейкером будет позитив софтваре, так что через паяльник :)

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

50. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Анонус (?), 01-Мрт-23, 12:33 
Позитив Текнолоджис
Ответить | Правка | Наверх | Cообщить модератору

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

это этого не надо защитать, указатели для этого и придуманы.

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

33. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (33), 01-Мрт-23, 11:45 
просто оно сделано defective by design
Ответить | Правка | Наверх | Cообщить модератору

34. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (32), 01-Мрт-23, 11:46 
Оно в процессоре так сделано
Ответить | Правка | Наверх | Cообщить модератору

55. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +3 +/
Сообщение от Аноним (46), 01-Мрт-23, 12:41 
Так в процессоре CHERIoT сделано уже иначе.
Ответить | Правка | Наверх | Cообщить модератору

267. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (265), 02-Мрт-23, 20:55 
RISC-V с дополнительным набором команд и на основе этих команд новый компилятор C/C++ способен реализовать безопасную работу с памятью.
Ответить | Правка | Наверх | Cообщить модератору

150. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноньимъ (ok), 01-Мрт-23, 19:38 
Именно.
Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

37. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +7 +/
Сообщение от Аноним (120), 01-Мрт-23, 11:54 
Почему Microsoft и Google не уволит свои криворуких кодеров и м..ак и не наймет экспетов по Си с opennet?
Ответить | Правка | Наверх | Cообщить модератору

39. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от Амомин (?), 01-Мрт-23, 11:56 
Дык им никто не рассказал почему-то до сих пор
Ответить | Правка | Наверх | Cообщить модератору

40. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (32), 01-Мрт-23, 11:56 
Месные эксперты с опеннет говорят там обязательно непустую учетку на гитхабе надо иметь к собеседованию. Хотя у меня всеего 1 раз спросили и сказали: "Ну нету дак нету, что теперь. Переходим к следующему этапу собеседования - hard skills".
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

110. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (120), 01-Мрт-23, 16:24 
Куда устраивался если не секрет? Взяли?
Ответить | Правка | Наверх | Cообщить модератору

133. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (32), 01-Мрт-23, 18:01 
Контрактором в Интел. Взяли.
Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

201. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 02-Мрт-23, 02:34 
> Контрактором в Интел. Взяли.

Думается интелу учетка на гитхабе не так важна как фактические знания и скилы того кого они нанимают.

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

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

Гитлаб, битбакет или self hosted gogs тоже сойдёт, если доступен публично.

Нету - ну так и нету, собеседование все равно всё покажет.

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

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

215. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (214), 02-Мрт-23, 09:25 
Почему ты просто не перепишешь всё на раст?
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

38. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Иваня (?), 01-Мрт-23, 11:56 
Очень интересно, спасибо за инфу, пригодится мне для разработки.
Ответить | Правка | Наверх | Cообщить модератору

43. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от YetAnotherOnanym (ok), 01-Мрт-23, 12:08 
> CHERI (Capability Hardware Extension to RISC-V)

CHERI - это у старшеклассниц, а "Capability Hardware Extension to RISC-V" должно называться "Червь".

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

57. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +2 +/
Сообщение от Аноним (46), 01-Мрт-23, 12:44 
Во, я тоже подумал про CHERVI.
Ответить | Правка | Наверх | Cообщить модератору

45. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +6 +/
Сообщение от Аноним (45), 01-Мрт-23, 12:20 
Никуда от указателей не деться в низкоуровневом программировании. Взятие данных по адресу -- это базовая инструкция центрального процессора.
Ответить | Правка | Наверх | Cообщить модератору

304. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (304), 03-Мрт-23, 18:00 
Это не значит, что указатель надо хранить в "голом" виде без обертки и позволять кому угодно делать с ним что угодно.
Ответить | Правка | Наверх | Cообщить модератору

47. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –2 +/
Сообщение от nc (ok), 01-Мрт-23, 12:25 
А что такого в том чтобы переписать существующий старый код? Ведь далеко не все ошибки связаны с переполнением буферов и неправильной работы с указателями. А переписывание кода заодно позволит его отрефакторить, да и просто посмотреть свежим взглядом.
Ответить | Правка | Наверх | Cообщить модератору

53. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (53), 01-Мрт-23, 12:37 
Такого - ничего. Только трудозатраты и время. Большие.
Ответить | Правка | Наверх | Cообщить модератору

126. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +3 +/
Сообщение от AKTEON (?), 01-Мрт-23, 17:34 
Таких программистов, которые были в 2004 году, сейчас мы даже приблизительно не  имеем(с)
Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

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

65. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от freecoder (ok), 01-Мрт-23, 13:39 
Rust делает проверки в compile-time, а здесь предлагается run-time решение, как я понял.
Ответить | Правка | Наверх | Cообщить модератору

202. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (-), 02-Мрт-23, 02:39 
> Rust делает проверки в compile-time,

Не все проверки можно в compile time сделать. Такая печалька. Скажем проверку переполнения математики в компилтайме как? А в рантайме это можно но на существующих процах надо команды делающие проверку флага добавлять - код сильно жирнее и медленнее получается, поэтому только в дебагбилды и годится.

> а здесь предлагается run-time решение, как я понял.

И это не такая уж плохая идея для некоторых случаев. Особенно если уж новую архитектуру развивать.

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

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

268. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (265), 02-Мрт-23, 21:07 
> проверку переполнения математики

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

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

328. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 07-Мрт-23, 22:30 
> К каждому числовому типу прикручены куча типажей которые определяют поведение данных при
> возникновение этих ситуаций. Другое дело что логической ошибки это не исправляет.

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

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

В общем случае да. Хотя вот тут даже чуть лучше...
1) Компилер в принципе даже наверное мог бы теоретически прочухать этот момент и варнинг кинуть, если не может вот тут строго доказать что входы этого всегда достаточно маленькие. Особенно если прогер не накастовал явно, изъявив желание знать лучше чего он хочет.
2) Вот на именно эти случаи у процов даже некая поддержка железом может и быть.

А вот с каким-нибудь более приземленными операциями, типа
uint8_t a, b, c;
a = 10;
b = 20;
c = a - b; // <- нет, возможно, мы и правда хотели миенно это. Но - не факт.

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

В вот именно этом случае компилер даже заранее знает ответ. И может варнинг кинуть. Де факто оптимизер оформит вон то как одну команду типа mov Rx, #const посчитав const в компилтайме еще. Но для пользовательского ввода например вы это сделать не сможете.

> Но верифицировать корректность значения Раст позволяет в этом случае.

По большому счету он не так уж далеко от сишки в работе с целыми ушел, просто менее дурно сделал некоторые вещи которые в си зачем-то очень криво специфицированы были "а потом все привыкли".

> Результат не выйдет за пределы и будет признак переполнения, например.

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

И проблема весьма фундаментальная: да, проц ставит флаг. Но его отлов - это дополнительные командочки, не нужные для самого вычисления, якорящие скорость и размер кода в разы. И если у вас какое-то крипто вместо 300 мегов в секунду сделает 100, на одном и том же алго, удвчи убедить всех что они должны именено вашим кодом пользоваться во имя луны. И докупить втрое больше серваков, за свои. Или камни втрое мощнее. Угу, за свои. Щас.

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

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

56. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –2 +/
Сообщение от Alexey Torgashin (?), 01-Мрт-23, 12:42 
Меня ребенок спросил - "А ты какие языки знаешь, знаешь СиПлюсПлюс? ОН СЛОЖНЫЙ!!!" Я говорю - "его не знаю, и он очень противный". Имея в виду что Паскаль не противный. На паскале можно писать гораздо БОЛЕЕ ЧИТАЕМЫЙ и безопасный код с проверками типов. Что и доказал мой проект CudaText.
Ответить | Правка | Наверх | Cообщить модератору

61. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +5 +/
Сообщение от непох (?), 01-Мрт-23, 13:03 
Это ваш бдсм-проект "очень противный", а не C++, которого вы не знаете.
И не забывайте таблетки от чсв принимать, а то вот опять обострение.
Ответить | Правка | Наверх | Cообщить модератору

115. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +2 +/
Сообщение от OpenEcho (?), 01-Мрт-23, 16:36 
> Имея в виду что Паскаль не противный.

Точно, в QuickBasic тоже про проблемы с памятью не знали.

Кстати прикол, видел недавно правда работающую программу компильнутую на TurboBasic. На вопрос, "переписывать не собираетесь?", получил ответ - "Зачем? Все работает и нас все устраивает"

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

147. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Tita_M (ok), 01-Мрт-23, 19:18 
Привет, Алексей! А почему Оберон не выбрали для своего проекта вместо Lazarus? Вы ведь в Lazarus пишете?
Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

212. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Алексей Торгаш (?), 02-Мрт-23, 09:19 
Видишь ли тут такое дело я не осилил Оберон. Да и не хотел его осиливать. Зачем если уже есть Паскаль? Паскаль — топ.
Ответить | Правка | Наверх | Cообщить модератору

240. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (235), 02-Мрт-23, 14:05 
Модулу смогёшь? Modula-2 включен в состав GCC 13.
Ответить | Правка | Наверх | Cообщить модератору

151. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноньимъ (ok), 01-Мрт-23, 19:40 
Спасибо вам за ваш труд!
Паскаль действительно очень интересная тема.
Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

288. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Neon (??), 02-Мрт-23, 23:02 
Только вот на Паскале никто почему то особо не пишет.))) Он не противный, он тривиально неудобный. Для мазозистов
Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

289. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (32), 03-Мрт-23, 00:22 
Посмотрел я этот ваш кудатекс. И что-то там сплошной object Pascal, а не паскаль. Это ж вроде изобретение Борланда, а не то что Никлаус Вирт завещал.
Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

66. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от freecoder (ok), 01-Мрт-23, 13:41 
А как этот процессор будет отличать ошибки работы с памятью от намеренных "оптимизаций" и бэкдоров?
Ответить | Правка | Наверх | Cообщить модератору

82. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от непох (?), 01-Мрт-23, 14:45 
Никак.
При наличии дырени для эксплойта нужно будет поприседать чуть больше, в том числе с добавленными инструкциями.

Вероятность появления дырени "в среднем по большине" действительно ниже, и вроде-бы труднее с ROP, насколько труднее - нужно посмотреть.

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

Уже понятно что у "черта" (aka CHERIoT) много общего с Prefast и Microsoft Static Analyzer (гибрида из clang-analyzer и prefast, который сейчас в Visual Studio).

Так вот, все релизы Microsoft Static Analyzer очень-очень сильно зависят от анотирования функций и имеют баги возрастом 3-5 лет. Поэтому для любых не hello-world проектов генерируют массу ложных предупреждений. Резолвить эти предупреждения иногда не возможно в принципе (ибо логические баги в анализаторе), поэтому приходится просто подавлять. Как себя в этих случаях поведет этот "черт" не ясно, 50/50 что будет глючить.

По-любому, похожесть на Microsoft Static Analyzer потребует переписывать весь действительно сложный сишный код. А с учетом скорости работы фуфла рикс-5 с такими проверками в железе - затея не взлетит .

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

106. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (106), 01-Мрт-23, 16:15 
А ничего, что компилятор ближе к железу, чем твой замечательный код?
Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

192. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (32), 02-Мрт-23, 00:04 
вроде оба работают с регистрами и инструкциями проца или компилятор работает как-то иначе... более ближе к железу?
Ответить | Правка | Наверх | Cообщить модератору

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

68. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от freecoder (ok), 01-Мрт-23, 13:43 
Вообще, сишники теперь должны полюбить Rust. Потому что он им даст больше свободы: пиши unsafe и разыменовывай нулевой указатель наздоровье. А тут - сам процессор твой код отвергнет.
Ответить | Правка | Наверх | Cообщить модератору

86. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (221), 01-Мрт-23, 15:02 
> Вообще, сишники теперь должны полюбить Rust.

наоборот, Rust не нужен вдвойне - достаточно пересобрать код специальным компилятором и использовать портированное ядро Linux/BSD и получить систему которая будет по настоящему безопасна во время работы, а не во время компиляции.

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

91. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от непох (?), 01-Мрт-23, 15:21 
Портировать ядро Linux или BSD на эту chert-ову байду проще чем переписать на Rust, но не настолько проще чтобы выбор был однозначным.
Ответить | Правка | Наверх | Cообщить модератору

117. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (117), 01-Мрт-23, 16:39 
> Портировать ядро Linux или BSD на эту chert-ову байду проще

Уже (причем, BSD задолго до пингвина).

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

92. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (221), 01-Мрт-23, 15:30 
> но не настолько проще чтобы выбор был однозначным

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

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

271. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (265), 02-Мрт-23, 21:29 
Скопилировать новым компилятором под (RISCV+расширенный набор команд). Обнаружить баги. Потом скопилировать старым под другой процессор? Это гарантирует отсутствие багов? Или это просто светлая дорога для нового RISCV в мир интернет-вещей?
Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

84. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (221), 01-Мрт-23, 14:56 
> Компания Microsoft открыла наработки, связанные с проектом CHERIoT

хорошо, но уже есть Linux

https://github.com/cheri-linux

проект arm morello с портированной freebsd

https://www.arm.com/architecture/cpu/morello

https://www.cheribsd.org/

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

99. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (46), 01-Мрт-23, 16:06 
В GCC тоже CHERI добавляли. Но пока только для Morello.
Ответить | Правка | Наверх | Cообщить модератору

94. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Заболотный (?), 01-Мрт-23, 15:40 
Они изобрели MPU?
Ответить | Правка | Наверх | Cообщить модератору

105. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (101), 01-Мрт-23, 16:13 
Судя по тому, что это делают 1) безопасники из майков 3) криворучки из подразделений Azure - эта херня не взлетит вообще никогда. Такую штуку могли теоретически запилить только в Майкрософт Ресерч, но им неинтересно под гнилую императивщину заплатки хлестать.
Ответить | Правка | Наверх | Cообщить модератору

109. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +3 +/
Сообщение от Аноним (109), 01-Мрт-23, 16:22 
> аппаратное решение

Бьёт по рукам при распарсивании ввода goto ? =)

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

118. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от OpenEcho (?), 01-Мрт-23, 16:42 
> Бьёт по рукам при распарсивании ввода goto ? =)

Ну тогда Леня Поцтеринг попал... по ходу и Торвалдс тоже

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

273. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (265), 02-Мрт-23, 21:32 
Запасайтесь попкорном. Только это всё имхо для отдельного сегмента.  
Ответить | Правка | Наверх | Cообщить модератору

204. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 02-Мрт-23, 02:46 
> Бьёт по рукам при распарсивании ввода goto ? =)

За него статический анализатор может по мозгам дать, если разрешить.

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

134. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (134), 01-Мрт-23, 18:01 
А в этом RISC-V классические инструкции NX, PAE для защиты памяти имеются?
Ответить | Правка | Наверх | Cообщить модератору

139. Скрыто модератором  +/
Сообщение от Аноним (-), 01-Мрт-23, 18:35 
Ответить | Правка | Наверх | Cообщить модератору

185. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от maximnik0 (?), 01-Мрт-23, 21:50 
А в этом RISC-V >классические инструкции NX,

Я по быстрому просматривал документацию,этого там нет.(Pae вообще то это расширенная адресация памяти,к безопасности отношение не имеет).Но не все так однозначно -в памяти исполнение программы запрещено,все вычесление только через регистры.А для вычесленных результатов есть память с допуском на запись через процедуру сохранение регистров. Но если нужна защита есть хитрый атрибуты для  атомарной операции. И ещё можно запретить чужой программе записывать в память.

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

256. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –2 +/
Сообщение от Аноним (256), 02-Мрт-23, 19:37 
>> А в этом RISC-V классические инструкции NX,
> Я по быстрому просматривал документацию,этого там нет.

Значит RISC-V - _г_о_в_н_о_ проц.

> Но если нужна защита есть хитрый атрибуты для  атомарной операции.

И как ты без NX будешь защиту памяти писать в OS? Надо реализовать: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#253

Писали когда-то защиту и для 286 без NX, но с какими-то другими инструкциями, регистрами - тормоза, ад и израиль!

Переписывать ядра OS никто не будет. Защита памяти уже реализована постранично или посегментно. Если проц не умеет ни постранично ни посегментно, то такое _г_о_в_н_и_щ_е_ никому ненужно!

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

258. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (258), 02-Мрт-23, 19:40 
И для виртуализации инструкции тоже необходимы.

Но NX нужнее.

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

305. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (302), 03-Мрт-23, 19:03 
С виртуализацией у RISC-V прогрессивнее всех нас егодня. Она там многоуровневая.
Ответить | Правка | Наверх | Cообщить модератору

275. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (265), 02-Мрт-23, 21:49 
Проц поддерживает тэгирование памяти (3 бита), а это покруче чем просто защита от исполнения (1 бит). Адреса хранятся в дескрипторе (128 бит), а не в указателе (64 бит). Дескриптор содержит указатель, размер и смещение. Работа с дескриптором защищена.

Постранично, посегментно это манагер памяти. Вы уверены что этого нет? Или просто хотелось?

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

308. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (308), 04-Мрт-23, 09:56 
> Проц поддерживает тэгирование памяти (3 бита), а это покруче чем просто защита от исполнения (1 бит)

Так говорите что память можно метить не только на исполнение, а есть еще бит для "только для чтения" и "запись", типа можно указывать обычние права RWX.

> Постранично, посегментно это манагер памяти.

Это метод защиты памяти. Постранично, на процах с NX защита работает без накладных расходов. А посегментно всегда чуть тормозит. В средине нулевых, после серии бажных Pentium-4 от Intel которые не верно работали с NX многие перестали доверять защите от проца и перешли на посегментную защиту.

> Вы уверены что этого нет?

Я не уверен что это есть, по этому и спрашиваю.

> Или просто хотелось?

Нет. Мне это необходимо и является основным критерием для выбора архитектуры процессора.

Жду патчи на ядро Linux с реализацией постраничной защиты памяти для RISC-V и mprotect() умеющий https://www.opennet.dev/openforum/vsluhforumID3/129886.html#253
А пока утверждаю, что в ядре Linux поддержки защещиты память даля RISC-V нет.
Может в NetBSD раньше появится. Если этот проц может паммять постранично защищать.

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

281. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от maximnik0 (?), 02-Мрт-23, 22:19 
> И как ты без NX будешь защиту памяти писать в OS? Надо
> реализовать: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#253

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


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

312. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (312), 04-Мрт-23, 12:10 
> Там есть 3 атрибута на память -Чтение,модификация и запись.

А надо - исполнение (запрет исполнения).

Еще раз, решили, что для обеспечения корректной работы ядра OS с памятью необходимо и достаточно:

  1. запрет изменения на исполняемую области памяти которая исполняемой не создавалась (W^X),
  2. запрет изменения на запись памяти которая выделена как исполняемая (W^X),
  3. запрет создания исполняемой памяти из анонимной памяти (W^X),
  4. запрет изменения на запись памяти выделеной только для чтения (RELRO).

У читывая что память выделяет ядро OS которое работает на процессоре, процесор должен иметь такие инструкции, чтобы максимально упростить написание ядра OS без потери производительности. И при этом процессор не должен быть переусложнённым.

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

315. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от maximnik0 (?), 04-Мрт-23, 22:06 
>И при этом процессор не должен быть переусложнённым.

Что то из перечисленного как мне кажется лишнее.Не забывайте что у RISC-V нет извращений для работы с памятью. Т.е  вычисления и другие операции минуя регистры запрещены.По крайне мере так я понял документацию.(Не забывайте что базовый набор команд совсем небольшой.) А насчет неисполняемого бита - еще для х86 было такое замечательное решение PaX .А насчет W^X с OpenBSD.В статье Криса Касперского "переполнение буфера на системах с неисполняемым стеком" говориться что эта защита обходиться множественным вызовом функции mmprotect.

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

323. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +2 +/
Сообщение от Аноним (323), 06-Мрт-23, 15:37 
> Что то из перечисленного как мне кажется лишнее.

Нет. В этом вся суть ИТ индустрии. Николая Вирт писал об этом в средине 1980-тых. Инструкции процессора NX _просты_ и необходимы для написания _простого_ ядра OS с защитой памати без потери производительности. Это база, основы.

То, что в RISC-V засунули 3 бита для чтения, изменения, записи вместо чтения, ИСПОЛНЕНЯ, записи - выглядит как умышленное вредительство, аппаратный троян.

А сабж от M$ явно лишний. И простым его не назовешь.

> Не забывайте что базовый набор команд совсем небольшой.

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

> А насчет неисполняемого бита - еще для х86 было такое замечательное решение PaX.

Оно и сегодня есть и не только для x86 - это пример правельной, эталонной, реализации защиты памяти ядром OS на процессорах с NX (alpha, avr32,  i386, ia64, parisc, sparc, sparc64, x86_64) или поддерживающих посегментную работу с памятью: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#309

> А насчет W^X с OpenBSD.В статье Криса Касперского "переполнение буфера на системах с неисполняемым стеком" говориться что эта защита обходиться множественным вызовом функции mmprotect.

В OpenBSD есть НЕ корректная реализация защиты памяти, с дырявым дизайном.

Можешь попробовать эксплоиты для обхода W^X в OS c корректной реализацией защиты памяти:

Linux+PAX  -  https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../

NetBSD. -  https://netbsd.org

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

354. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (354), 13-Май-23, 18:52 
> То, что в RISC-V засунули 3 бита для чтения, изменения, записи вместо
> чтения, ИСПОЛНЕНЯ, записи - выглядит как умышленное вредительство, аппаратный троян.
> Необходимый NX зажидили, но при этом инструкции виртуализации и сабж, включили.
>> А насчет неисполняемого бита - еще для х86 было такое замечательное решение PaX.

Какое необразованное, наглое вранье. Чем лапшу вешать людям на уши или коль сам веришь в то что говорит, заглянул бы в спеку priv, на эмуляторе посмотрел бы поведение в конце концов.

(Figure 4.15) The permission bits, R, W, and X, indicate whether the page is readable, writable, and executable, respectively.

https://riscv.org/wp-content/uploads/2017/05/riscv-privilege...

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

355. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (355), 24-Июн-23, 08:58 
Тесты RISC-V покажи: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#309

Важно иметь архитектуру CPU + ядро OS. В ядре OS тоже необходимо реализовать DAC для защиты оперативной памяти.

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

356. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (356), 17-Сен-23, 17:01 
>[оверквотинг удален]
>> Я по быстрому просматривал документацию,этого там нет.
> Значит RISC-V - _г_о_в_н_о_ проц.
>> Но если нужна защита есть хитрый атрибуты для  атомарной операции.
> И как ты без NX будешь защиту памяти писать в OS? Надо
> реализовать: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#253
> Писали когда-то защиту и для 286 без NX, но с какими-то другими
> инструкциями, регистрами - тормоза, ад и израиль!
> Переписывать ядра OS никто не будет. Защита памяти уже реализована постранично или
> посегментно. Если проц не умеет ни постранично ни посегментно, то такое
> _г_о_в_н_и_щ_е_ никому ненужно!

Не было там никаких тормозов, NX можно реализовать через отдельный tlb для выполнения, там было что-то вроде выставить атрибуты страницы, выполнить инструкцию или выставить и прочитать, тогда в кеше для выполнения и чтения/записи были разные атрибуты страницы (no_access/rw) что-то в этом роде

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

213. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Алексей Торгаш (?), 02-Мрт-23, 09:19 
RISC-V кстати открыт для твоих расширений. Но писать их надо будет исключительно на быстром и безопасном языке Паскаль.
Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

227. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (224), 02-Мрт-23, 12:19 
NX, PAE - это из мира x86. Причём, PAE - это для 32-битных CPU с целью расширения адресного пространства, а не для защиты от выходов за границы.
Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

250. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (250), 02-Мрт-23, 18:22 
В OS: Linux, BSD* используют 3 варианта:

1. Инструкция NX в процессорных архитектурах: alpha, avr32,  i386, ia64, parisc, sparc, sparc64, x86_64 разрешает написать постраничную защиту памяти ядром OS без потери производительности. Это стандарт для процессорных архитектур и стандарт реализации защиты W^X для памяти выделяемой OS.

2. Есть реализация защиты пямяти W^X основана на свойствах некоторых процесорных архитектур посегментно выделять память. Эта еализация имеет ограничения в 1.5Гб ОЗУ для проги, а также слегка притормаживает.

3. Ваше дырявое С-ишное ведро Linux/BSD* будет работать без защиты памати и с возможностью перезаписи испоняемых областей при возможном переполнении буфера.

Основываясь на выше сказаном: проц без инструкции NX - г_о_в_н_о, а если проц даже посегментно не может работать с памятью то он - г_о_в_н_и_щ_е! И никакой Rust не спасет.

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

276. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  –1 +/
Сообщение от Аноним (265), 02-Мрт-23, 21:54 
Вам просто подчеркнутое слово нравится. Повод употребить его так себе...
Ответить | Правка | Наверх | Cообщить модератору

278. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (265), 02-Мрт-23, 22:10 
Из топика: "каждая операция чтения и записи в память авторизуется"

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

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

324. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (324), 07-Мрт-23, 13:25 
Запрет исполнения есть не только в сегментной, но и в постраничной.

Вот надо организовать W^X.
Выделили пару страниц памяти для изменения, пометили W. Необходимо сразу пометить их запретом исполнения. В правильных процах для этого есть NX. А в вашем RISC-V есть три варианта для метки памяти: чтение, изменение (а зачем? ЭТО ТРОЯН!), запись. Метки запрета исполнения для страниц памяти в RISC-V нет!

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

329. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 07-Мрт-23, 22:34 
Ващет бывает и легитимный самомодифицируюшийся код. Скажем man "data 2 code transformation". Это довольно быстрый класс алгоритмов, когда под ситуацию на основе входных данных генерится наиболее оптимальный для вот именно этого входа код и дальше его выполнение ведет к наиболее быстрой генерации выходного результата из всех возможных.

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

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

330. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (330), 08-Мрт-23, 07:42 
> бывает и легитимный самомодифицируюшийся код

JIT зло. JIT несовместим с принципами безопасности.

Критерии корректности работы с памятью на компютерной архитектуре (проц + ядро OS): https://www.opennet.dev/openforum/vsluhforumID3/129886.html#312 гарантировано запрещают JIT.

Программы должны предусматривать сборку без JIT кода. Например иметь опцию конфигурации:


./configure ... --without-jit ...

Иначе на безопасных архитектурах работать не будут.

> когда под ситуацию на основе входных данных генерится наиболее оптимальный для вот именно этого входа код

В самом алгоритме проводить аналих входных данных и на его основе далее выбирать найлучший алгоритм (if, case).

>А ну да, надо алгоритмистов нагреть.

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

> А потом когда у вас всякое крипто, сжатие и алгоримика ухнет в разы думать чего делать дальше, "зато безопасно".


equery h jit

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

> И никто такие процы чота не покупает, потому что на соседних, по тому же техпроцессу, бенчи втрое быстрей кажут.

Спорный вопрос JIT, в зависимости от алгоритма, может дать чуть прирост ~10%, а может и замедлить. Потестируй JIT алгоритмы в OpenBSD.

Процессоры для построения безопасных архитектур более привлекательны для покупателя.

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

340. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 08-Мрт-23, 16:55 
> JIT зло. JIT несовместим с принципами безопасности.

Вон то не JIT. Просто класс алгоритмов такой. Скоростными дата компрессорами допустим используется.

> Программы должны предусматривать сборку без JIT кода.

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

> Иначе на безопасных архитектурах работать не будут.

В целом я как бы сторонник W^X но иногда это таки нагибает некоторые вещи и эффективные реализации. Это что, мне теперь даже qemu с TCG нельзя для кросс-эмуляции другого проца? Оно и с JIT то раз в цать медленнее чем хотелось бы. А без JIT или совсем не заработает или так работать будет что лучше б не работало вообще. Нафиг мне эмуляция ARMовской виртуалки в режиме пошаговой стратегии? Безопасность это хорошо, но если она ломает основную функциональность - окей, что-то идет не так и хвост виляет собакой.

> В самом алгоритме проводить аналих входных данных и на его основе далее
> выбирать найлучший алгоритм (if, case).

...потратив время еще и на это :). Ващет лучше в компилтайме в идеале так то. Но не всегда возможно.

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

Data2code transform - вообще не JIT. Это именно генерация кода по входным данным. И выполнение этого как самый быстрый способ получить результат в памяти, как результат работы вот этого кода. Такой вот оптимизационный трюк. А ну да, когда вон та гамеса не заработает вы и об этом узнаете. Зато безопасно.

> Спорный вопрос JIT, в зависимости от алгоритма, может дать чуть прирост ~10%,
> а может и замедлить. Потестируй JIT алгоритмы в OpenBSD.

Я в JS потестировал случайно. Не, там не 10% было. Скорее, 10 000% - дождаться загрузки современного почтаря без JIT малореально. А можете и в 0ad - там чуть не pathfinder на этом. И если его так заякорить, ну, будете воевать 5 юнитами вместо 200. Иначе реалтайм стратегия станет пошаговой.

> Процессоры для построения безопасных архитектур более привлекательны для покупателя.

Безопасность это хорошее дополнение, но только не ценой нагибания задач покупателя. А неработа даже вот веб почтаря или игрухи с интенсивным юзом JS в "медленной" логике - покупателя точно не обрадует. По примерно тем же причинам некоторые сильно замороченные вещи типа GRSec/PaX и проч в майнлайн портированы только частично.

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

342. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (342), 09-Мрт-23, 20:36 
> Вон то не JIT. Просто класс алгоритмов такой. Скоростными дата компрессорами допустим используется.

Критерии работы ПО с памятью определил: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#312 если прога им удовлетворяет то работать будет. Но JIT эти критерии исключают полностью.

> > Программы должны предусматривать сборку без JIT кода.
> Да пожалста, соберите себе браузер. А теперь зайдите им на гмыл, мылру, яндекс или что подобное.

Давно туда не ходил. Да и JS отключен для внешнего мира. Google Chromium имеет JS движок без JIT, специально разработали для архитектур с запретом JIT. Можно его пробывать. А вот Mozilla имеет JIT для JS и для поддержки плагинов, код без JIT предоставлять не хочет, ржавчиной занята.

> Data2code transform - вообще не JIT. Это именно генерация кода по входным данным. И выполнение этого как самый быстрый способ получить результат в памяти, как результат работы вот этого кода

Если удовлетворяет критериям корректности, упомянутым выше, то работать будет. Но здесь усматривается другое но, уже не связаное с процессором и работой OS с памятью. Дедушки заповедали нам, что запускать левые бинари система не должна (где-то в MULTIX еще) и сегодня используется кучу средств, начиная с DAC, которые запретят запустить бинарь собраный/скачаный пользователем. Система разрешает запуск только корректно установленного ПО. Но это уже другая история.

> Я в JS потестировал случайно. Не, там не 10% было. Скорее, 10 000% - дождаться загрузки современного почтаря без JIT малореально.

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

> Безопасность это хорошее дополнение, но только не ценой нагибания задач покупателя. А неработа даже вот веб почтаря или игрухи с интенсивным юзом JS в "медленной" логике - покупателя точно не обрадует.

Вот мы обошли круг и вернулись к первоначальному вопросу: инструкцию NX для реализации корректной работы с памятью без потери производительности в RISC-V сделают? Или при разработки процессора RISC-V корпорашки вкладывают деньги только в аппаратные трояны, чтобы иметь возможность изменять память и устанавливать буткиты с виртуализацией для запуска в них пользовательских OS.

Выше писал, что пользователя нагибает не технология безопасности, а жидо-масонские корпорашки:
1. Не включают инструкции NX для реализации корректной работы с памятью без потерь производительности. В место этого включают аппаратные трояны в процессоры. И это типа свободный процессор. Просто верх цэнизма.
2. Умышленно пишут JS код так, чтобы вынудить некоторых пользователей отключить корректно работающие с памятью алгоритмы для запуска кода с JIT.

> По примерно тем же причинам некоторые сильно замороченные вещи типа GRSec/PaX и проч в майнлайн портированы только частично.

Linix изначально старался корректно работать с памятью используя  NX инструкцию процессора i386 и других. А после переезда Тровальдса в САШ этот код с ядра был удален. Тогда пользователи с европы написали анонимно патчи PAX. И этот код Торальдсу в САШ не дадут включить в мейнлайн. Формальные отмазки:
1. PAX патчи анонимны, а от анонима мы ничего брать не будем.
2. Есть и другие реализации защиты памяти. Вот вы к общему знаменателю прийдите сделайте одну и ее включим.

То что с PAX/Grsecurity портировали в ядро линукс не всегда хорошо. Иногда получилось лучше, но в большинстве реализация в Linux есть хуже. Мейнтейнеры ядра в общем не поняли сути технологий защиты PAX/Grsecurity при их реализации в LInux.

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

348. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 14-Мрт-23, 04:19 
> если прога им удовлетворяет то работать будет. Но JIT эти критерии
> исключают полностью.

JIT не будет работать с W^X. Почему-то. Data2code transform тоже не будет. Эту технику специфичные датакомпрессорщики любят. Включая всяких проприетариев с рекордными параметрами по соотношению плотности сжатия к скорости распаковки. Игроделы всякие и т.п.. А заодно и упаковщики исполняемых файлов. Или программы патчащие себя для скорости. Это правда больше линукскернел так развлекается, но с чего бы программам в памяти себя патчить нельзя - кто ж его знает. Некоторые и патчат.

> Давно туда не ходил. Да и JS отключен для внешнего мира.

Это так то хорошо и правильно. И почтарь так то лучше этого кошмара. Но вон то юзерье вас не поймет и если мы про популярность проца и технологий...

> Google Chromium имеет JS движок без JIT,

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

> с DAC, которые запретят запустить бинарь собраный/скачаный пользователем.

...
> Система разрешает запуск только корректно установленного ПО. Но это уже другая история.

Это все прекрасно - кроме того что с одной сторонй DAC достаточно хлипкий и уповать только на него да ну нафиг. Для себя я предпочел иной путь. Вот вы видите меня. Допустим, мы смогли прорубиться. И тут окажется что доступа в систему по сути и нет. Можете в Download браузера орудовать и читать с десяток либ. Браузеру больше и не требовалось. А если вдруг это удастся обойти - то тут окажется что есть еще вопрос: а чей это W^X? Ах, какой-то виртуалки? Ну, а она не так уж и важна в конечном итоге. Может она вообще временно существует и через день перестанет существовать. Так что масштаб урона весьма маргинальный. Ну, ок, хаксор может упереть у меня даунлоады. Но вообще-то это и без меня скачать можно. Нет, никаких ништяков тут вообще совсем нет, system management, "контроль инфраструктуры" и проч - случается в совсем иных местах. Боее того - эта "инфраструктура" из виртуалок и мелких железок достаточно недружественна к левым типам. Так что они врядли много куда попадут, зато триггернут логи.

С другой стороны типовая программа уже содержит более чем достаточно либ и интерфейсов к системе для того чтобы в случае если ее удалось обмануть пожалеть об этом. Вон мозилла как-то лоханулась и позволила внешнему JS встраиваться в контекст браузера. А это доступ во все куда у браузера доступ есть. И даже если там W^X в вашем понимании и нет, это не мешает разбойному коду сканера дисков снять список дир, отстроить список интересных артефактов и утащить их всем скопом. Включая ключи ssh, логин-пароли популярных штук и какой там еще "cool stuff".

Видимо на концептуальном уровне я не доверяю идее Супер Нерушимых систем, предпочитая иметь эффективные запасные планы на случай если "супер нерушимое" окажется не совсем таковым. Как мозильский браузер с его вгрузкой JS в контекст морды браузера и далее шараханием по системе, при этом не так уж важно есть там JIT или нет, важно что JS влез в привилегированый контекст интерфейса браузера и может все то что сам браузер. На более низком уровне всякие ROP и прочие фокусы с неявным контролем дают много опций как сделать что-то вредное легитимному хозяину системы даже без совсем уж записи и выполнения кода. Это один из поводов для запрета явно ненужных сисколов и их параметров. Я стопроцентно уверен что браузеру не надо доступ к ssh, допустим, и у него нет никаких легитимных поводов трогать бинарник ssh вообще, или тем паче ключи пользователя (да, JS-сканер их пер первым делом). У меня это даже при срабатывании упрет только дырку от бублика, тут ничего кроме даунлоадов браузера нет а это все можно в интернете скачать было :)

> Когда-то была возможность работать без JS, ... поищи.

Я так то вообще программами почтарей предпочитаю. Но тем юзерам привычно воооон то.

> делается умышленно чтобы вынудить пользователей использовать JS с JIT и владельци
> сайтов имели возможность запускать вирусный код на компьютерах клиентов.

И на этот случай у меня есть довольно пустая и не информативная виртуалка. Даже если ее разнесут вдрызг я не так уж и расстроюсь, у меня снапшоты и темплейты есть. Хотя я дважды подумаю стоит ли подставлять даже ее.

> Вот мы обошли круг и вернулись к первоначальному вопросу: инструкцию NX для
> реализации корректной работы с памятью без потери производительности в RISC-V сделают?

Как по мне - MMU вообще отдельный от проца компонент. И на концептуальном уровне отличие в том что система может им рулить, а юзер напрямую нет. И если его можно на страничном уровне как W^X запрограмить - не вижу реальных проблем. В конечном итоге система (кернел) свое в такой системе у юзера отспорить чисто технчески может. А захочет ли и почему так - это уже административный вопрос а не технический. Сама железка может обеспечить эффективный и быстрый энфорс W^X на уровне тех же прав памяти.

А конкретно x86-32 был куском дурных проблем. В том числе - потому что в нем нет нормальных режимов относительной адресации. Этот хлам не умеет относительно PC адресоваться! Это значит что программу нельзя просто загрузить в адреса отличные от ее дефолтных. Ее сперва надо жестко пропатчить в куче мест - использовав жуткий костыль известный как relocations. Это by design клещится с идеей полного W^X, это либо патчится, либо не может работать в желаемых адресах. И вот там x86-32 нагородили дурных костылей. Остальные архитектуры просто не имеют этой проблемы, там обычно вокруг PC адресовать можно и то жоское костылестроение не актуально на самом базовом уровне.

> Или при разработки процессора RISC-V корпорашки вкладывают деньги только в аппаратные
> трояны, чтобы иметь возможность изменять память и устанавливать буткиты с виртуализацией
> для запуска в них пользовательских OS.

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

> 1. Не включают инструкции NX для реализации корректной работы с памятью без
> потерь производительности.

Я вообще не понимаю почему вам мало атрибутов памяти MMU, при обеспечении что их только система крутить может. И это вполне быстро.

> В место этого включают аппаратные трояны в процессоры.

Если что-то этим словом называть, #1 будет ME, #2 - PSP. И это в вон тех x86 так то. SMM mode с нельключаемым хэндлером в проприетарном мусоре блобваре тоже не далеко ушел, система даже вырубить это не может - у оси эффективного контроля над железом вообще НЕТ. Она в гостях.

> И это типа свободный процессор. Просто верх цэнизма.

На мой вкус там все в пределах разумного. И если отбросить перфекционизм, это сильный шаг вперед vs вон те. А знаете, если я из HDL для FPGA собрал core, я могу быть уверен что там нету ME. А для самой FPGA и ее бэкдоров вон то слишком сложно для осознания как ни крути и оно не сможет целенаправленно с эффективно этим воспользоваться даже если и было. А с x86 - опции какие вообще? А, лизать ботинки 2 корпам? Ну, офигеть, круто.

> 2. Умышленно пишут JS код так, чтобы вынудить некоторых пользователей отключить корректно
> работающие с памятью алгоритмы для запуска кода с JIT.

Ну как бы вот именно ЗАСТАВИТЬ меня юзать какой-то сайт - это надо минимум надзирателя с автоматом для эффективного энфорса. А для редких единичных случаев у меня есть чудные виртуалки.

> Linix изначально старался корректно работать с памятью используя  NX инструкцию процессора
> i386 и других.

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

> мейнлайн. Формальные отмазки:
> 1. PAX патчи анонимны, а от анонима мы ничего брать не будем.

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

> 2. Есть и другие реализации защиты памяти. Вот вы к общему знаменателю
> прийдите сделайте одну и ее включим.

Линукс портабельная система. Вот лично меня линукс интересует на ARM (-el,-hf,aarch64), MIPS, RISCV, x86-64. Итого 6 (суб)архитектур. С своими идеями как там и что. И я предпочту чтобы секурно было более-менее везде, ага.

> ядра в общем не поняли сути технологий защиты PAX/Grsecurity при их
> реализации в LInux.

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

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

350. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (350), 03-Апр-23, 20:09 
На все отвечать не буду, но прочёл всё.

> JIT не будет работать с W^X. Почему-то. Data2code transform тоже не будет.

W^X это фундаментальный и принципиальный момент для безопасности архитектуры.
"Все что исполняется никогда не должно изменятся, а что изменяется никогда не должно исполнятся" - это правило основа всей ИТ безопасности.

>> Google Chromium имеет JS движок без JIT,
> А вы им еще и пользоваться пробовали?

На многих архитектурах с W^X люди пользуются.

>> с DAC, которые запретят запустить бинарь собраный/скачаный пользователем.
>> Система разрешает запуск только корректно установленного ПО. Но это уже другая история.
> Это все прекрасно - кроме того что с одной сторонй DAC достаточно хлипкий и уповать только на него да ну нафиг.

Второй фундаментальный принцип ИТ безопасности утверждает, что сначала необходимо настроить DAC. Правельно настроеный DAC даёт вполне безопасную систему.

И только после настройки DAC стоит заморачиватся c MAC и прочим.

Сами технологии виртуализации не разрабатывались как технологии безопасности. Но совмещение PAX+Grsecurity+виртуализация даёт неплохой результат. Особенно интересны новые OS для безопасной виртуализации на SPARK: https://muen.sk/

> На более низком уровне всякие ROP

У меня ROP закрыт: https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...

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

это какие?

>[оверквотинг удален]
> концептуальном уровне отличие в том что система может им рулить, а
> юзер напрямую нет. И если его можно на страничном уровне как
> W^X запрограмить - не вижу реальных проблем. В конечном итоге система
> (кернел) свое в такой системе у юзера отспорить чисто технчески может.
> А захочет ли и почему так - это уже административный вопрос
> а не технический. Сама железка может обеспечить эффективный и быстрый энфорс
> W^X на уровне тех же прав памяти.
> ...
> Я вообще не понимаю почему вам мало атрибутов памяти MMU, при обеспечении
> что их только система крутить может. И это вполне быстро.

Хочу увидить реализацию защиты памяти и сравнить её размер и скорость работы с реализацией и работой NX+PAX.

Вот например для ARM с защитой памяти есть большие проблемы и костыли с анклавами, а реальной безопасности нет.

> А конкретно x86-32 был куском дурных проблем.
> ...
> Скорее, половина вон того было актуально для кривого 32-бит уродца с полутора
> регистрами без нормальной относительной реализации - и специфична для именно его
> чудесатых проблем, когда программы вообще не релокатабельны без жутких костылищ.

i686 и сегодняшние x86_64 с софтом собраным c -fPIE -fPIC нормально работают с ASLR и описанных тобою проблем нет: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#309
Но, если кто гвоздями в асемблере намертво прибил адреса памяти (для некоторых оптимизаций mmx, sse, ...) то да надо пересобрать прогу и писать позиционно независимый код. Есть вся документация
  equery h pic
выдало 1 архиватор и 5 прог связаных с видео. Пришлось их собрать без аппаратного ускорения mmx, sse* на x86_64 чтобы получить позиционно независимый бинарь для запуска в  ASLR ядре.

А "Full RELRO" у меня везде без проблем. Это о либах, опции к ld: asneeded, now, relro.

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

Читать доки надо перед тем как включать, или пользоватся стандартными профилями: https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...

> Линукс портабельная система. Вот лично меня линукс интересует на ARM (-el,-hf,aarch64),
> MIPS, RISCV, x86-64. Итого 6 (суб)архитектур. С своими идеями как там
> и что. И я предпочту чтобы секурно было более-менее везде, ага.

Для ARM защиты памяти нет, там костыли, не знаем как писать защиту памяти.

MIPS не имеет NX, но как PPC* имеет другое и мне не известно смог ли кто написать для него W^X ядро ОS.

x86-64 есть инструкции NX и есть эталонные реализации OS с защитой памяти: Linux+PAX, NetBSD.

RISC-V под вопросом вообще сама возможность написания OS с защитой памяти.

Тестируй: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#309

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

351. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (351), 04-Апр-23, 18:34 
> Линукс портабельная система. Вот лично меня линукс интересует на ARM (-el,-hf,aarch64), MIPS, RISCV, x86-64. Итого 6 (суб)архитектур. С своими идеями как там и что. И я предпочту чтобы секурно было более-менее везде, ага.

Классический алгоритм постраничной защиты памяти с использованием инструкции NX и без потери производительности работает на архитектурах: alpha, avr32,  i386, ia64, parisc, sparc, sparc64, x86_64.

На ppc, ppc64 там чуть по другому зделано, другая архитектура и постранична защита памяти будет чуть-чуть тормозить.

MIPS реализацию постраничной защиты памяти давно начинали писать за результат не знаю, но потери производительности чуть будут.

ARM слыхал материли, он о энергопотреблении, а не о безопасности. Проц разрабатывался не для работы с тяжолыми правельными ядрами. Разрабы ядер задавали вопросы ARM "а как вы понимаете безопасность". Потом вышел hardfp и от ARM отстали. ARM для экономии энергии и денег, а не для безопасности.

RISC-V - https://www.opennet.dev/openforum/vsluhforumID3/129886.html#323 Лично хочу чтобы добавили инструкцию NX! Тогда все классические защищённые ядра должны легко заработать.

Еще раз критерии корректной работы ядра OS с памятью: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#312
     1. запрет изменения на исполняемую области памяти которая исполняемой не создавалась (W^X),
     2. запрет изменения на запись памяти которая выделена как исполняемая (W^X),
     3. запрет создания исполняемой памяти из анонимной памяти (W^X),
     4. запрет изменения на запись памяти выделеной только для чтения (RELRO).
Архитектура процессора должена быть такая, чтобы код ядра OS был прост и производительность не сильно падала.

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

353. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (353), 11-Май-23, 15:27 
Инструкция  PAE в процах Intel позволяет делать ASLR без потерь производительности.
Ответить | Правка | Наверх | Cообщить модератору

301. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (302), 03-Мрт-23, 14:50 
А какие работоспособные ядра есть недыряво-сишные? Redox, мягко говоря, неработоспособно.
Ответить | Правка | К родителю #250 | Наверх | Cообщить модератору

309. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (309), 04-Мрт-23, 11:10 
Очередная тестовая сборка Hardened Gentoo GNU/Linux
-systemd -elogind -dbus -polkitd -jit -...

MAC отключен, работает только DAC:


# paxtest kiddie
PaXtest - Copyright(c) 2003-2016 by Peter Busser <peter@adamantix.org> and Brad Spengler <spender@grsecurity.net>
Released under the GNU Public Licence version 2 or later

Writing output to /home/user/paxtest.log
It may take a while for the tests to complete
Test results:
/usr/bin/paxtest: line 69: /usr/lib64/paxtest/x86_64-pc-linux-gnu-gcc: No such file or directory

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable stack (mprotect)              : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments                   : Killed
Anonymous mapping randomization test     : 28 quality bits (guessed)
Heap randomization test (ET_EXEC)        : 35 quality bits (guessed)
Heap randomization test (PIE)            : 35 quality bits (guessed)
Main executable randomization (ET_EXEC)  : 27 quality bits (guessed)
Main executable randomization (PIE)      : 27 quality bits (guessed)
Shared library randomization test        : 28 quality bits (guessed)
VDSO randomization test                  : 28 quality bits (guessed)
Stack randomization test (SEGMEXEC)      : 35 quality bits (guessed)
Stack randomization test (PAGEEXEC)      : 35 quality bits (guessed)
Arg/env randomization test (SEGMEXEC)    : 39 quality bits (guessed)
Arg/env randomization test (PAGEEXEC)    : 39 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 27 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 27 quality bits (guessed)
Randomization under memory exhaustion @~0: 28 bits (guessed)
Randomization under memory exhaustion @0 : 28 bits (guessed)
Return to function (strcpy)              : paxtest: return address contains a NULL byte.
Return to function (memcpy)              : Vulnerable                                                                        
Return to function (strcpy, PIE)         : paxtest: return address contains a NULL byte.                                      
Return to function (memcpy, PIE)         : Vulnerable


Тест показывает правильность работы процессора и ядра OS.
Return to function (memcpy)              : Vulnerable                                                                        
Return to function (memcpy, PIE)         : Vulnerable
Потому, что тот тест собирается без SPP. А вот на архитектурах MIPS, PPC даный тест должен пройти и без SPP, у них это делается аппаратно.

# hardening-check /bin/ls
/bin/ls:
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: yes
Read-only relocations: yes
Immediate binding: yes

# checksec -f /bin/ls
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FORTIFY Fortified Fortifiable  FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   Yes     5               17      /bin/ls

# checksec -pl 1
* System-wide ASLRPaX ASLR enabled

* Does the CPU support NX: Yes

* Process information:

         COMMAND    PID RELRO           STACK CANARY            SECCOMP          NX/PaX        PIE                     Fortify Source
            init      1 Full RELRO      Canary found            No Seccomp       PaX enabled   PIE enabled             Yes


    RELRO               STACK CANARY   NX/PaX        PIE            RPath       RunPath   Fortify Fortified   Fortifiable

* Loaded libraries (file information, # of mapped files: 4):

  /lib64/ld-2.26.so:
    Full RELRO      No canary found   NX enabled    DSO             No RPATH   No RUNPATH   No  0               0

  /lib64/libc-2.26.so:
    Full RELRO      Canary found      NX enabled    DSO             No RPATH   No RUNPATH   Yes 79              170

  /lib64/libpthread-2.26.so:
    Full RELRO      Canary found      NX enabled    DSO             No RPATH   No RUNPATH   Yes 0               27

  /sbin/init:
    Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   Yes 7               13


Даные тесты показывают правильность сборки и линковки ПО.
-D_FORTIFY_SOURCE=3 даст еще больше "Fortified", так что Rust не нужен.

# mount |grep -v -E '(noexec|ro)'

Тест на монтирование дисков. Ничего не должен выводить.

# sed -i 's/Virus//' /var/log/syslog.log
sed: cannot rename /var/log/sedKktIU4: Operation not permitted

Тест защиты логов от чистки. Файл лога остался неизменным.

# cp --preserve=all /bin/ls /tmp

# /bin/ls
работает
# /tmp/ls
-bash: /tmp/ls: Permission denied

# /lib/ld-linux-x86-64.so.2 /bin/ls
работает
# /lib/ld-linux-x86-64.so.2 /tmp/ls
/tmp/ls: error while loading shared libraries: /tmp/ls: failed to map segment from shared object


Запрет на исполнение любых левых бинарей.

$ ls /proc/1/
ls: cannot access '/proc/1/': No such file or directory

Пользователь должен видеть только свои процессы.

По моему мнению эта система соотведствует уровню "C2".
Обратите внимание на 3 вещи:
1. Запуск только установленных бинарей. Невозможность запуска левых бинарей.
2. DAC распространяется и на оперативную память. Корректность работы процессора и ядра OS с памятью - W^X.
3. Невозможность правки логов.

Больше тестов делают системы для аудита типа lynis https://cisofy.com/lynis/

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

311. "Fix"  +/
Сообщение от Аноним (311), 04-Мрт-23, 11:44 
Fix:
Потому, что тот тест собирается без SSP. А вот на архитектурах MIPS, PPC даный тест должен пройти и без SSP, у них это делается аппаратно.
Ответить | Правка | Наверх | Cообщить модератору

313. "Fix 2"  +/
Сообщение от Аноним (313), 04-Мрт-23, 12:56 
Права на процесы наверно лучше проверять так:

# ls -dl /proc/1
dr-x------ 8 root root 0 Mar  4 14:14 /proc/1

$ ls -dl /proc/1
ls: cannot access '/proc/1': No such file or directory

$ ls -l /proc |grep "$USER $USER"
dr-x------  8 user user     0 Mar  4 14:14 393098
dr-x------  8 user user     0 Mar  4 14:14 393211
dr-x------  8 user user     0 Mar  4 14:14 393224
dr-x------  8 user user     0 Mar  4 14:14 393229
dr-x------  8 user user     0 Mar  4 14:14 393250
dr-x------  8 user user     0 Mar  4 14:14 393259
dr-x------  8 user user     0 Mar  4 14:14 409653
dr-x------  8 user user     0 Mar  4 14:14 706112
dr-x------  8 user user     0 Mar  4 16:18 969673
dr-x------  8 user user     0 Mar  4 16:19 969677
dr-x------  8 user user     0 Mar  4 16:20 970599


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

310. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (310), 04-Мрт-23, 11:39 
> А какие работоспособные ядра есть недыряво-сишные?

Там не в одном ядре дело. Корректность работы достигается за счет связки 5-ти важных для затыкания C-ишных дыр компонентов:

  Процесор с NX + Ядро OS + Компилятор gcc + Линковщик binutils + Системна библиотека glibc.

По этому надо тестировать дистры Linux/BSD* и выбирать правильно собраные.

Мое мнение ядра:
Linux+PAX, NetBSD - вполне корректные и работоспособные.
FreeBSD, OpenBSD - некорректные.
DragonflyBSD - имеет потенциал корректности, но надо смотреть.

Запускай
paxtest blackhat
настраивай пересобирай опять запускай
paxtest blackhat
патчи настраивай пересобирай
paxtest blackhat
...

Важный момент: JIT код в корректных ядрах никогда работать не будет. Система должна гарантировать невозможность запуска левых бинарей и измененных бинарей.

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

320. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (117), 06-Мрт-23, 11:03 
> Мое мнение ядра:
> Linux+PAX, NetBSD - вполне корректные и работоспособные.
> FreeBSD, OpenBSD - некорректные.

FreeBSD+Hardened патчи
https://hardenedbsd.org/content/easy-feature-comparison
https://hardenedbsd.org/content/projects
> HardenedBSD's implementation of ASLR is the strongest implemented in any of the BSDs.

...
> NOEXEC prevents the creation of memory allocations that have both the writable and execute permissions set. If an allocation is created as writable, it can never be marked as executable. If is created as executable, it can never be marked as writable.

...
> Integriforce allows a system administrator to ensure file integrity through hash enforcement--similar in concept to NetBSD's Veriexec. Integriorce can be set in whitelisting mode, turning Integriforce into a verified application whitelisting tool.

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

322. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (323), 06-Мрт-23, 15:02 
Критерии корректности работы с памятью написал: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#312

Linux+PAX, NetBSD - этим критериям отвечают.

FreeBSD, OpenBSD - этим критериям не отвечают. Тео повелся на JIT. Если архитектура (процессор с ядром OS) допускают использование JIT кода, то она небезопасна.

DragonFlyBSD, HardenedBSD -- надо смотреть, дай вывод paxtest с этих BSD-ей.

Выше привел пример базового аудита корректности OS. Сделай и выложи результаты аудита корректности работы с *BSD.

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

141. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +2 +/
Сообщение от Аноним (141), 01-Мрт-23, 18:54 
теперь RISC-V начнёт падать в синий экран...
Ответить | Правка | Наверх | Cообщить модератору

299. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (302), 03-Мрт-23, 14:41 
В IoT не обязательно наличие экрана. Тогда во что?
Ответить | Правка | Наверх | Cообщить модератору

306. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (306), 03-Мрт-23, 22:40 
halt? reboot? Синий экран это виндузятник.
Ответить | Правка | Наверх | Cообщить модератору

316. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Личинка_Шигорина (?), 05-Мрт-23, 04:05 
Придётся купить.
Ответить | Правка | К родителю #299 | Наверх | Cообщить модератору

142. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Аноним (142), 01-Мрт-23, 19:03 
>даже на встраиваемых системах с 256 МБ ОЗУ
>на встраиваемых системах
>с 256 МБ ОЗУ
>даже

Эта корпорация полагает, что в каждой Ардуине 256 MiB RAM....
Неудивительно, что их решения стали прожорливыми...

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

148. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от пох. (?), 01-Мрт-23, 19:21 
эта корпорация логично полагает что эпоха пердулин прошла и их удел - мигать светодиодиком.

А эмбеднутые поделки на risc-v вполне могут и с полугигом сделать - песка полный пляж, бери совок и пеки чипы.

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

143. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (142), 01-Мрт-23, 19:05 
>Никакой код извне не может передать управление коду в компартменте и получить доступ к объектам, за исключением обращения к специально определённым точкам входа и использования указателей на объекты, явно переданные при вызове другого компартмента. Для кода и глобальных объектов в компартменте гарантируется целостность и конфиденциальность.

Лишь бы слово "анклав" не использовать, а то юристы Intel обидятся...

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

144. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (144), 01-Мрт-23, 19:10 
А PAE инструкции для защиты памяти от Intel патентированы или свободны как NX ?
Ответить | Правка | Наверх | Cообщить модератору

187. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от maximnik0 (?), 01-Мрт-23, 22:08 
>А PAE инструкции

О Господи,в Интел для этого специальные инструкции придумали или вы что то напутали ? Рае вообще-то расширение памяти для 32 битного режима,реализовано до фига где в других архетектурах процессоров.NX -неисполняемый,всего лиш 1 бит ,означает атрибут неисполнение  участка памяти.Да,он использует Рае т.к в стандартной адресации этот бит был не использован и предусмотрен. Этот бит не панацея, его в некоторых случаях можно обойти без срабатывания исключения,хорошо хоть 16 бит код запретили,там из за особенности адресации элементарно этот бит обходился.

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

253. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (253), 02-Мрт-23, 19:18 
> Этот бит не панацея,  его в некоторых случаях можно обойти без срабатывания исключения

Все зависит от реализации защиты памяти ядром OS.

Допустим защита пямяти не такая как в M$, OpenBSD, ... которая разрешает JIT код запускать, а правельная как в Linux+PAX, NetBSD, ... :

Строжайше запрещает:
  1. changing the executable status of memory pages that were not originally created as executable,
  2. making read-only executable pages writable again,
  3. creating executable pages from anonymous memory,
  4. making read-only-after-relocations (RELRO) data pages writable again.

как будешь обходить?

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

191. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от maximnik0 (?), 01-Мрт-23, 22:16 
>Лишь бы слово "анклав" не использовать, а то юристы Intel обидятся...

Юристам Интел в этом случае лучше помалкивать.Есть минимум 2 более ранних реализаций,просто срок действия патентов истек или истекает + использования кросслецензирование.Я имею в виду Барроуз и ИБМ (майфрэймы).

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

176. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Kuromi (ok), 01-Мрт-23, 21:22 
DRM очередной? Или встроенный зонд?
Ответить | Правка | Наверх | Cообщить модератору

303. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от подрывник (?), 03-Мрт-23, 17:45 
Жил-был дядя Боб,
Толоконный лоб.
Пошел Боб по базару
Посмотреть кой-какого товару.
Навстречу ему программист Балда
Идет, сам не зная куда.
«Что, Боб, так рано поднялся?
Чего ты взыскался?»
Боб ему в ответ: «Нужен мне умелец:
фронтендер, бекендер и за сервером сиделец.
А где найти мне такого
Работничка не слишком дорогого?»
Балда говорит: «Буду служить тебе славно,
Усердно и очень исправно,
В год за три щелчка тебе по лбу,
Есть же мне давай варёную полбу».
Ответить | Правка | Наверх | Cообщить модератору

189. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +1 +/
Сообщение от Sw00p aka Jerom (?), 01-Мрт-23, 22:14 
>а уже существующие проекты на С/C++ переработать достаточно проблематично

какие нафиг существующие IoT проекты, где они все? Их так много (в особенности легаси проекты)?  

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

205. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +2 +/
Сообщение от Аноним (205), 02-Мрт-23, 02:52 
К автору: в чем грех разименовать  указатель?
Ответить | Правка | Наверх | Cообщить модератору

207. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Sw00p aka Jerom (?), 02-Мрт-23, 08:39 
тем более в IoT :)
Ответить | Правка | Наверх | Cообщить модератору

347. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (-), 13-Мрт-23, 17:30 
> тем более в IoT :)

Фирма ARM нулевые указатели не любит. Поэтому единственным достижением станет брякнувшийся в Hard Fault проц. Это довольно сложно не заметить, а эксплойтировать что-то в вот именно этом состоянии уже врядли получится, это чаще всего считается за unrecoverable и лечится ребутом.

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

252. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от ЗанудаВФорточке (?), 02-Мрт-23, 19:09 
> приводящих к таким проблемам, как переполнение буфера, обращение к уже освобождённой памяти, разыменование указателей

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

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

274. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +2 +/
Сообщение от Аноним (274), 02-Мрт-23, 21:44 
Вместо того чтобы научиться программировать лепят такую горбуху.
Ответить | Правка | Наверх | Cообщить модератору

280. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (265), 02-Мрт-23, 22:14 
Идеальный программист это утопия.
Ответить | Правка | Наверх | Cообщить модератору

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

300. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (302), 03-Мрт-23, 14:45 
Так это для унаследованного кода, который требует перепрограммирования на большие лета.
Ответить | Правка | К родителю #274 | Наверх | Cообщить модератору

343. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Аноним (344), 10-Мрт-23, 18:10 
Так перепрограммируй, кто тебе не дает?
Ответить | Правка | Наверх | Cообщить модератору

318. "Microsoft открыл CHERIoT, аппаратное решение для повышения б..."  +/
Сообщение от Глашатый (?), 05-Мрт-23, 11:02 
Интересно, почему нейросети не приспособили до сих пор к анализу и переписыванию кода?
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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