OberonCore

Оказывается, нашумевшая в этом месяце проблема OpenSSL опять вызвана отсутствием контроля выхода за границы массивов.

http://habrahabr.ru/post/218609/



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

Позорище

Насколько я знаю - нет. Границы массива там проверяются. А проблема в том, что пользователю позволено задать размер массива самому. То есть, если по протоколу для ответа требуется 20 байт, то пользователь может задать буфер размером 2000 байт. первые 20 из которого - ответ, а оставшиеся - мусор, который может содержать в том числе и ключи.

Позорище однозначно.

Что тут скажешь, вот эти вот 500 символов, они вроде как из некоего буфера. Получается, пароль и буфер смешаны - а в таком случае понимание кода усложняется, и выходит, что хакеры (не в смысле взломщика, а в смысле гуру программирования) объегорили сами себя.

Так чтобы проверить пароль, его всё равно нужно в какой-то буфер записать. Иначе проверять нечего. И в эти 500 символов попал не обязательно пароль того человека, который пытается зайти. Собственно, на то и расчёт.

Обсуждать технические детали, конечно, тут можно, но оправдать -- нет.

Сюда, что ли... Замечательная подборка программных глюков в военной сфере: http://neochapay.livejournal.com/325830.html. Например:

Читал-читал вашу книжечку по БК-0010, практически настольная книга.

Давненько это было... а вот какая связь с темой и с приведённой цитатой?

На бейсике потому что нужно программировать. DIM, мол, A[10] типа, ну и т.д. При программировании на бейсике все классические структуры данных, наподобие очередей и деревьев заранее помещаются в отдельную кучу конкретного и фиксированного размера. Это уже потом распоясались и привыкли к тому, что память автоматически выделяется, под неограниченный рост. А на бейсике - шишь. Нужно следить заранее. Берется массив или группа массивов, только с ними и работают. Ни шагу вправо, ни шагу влево. Только массив и его индексация. Изоляция всех структур данных на уровне семантики и синтаксиса. Никаких тебе указателей и прочей лабуды. Тут Вирт не доработал. Увлекся концепцией указателя и пошел по приматизму. Из Оберона это все тоже с успехом можно выкинуть. Пусть учатся программировать, а не указателями указывать. Единственная полезная структура данных - это массив, а единственная полезная конструкция - процедура. Все остальное - чтобы на обложке расписаться. У Вирта много таких заморочек: процедура, которая не процедура, а функция и т.д. где-то он рамсы попутал. Надо было изначально засандалить расширение структур по типу ПЛ/1, функции из языка выкинуть вообще, а указатели похерить на вечные времена и никогда о них не вспоминать. Для массивов - только фиксированный размер, в крайнем случае сознательная лазейка навроде redim. И все. Goto тоже можно было бы выпилить нафиг, но не факт. Реликвия как-никак. PEEK и POKE тожа. Лучше бы туда вместо этих указателей, инструменты векторизации запихнули. Касаемо параллелизма в языке - это вообще умора. Тут Вирт правильно заметил. Не в параллелизме дело и не в семафорах, а в трудности применения этой самой концепции. То же относится и к понятийной однородности. Вместо указателя на метод в составе структуры - тип данных "точка входа" - целое без знака=ADDR(proc) или что угодно, на ваш страх и риск.
Т.е. предлагаю краеугольную концепцию: pointer - считать вредным. А о существовании всяких значков вроде: &,^, *, -> и т.д. - забыть на вечные времена.

А как насчёт концепции "вычислительного модуля": - можно/нужно запилить такое на не-эльбрусовском железе?..

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

С этим можно согласиться. При условии, что массив может быть динамическим.

Да, это совершенно лишний реверанс в пользу математики, который не даёт ничего полезного, кроме (иногда) удобства синтаксиса вроде cos(sin(sqrt(my_cool_func(x)))).

Я уже плохо помню, что там в ПЛ/1 было, но вроде оно было статическим. В то время как любая реальная задача (какой-нибудь протокол связи) требует трактовать последовательность байтов по-разному в зависимости от значения первого, пятого и тридцать третьего байта (и так по дереву синтаксических возможностей, и опять же с динамическим размером последовательностей байтов). Короче, для динамического разбора последовательности байтов никакие самые навороченные структуры не пригодны. Можно оставаться в рамках массива, но без типизированного указателя для работы с данными в этих цепочках добавится необходимость вызова неких специальных процедур. Что даже на уровне машинного кода будет неэффективно, не говоря уж об издержках синтаксиса.

Это последовательность по Вирту?..

В общем, ФС Линукса рулит (дерево с прошивками, коими можно в принципе представить и зависимости)?..

1,2,3. Как это не выйдет? У меня выйдет, а у Вас не выйдет? Должно выйти. Главное напирать плотнее. Есть аргументы. Я о них тут когда-то давно распространялся. И по поводу структур в ПЛ-1 тоже. Там было и наследование и полиморфизм и черт в ступе. Но мне кажется что обойдутся.

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

Так куча она и есть куча, зачем отдавать кому-то распределение памяти, если эта простейшая, систематическая и крайне поучительная процедура имеет столько интересных приложений? Чтобы расписаться на обложке и назвать индекс указателем? В Фокале вон была переменная с индексом и никто не парился. А в Мампсе эта, частная вообщем-то, идея была доведена до относительного блеска в связи с реализацией В+дерева. А сколько упущено педагогического аспекта... Указатель можно свести к индексу, а индекс сводить к указателю, как бы глупо. Все эти вещи следовало бы вынести из языка в библиотеку, и пользоваться, если уж так позарез охота. В Си доподменяли менеджмент памяти массивами и индексами играми с цепочками "указателей" - вот он результат. А некоторые, не будем указывать пальцами на их почтенные бороды, просто несколько ограничили это безумие. Ввели его в рамки собственных, не вполне обязательных к использованию концепций, заодно расписавшись на обложке. Вместо того, чтобы от этого безобразия вообще отказаться. Еще одно основание - работа с массивами хорошо формализуется, она сплошь и рядом используется в качестве иллюстраций к разным проблемам: векторизации и другим в т.ч. графическим, гуевым и т.д. Это более математичный подход т.к. для него есть готовый математический аппарат.

На мой взгляд язык должен быть ни чем иным, как высокоуровневым ассемблером, позволяющим при необходимости реализовать любую идею. Его задача - избавить от чисто технических вопросов наподобие настройки адресов и обеспечить минимум высокоуровневых конструкций, которые нужно отбирать самым тщательными образом и варьировать от реализации к реализации, но так чтобы итог гарантировал максимум ортогональности и ясности. Массив это естественная конструкция, а указатель - вряд ли. Переменная типа адрес в памяти. Что это и кому нужна эта помесь железа с математикой? Бульдога с носорогом. Вирт просто напросто перешел от произвольного тыканья пальцем в память к ее метризации с помощью своих структур данных и введению соответствующего набора операций. Абстрагировавшись от низкоуровневых процессов управления памятью. Таких метрик можно, при большом желании, выдумать сколько угодно. Все они так или иначе моделируются массивами и, в каждом отдельном случае, получится отдельное издание талмуда - "Алгоритмы и структуры данных". Было бы вполне разумным излагать теоретические основы на примере наиболее фундаментальной конструкции - массива, что и сделано в ряде трудов прошлых периодов. Очень поучительное чтиво.

Вирт скомпилировал сам себя, изобразил на самом себе System 3 и решил, что дело в шляпе. Это должно было нам как бы намекать на "полноту и линейную независимость" Оберона. Ну и что? Мало ли...бывает.. МеnuetOS вообще на ассемблере настрочили. Каноничность из этого не следует. Это все равно, что разложение по многочленам оставить, а по тригонометрическим функциям - выкинуть нафиг, мотивируя этот акт "малопонятностью" последних.