Привет, Хабр! Представляю вашему вниманию перевод статьи "The Rust Release Team "Announcing Rust 1.34.0".

Команда разработчиков Rust рада сообщить о выпуске новой версии Rust, 1.34.0. Rust — это язык программирования, который даёт возможность каждому создавать надёжное и эффективное программное обеспечение.

Если у вас установлена предыдущая версия Rust с помощью rustup, то для обновления Rust до версии 1.34.0 вам достаточно выполнить:

$ rustup update stable

Если у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта.

Что вошло в стабильную версию 1.34.0

Основное улучшение этого выпуска это поддержка альтернативных cargo-реестров. Релиз также включает поддержку ? в документационных тестах, некоторые улучшения в #[attribute(...)] и стабилизацию TryFrom. Читайте далее о ключевых вещах или можете посмотреть подробные примечания к выпуску для дополнительной информации.

Продолжаем исследовать Эльбрус путем портирования на него Embox.

Данная статья является второй частью технической статьи об архитектуре Эльбрус. В первой части речь шла о стеках, регистрах и так далее. Перед прочтением этой части рекомендуем изучить первую, поскольку в ней рассказывается о базовых вещах архитектуры Эльбрус. В этой части речь пойдет о таймерах, прерываниях и исключениях. Это, опять же, не официальная документация. За ней следует обращаться к разработчикам Эльбруса в МЦСТ.

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

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

13 апреля в Санкт-Петербурге (оффлайн и онлайн) и 20 апреля — в Москве (только оффлайн) пройдет самый крупный семинар CLRium#5 за всё время его существования.

Прокопав дебри алгоритмов управления памятью я теперь могу, наконец, ответить на извечный вопрос: "а зачем это знать?". Раньше кроме как just for fun до этого момета мне сложно было что-то ответить по одной простой причине: по-хорошему мы ничего не знали о том, как работает память в .NET. Мы знали что есть GC, что есть в целях оптимизации три поколения. Кто-то из нас даже знал про эфимерные сегменты и карточный стол. Но это выглядело скорее как буклет к чему-то более сложному, что никак не описано. И теперь, когда есть и исходники и люди, в них копающиеся, мы, наконец можем ответить на этот вопрос.

Мы приглашаем вас всех на этот семинар и в течении которого с 10:00 до 20:00 с перерывами на снять напряжение с головы будет рассказано очень и очень многое о том, как же всё-таки всё устроено.

Введение в операционные системы

Привет, Хабр! Хочу представить вашему вниманию серию статей-переводов одной интересной на мой взгляд литературы — OSTEP. В этом материале рассматривается достаточно глубоко работа unix-подобных операционных систем, а именно — работа с процессами, различными планировщиками, памятью и прочиими подобными компонентами, которые составляют современную ОС. Оригинал всех материалов вы можете посмотреть вот тут. Прошу учесть, что перевод выполнен непрофессионально (достаточно вольно), но надеюсь общий смысл я сохранил.

Лабораторные работы по данному предмету можно найти вот тут:

• оригинал
• оригинал
• моя личная адаптация

Другие части:

• Часть 1: Intro
• Часть 2: Абстрация: процесс
• Часть 3: Введение в API процессов
• Часть 4: Введение в планировщик
• Часть 5: Планировщик MLFQ

А еще можете заглядывать ко мне на канал в телеграм =)

Введение в операционные системы

Привет, Хабр! Хочу представить вашему вниманию серию статей-переводов одной интересной на мой взгляд литературы — OSTEP. В этом материале рассматривается достаточно глубоко работа unix-подобных операционных систем, а именно — работа с процессами, различными планировщиками, памятью и прочиими подобными компонентами, которые составляют современную ОС. Оригинал всех материалов вы можете посмотреть вот тут. Прошу учесть, что перевод выполнен непрофессионально (достаточно вольно), но надеюсь общий смысл я сохранил.

Лабораторные работы по данному предмету можно найти вот тут:

• оригинал: pages.cs.wisc.edu/~remzi/OSTEP/Homework/homework.html
• оригинал: github.com/remzi-arpacidusseau/ostep-code
• моя личная адаптация: github.com/bykvaadm/OS/tree/master/ostep
• Часть 3: Введение в планировщик

Другие части:

• Часть 1: Intro
• Часть 2: Абстрация: процесс
• Часть 3: Введение в API процессов
• Часть 4: Введение в планировщик
• Часть 5: Планировщик MLFQ

А еще можете заглядывать ко мне на канал в телеграм =)

27 марта мы в Mozilla объявили о начале стандартизации WASI, системного интерфейса WebAssembly (WebAssembly system interface).

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

Что: WebAssembly — это ассемблер для концептуальной, а не физической машины. Он работает на различных архитектурах, поэтому и системный интерфейс нужен для концептуальной ОС, чтобы работать на разных операционных системах.

Вот что такое WASI: это системный интерфейс для платформы WebAssembly.

Введение в операционные системы

Привет, Хабр! Хочу представить вашему вниманию серию статей-переводов одной интересной на мой взгляд литературы — OSTEP. В этом материале рассматривается достаточно глубоко работа unix-подобных операционных систем, а именно — работа с процессами, различными планировщиками, памятью и прочиими подобными компонентами, которые составляют современную ОС. Оригинал всех материалов вы можете посмотреть вот тут. Прошу учесть, что перевод выполнен непрофессионально (достаточно вольно), но надеюсь общий смысл я сохранил.

Лабораторные работы по данному предмету можно найти вот тут:

• оригинал: pages.cs.wisc.edu/~remzi/OSTEP/Homework/homework.html
• оригинал: github.com/remzi-arpacidusseau/ostep-code
• моя личная адаптация: github.com/bykvaadm/OS/tree/master/ostep
• Часть 3: Введение в планировщик

Другие части:

• Часть 1: Intro
• Часть 2: Абстрация: процесс
• Часть 3: Введение в API процессов
• Часть 4: Введение в планировщик
• Часть 5: Планировщик MLFQ

А еще можете заглядывать ко мне на канал в телеграм =)

Я очень люблю видеоуроки. Почему-то информацию с текста лично я воспринимаю весьма и весьма плохо. А есть вещи, в которых информации на бумаге не так много. Возьмём, к примеру, уроки игры на балалайке: на YouTube есть замечательные разборы, как играть ту или иную мелодию (кому интересно, ищем по имени «Сергей Воронцов»), но повторить и заучить последовательность с потокового видео сложно. Надо или записывать на бумагу (судя по комментариям под уроками, некоторые так и делают), или докупать дополнительные материалы (но я не жадный, а домовитый).



В общем, в моём балалаечном случае, да и при многих других, надо идти так: посмотрел фрагмент, поставил на паузу, повторил несколько раз за автором, продолжил просмотр. Если что-то непонятно — отмотал назад, посмотрел повнимательнее. Но как это всё мотать, если руки заняты? Тем более, в моём случае они заняты пусть не огромным баяном, но всё-таки какой-никакой, а балалайкой. Значит, работать надо при помощи ног.

Первая часть
Вторая часть

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

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

Первая часть

Первая статья еще не успела остыть, а я решил не держать вас в интриге и написать продолжение.

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

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

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

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

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

Я решил написать статью, а если получится — то и серию статей, чтобы поделиться своим опытом самостоятельного исследования как устройства Bare Bone x86, так и организации операционных систем. На данный момент мою поделку нельзя назвать даже операционной системой — это небольшое ядро, которое умеет загружаться из Multiboot (GRUB), управлять памятью реальной и виртуальной, а также выполнять несколько бесполезных функций в режиме многозадачности на одном процессоре.

При разработке я не ставил себе целей написать новый Linux (хотя, признаюсь, лет 5 назад мечтал об этом) или впечатлить кого-либо, поэтому особо впечатлительных прошу дальше не смотреть. Что мне на самом деле захотелось сделать — разобраться, как устроена архитектура i386 на самом базовом уровне, и как именно операционные системы делают свою магию, ну и покопать хайповый Rust.

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

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

В статье на примере описания реализации алгоритма шифрования по ГОСТ 28147–89, построенного на сети Фейстеля, показаны возможности двухъядерного процессора BE-T1000 (aka Байкал-Т1) и проведены сравнительные испытания реализации алгоритма с помощью векторных вычислений с сопроцессором SIMD и без него. Здесь будет проведена демонстрация применение SIMD-блока для задачи шифрования по ГОСТ 28147-89, режим ECB.

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

TL;DR. В этой статье мы исследуем защитные схемы (hardening schemes), которые из коробки работают в пяти популярных дистрибутивах Linux. Для каждого мы взяли конфигурацию ядра по умолчанию, загрузили все пакеты и проанализировали схемы защиты во вложенных двоичных файлах. Рассматриваются дистрибутивы OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 и 7, а также Ubuntu 14.04, 12.04 и 18.04 LTS.

Результаты подтверждают, что даже основные схемы, такие как стековые канарейки и независимый от позиции код, ещё не всеми используются. Ситуация ещё хуже у компиляторов, когда речь идёт о защите от уязвимостей вроде столкновения стека (stack clash), которые попали в центр внимания в январе после публикации информации об уязвимостях в systemd. Но не всё так безнадёжно. В значительной части бинарников реализованы базовые методы защиты, и их число растёт от версии к версии.

Проверка показала, что наибольшее количество методов защиты реализовано в Ubuntu 18.04 на уровне ОС и приложений, затем следует Debian 9. С другой стороны, в OpenSUSE 12.4, CentOS 7 и RHEL 7 тоже реализованы базовые схемы защиты, а защита от столкновения стека применяется ещё шире при гораздо более плотном наборе пакетов по умолчанию.

При разработке аппаратной части комплекса REDD, описанного в этой статье, мы рассматривали различные варианты реализации. PSoC рассматривался, так как для него имеется готовый относительно стандартизованный, пусть и де-факто, вариант переходника USB-I2C. К сожалению, по причинам, описанным в статье про DMA, сделать что-то сложное для данного конкретного комплекса на PSoC не удалось, а простое — экономически нецелесообразно. Оказалось, дешевле взять микросхемы от FTDI. Но пока велись эксперименты с PSOC, вскрылись интересные подробности, которые имеет смысл опубликовать.

Наиболее полный источник информации о жизни создателя TempleOS Терри Дэвиса

Легко заклеймить Терри Дэвиса параноидальным, нарциссическим, душевнобольным и психически нестабильным расистом, 12 лет своей жизни проведшим за созданием бесполезной операционной системы TempleOS, предназначенной для разговоров с богом; но перед тем, как выносить ему свою оценку, нужно сначала составить полное представление о нём. История Терри – это трагическое повествование о том, как психическая болезнь забрала у нас человека, объявившего себя «величайшим из когда-либо живших программистов».

Ранние годы Терри Дэвиса

Терри Дэвис родился 15 декабря 1969 года в г. Вест-Аллис, шт. Висконсин. Но затем в течение жизни переезжал в Орегон, Вашингтон, Мичиган и Аризону. Он родился в большой семье, был седьмым ребёнком из восьми, а отец его был промышленным инженером, работавшим над ракетной системой "Титан" в 70-х и 80-х.

Рос он в близком контакте с братьями и сёстрами, но когда в зрелом возрасте начали проявляться проблемы с психикой, он решил, что: «Иисус не разговаривал со своими братьями и сёстрами, ему не хотелось иметь с ними ничего общего, ему лучше было с незнакомцами. И я такой же».

Нам предстоит сделать предпоследний шаг в практическом освоении работы с UDB. Сегодня мы будем вести разработку не при помощи автоматизированного UDB Editor, а в полуручном режиме, с использованием Datapath Config Tool. Очень хорошим подспорьем в освоении этого инструмента является документ AN82156 — PSoC 3, PSoC 4, and PSoC 5LP – Designing PSoC Creator Components with UDB Datapaths. Собственно, я сам учился по нему.

Итак, сразу к делу. Писать будем под Linux, на NASM и с использованием QEMU. Установить это легко, так что пропустим этот шаг.

Подразумевается, что читатель знаком с синтаксисом NASM хотя бы на базовом уровне (впрочем, ничего особо сложного здесь не будет) и понимает, что такое регистры.

Первая часть с функциональными требованиями тут.

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

В алфавитном порядке — Active Oberon, Ada, BetterC, IEC 61131-3 ST, Safe-C.