Pull to refresh
-10
0

Эксперт по разработке ПО

Send message
Ну зачем Вы пишите, если говорить не о чем?
А зачем отвечаете?

По этим двум вопросам однозначно, да!
Со стороны ОС поддержать новый процессор. И делается это на языке Си который не знает ничего об этом. Компиляторы дорабатывать не надо. Ибо они не будут напрямую работать с shadow stack, учитывая его архитектуру.

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

Embox это ОС и там пришлось работу со стеком (при переключении контекстов) сильно замысловатым делать.
А что вам мешало использовать встроенные средства языка Си для переключения контекста? Мы ведь уже выяснили что язык Си связан с термином стек.

(и даже конкретного ABI)
Нонсенс. Как получается что на MSVC я под Linux бинари собираю?

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

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

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

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

В C# тоже бенефиты, например память освобождать не надо. А как следствие сбурщик мусора требует процессорное время. И память освобождается дольше. И если тоже самое делать на С++, то результат себя лучше покажет, когда речь о высокой нагрузке. Вы не будете с этим спорить?

Нет, речь как раз о баге. Типичный пример, когда забыли проверить на нулл и разыменовали нулевой указатель. Или у вас такого не бывает?
Бывает. Когда я драйвер пишу, у меня DriverVerfier включен постоянно. Когда приложение, то memoryleakdetector прикомпоновываю. Все возможные инструменты проверки у меня работают постоянно. И я отлаживаю то что пишу, даже если в функции две строчки. И прорабатываю под отладчиком все возможные пути работы той или иной функции. А потом в комплексе все смотрю. Это не сложно. Обычная проверка того, что делаешь. Но, те о ком вы говорите, так не заморачиваются. Потому как им просто лень. Возникает вопрос, а зачем такой пассажир нужен? Как вы ранее упомянули, людей не поменяешь. Я, понимая это, по возможности буду избегать с такими встречи. И не буду входить в положение их тонкой и ленивой натуры.

Если человек не знает физику, то микробиологом ему не быть, потому что он основы не понимает.
А смена языка равна смене профессии? Языки высокого уровня, по сути ускорили разработку. Языки с «бенефитами» не только ускорили, но и ограничили. Поэтому и область применения у них разная.

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

Простите, но нет. Есть известный закон дырявых абстракций, который явно говорит, что достаточно знать +-1 уровень от своей текущей чтобы полноценно выполнять свою работу.
Скажите, а ассенизатор хорошо выполняет свою работу?

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

Но как уже сказано, знание «С++» никак не делает челвоека более хорошим разработчиком, чем знание C#.
Никак, согласен. Только, знание только С# тем более.
Ну так если посмотреть на правила приемки самолетов, то там не си используется, а его подмножество удивительно похожее на какой-нибудь раст опять же.
Это что-то доказывает? Это доказывает что везде надо применять этот язык? Самолетостроение все-таки несколько иная стезя. И подходы следовательно иные, сугубо специализированные.

Человека нельзя кардинально поменять. Нельзя сказать «с завтрашенго дня пиши без багов».
Речь по-моему не о багах. Кардинально можно уволить. А в утверждения типа «пишет плохо но круто идеи выдает» я давно не верю. Т.к. многократно видел что это не так. И т.к. если человек плохо разбирается в деталях, то и в глобальным смысле он видит еще меньше. Если человек не может кардинально меняться, ему надо менять профессию. Например на стройку пойти работать. Если конечно у него задача найти свою нишу. А если в целом, я не пойму откуда такая любовь к таким людям. Я с такими даже говорить не стану(в профессиональном смысле, профессионализм на человеческие качества никак не влияет). Что уже говорить о том, чтобы считаться с ними. Интересно выходит, делают хуже, а требуют к себе равного отношения. «Защита прав слабоумных».

Человеку можно дать более удобный инструмент, но и все.
Можно, и инструмент нужно улучшать. Но сути само по себе оно не меняет. Если человек на менее удобном инструменте не мог выполнять работу нормально, то он и на более удобном не сильно то себя проявит. Потому что основ не понимает. А бывает еще когда дурака грамота только портит. Скажем так, с удобством инструмента, должны расти и требования к задачам. А если так, то планка по задачам снижаться не будет, с чего бы ради он будет делать нормально, когда в голове больше двух переменных удержать не может? Но если планка не повышается, а инструмент удобнее и проще, и как следствие он ту или иную задачу уже может выполнить, то он, выходит обезьяна. Т.к. по сути по методичке уже делает, не понимая основ. И в том и в другом случае, мне видится, дело в человеке.
То есть, тот же раст на самом деле имеет кучу интересных фич, но зачем-то позиционируется многими как замена си со смущающей меня аргументацией.
А те кто позиционируют — ничего другого не знают. Вы на скольких языках пишете? Я по роду деятельности: ассемблер, СИ, C++, C#, Java, Phyton (web и 1С перечислять не буду, давно в прошлом). Уверен и у вас не один. Ибо данное вами высказывание наталкивает меня именно на такие мысли.

Так тяжело существовать параллельно, что ли?)
Безусловно да. Ибо человек, который знает только один язык, ограничен в восприятии контекста решаемых задач. А значит все должно быть как у него :) «Когда в руках только молоток, все начинает казаться гвоздем».

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

Так же и тут. Я и не против того чтобы все унифицировать. Но наша индустрия еще не выработала всего нужного. Есть legacy, есть лишнее, а что-то отсутствует. За много лет её существования поменялся ряд задач, которые мы решаем. Многие из них перестали вписываться в ту картину которая сложилась. Нужно переосмысление всего. И как следствие выработка новых подходов, механизмов и аппаратуры. А людей, которые решат данную задачу, просто нет. Потому что и спроса на них нет. А ведь это исследовательская работа, которая требует очень длительного вовлечения по времени. Ситуация осложнена тем, что корпорации деньги зарабатывают. И развитие как таковое отсутствует. Рынок насытился, и все думают о том чтобы прибыль осталась на том же уровне.

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

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

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

Я другой пример приведу, в процессорах Itanium стек данных и стек вызова развязан. А в будущем поколении процессоров Intel будет shadow stack. Что автоматически защищает от buffer overrun. Имеет ли язык Си к этому отношение? Что будет со стороны ОС сделано чтобы оно заработало? Надо ли будет дорабатывать компиляторы? По всем вопросам однозначно нет. А если так, возникает вопрос, как это получается, что появление аппаратного механизма делает абстрактный язык Си — безопаснее?

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

Когда говорят о безопасности, надо понимать контекст. А конкретный пример чего-либо, сам по себе может еще ничего не доказывать.

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

Механизм подписей пред-загрузчиков для Secure Boot, с теми требованиями, какие выдвигались к ним, несостоятельны.
Ну так и UEFI не состоялся. С ним намного больше проблем чем с BIOS. Все в практику уперлось. А стандарт разумный.

Всё основывается на доверии подписывающей стороны (Microsoft) к компании, и Microsoft не проверяет, что вы будете загружать в качестве второго загрузчика.
Отвечать должна Microsoft(по совести). Т.к. на себя замкнула подпись. Но только это к ним вопросы должны быть. Направленные.

Технически удостовериться, что компания не начнет подписывать всё что угодно ключом, включенным в пред-загрузчик, невозможно до обнаружения такого загрузчика.
Это не так. Было бы желание. Большинство тонкостей можно выяснить, работая с модулем как с черным ящиком.

даже не задумываясь, что делает что-то неправильно
А вы когда делаете что-то не так всегда это сознаете?

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

Вашу ошибку в NTFS можно использовать без прав администратора, и, возможно, даже удалённо, через какой-то софт.
Нет, нужен физический доступ к ПК. Она не критичная. А популярной она стала только потому что собрались любители покритиковать. Ну и любители пополнения контентов своих сайтов. Раздули из мухи слона. Всем нужна истерика.

На подмену EFI-загрузчика требуются права администратора в ОС (как в Windows, так и в Linux), злоумышленник должен написать свой буткит+руткит, и должен его ещё как-то использовать из ОС.
Видимо Petya как-то иначе работал. Пойду изучать.
Где-то выше, коллега по цеху упоминал что на практике все выродилось в то, что ШИМ все делали не безопасно. Справедливо и обратное утверждение. UEFI реализован чуть лучше чем плохо. Гарантии даете что этот механизм будет работать надежно? И что никто не пострадает?
По моему мнению, проблема не настолько значительная, чтобы придерживаться ответственного подхода к её сообщению.
Зачем тогда надо было статью об этом писать?

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

Ждем Petya2.
Скачать Silent UEFIinSecureBoot Disk в сети ZeroNet Git Center: 127.0.0.1:43110/1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv/

Я извиняюсь, а Silent в ZeroNet был залит по каким-то соображениям безопасности?
Читал книгу, «Дальняя Бомбардировочная». Воспоминания о ВОВ маршала Голованова. Ну так, там столько примеров, как себя США и Англия вели, не счесть. Мнение не просто популярно, а имеет место быть. Вся история это показывает.

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

США очень интересно воевали. Сделали 25 вылетов, говорят мы на том свете были, для нас война окончилась. И наши летчики, по 300 вылетов. И в каких условиях, самолет вернулся, баки пробиты, обшивки нет, сам самолет на обода сел, стрелок убит. И чего? Перекур и на следующий вылет.

Кстати из этой же книги забавный случай вычитал. Сталин посылал Рузвельту посылки всякие. Ну там балык, коньячок и так далее. Но не напрямую, а через Черчилля. Так вот коньячок никогда не доходил :) После чего Сталин Черчилля пригласил, по русски скажем, бухануть. В итоге напоил его и тот очень много лишнего наговорил. Глава называется «Не бойся, России я не пропью».
Нормальная контора это какая?
Где ориентир качество, а не скорость выпуска.

Где в рабочее время не сидят на левых сайтах?
Не сидеть на левых сайтах — не достаточно.

Так это любая продуктовая успешная компания.
Работаю в такой. Только деньги для меня, даже не половина успеха.

Бездельников хватает везде не только в айти.
Хватает. Только в IT их на порядок больше. Потому что деньги есть.
Успех?
Смотря что считать успехом. Если деньги — да, успех.

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

Как по мне, это, отчасти умелый маркетинг.
По-моему маркетинг не наука. А манипуляция.

Уж поверьте, сотрудники Apple работают на полную катушку.
Не поверю. Знаю двух из Intel, одного из NVIDIA. То что рассказывают они, говорит об обратном. Сам работаю в крупной компании.

Железка получилась клевая?
Красивая железка. А нужна? И для чего? Качественно жизнь людей оно как меняет?

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

На предыдущий пост:
Мне повезло, меня окружают люди, которые понимают принципы
А вы как поняли что они понимают? Попросили доказать надежность алгоритма?

И что для вас принципы работы? Для меня, это то что лежит в его основе его действий.

Вот спецификация AES, попробуйте реализовать это не понимая принципов работы.
В спецификации, тонна псевдокода. Я реализовывал. Только я не могу доказать его надежность. Значит ли это что я понимаю принципы?

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

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

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

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

Я другой пример приведу, вот вы заходите на FB. Вам выскакивает форма где предлагают пройти тест на «какому гению вы соответствуете». Вы отвечаете на вопросы. Вы сами им рассказываете свой психологический портрет. Более того, когда будете читать результат, вам может показаться насколько точный тест. На самом деле, результат который вы прочитали, в точности такой, какими были ваши ответы на вопросы. Просто другими словами. Ничего сверхъестественного. Это ли не слежка?

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

Но мы о другом говорили. Не о противодействии слежке.
За это надо платить. Где-то половину зарплаты.
Пусть так. Тогда пусть работодатель не использует результат этой работы как минимум на половину. И раз уж я платил половину зарплаты, то и половина результата работы — тоже моя.
Сравнивать свой код с чужим мы начитаем уже после того, как появилось солидное количество кода, написанного именно своими руками.
Я бы даже больше сказал. Многие ко стилю написания придираются. На основании чего и выводы могут делать. Хотя и те и другие могут делать неплохо. А в целом я с вами согласен. Оценивать начнешь тогда, когда сам начнешь понимать.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity