Так сложилось, что в Qt4 Embedded, которую мы используем на нашем приборе Беркут-ММТ, нет поддержки таких устройств ввода, как энкодер. Т.е. если прицепить к прибору мышь — координаты при перемещении обрабатываться будут, а вот колесо прокрутки — нет. Потому что драйвер linuxinput не обрабатывает события с типом REL_WHEEL, которое генерит энкодер, а только REL_X и REL_Y, которые отвечают за изменение координат.

Кому интересно как эту проблему решить — добро пожаловать под кат.

Наша первая статья о Wi-Fi-чипе ESP8266 была тепло встречена хабра-сообществом. Не смотря на то, что содержала мало конкретной информации. Тому была веская причина — NDA, подписанное нами для получения SDK от производителя решения, компании Espressif. Именно поэтому мы просто рассказали, «вот, есть такое решение». Чтобы заинтересованные имели возможность обратить внимание.

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

Приветствую!

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

С чего все начиналось

Изначально мы занимались разработкой программного обеспечения для чип-тюнинга. Одна из основных задач которого — считать прошивку из ЭБУ (электронный блок управления двигателем) и записать ее обратно. Понятное дело, что для этих целей нужно каким-то образом связать компьютер и ЭБУ при помощи адаптера. Когда раньше подавляющее количество ЭБУ использовало простейший способ приема-передачи данных, достаточно было использовать простейший адаптер на транзисторах или специализированной микросхеме. Однако на сегодняшний день большинство автомобилей для «общения» своих компонентов со внешней средой используют CAN шину. Адаптер для CAN шины на транзисторах уже не соберешь, и тут однозначно нужен процессор, который будет управлять всем по определенной программе.
Так возникла первая проблема — как побороть CAN шину. Для того, чтобы не изобретать велосипед выбор сделан на использовании готового адаптера, который работает по стандарту J2534. Для тех, кто не в курсе, стандарт J2534 это стандарт, описывающий аппаратную и программную части устройства, с помощью которого можно произвести подключение к ЭБУ посредством компьютера. Разработали его американцы. Основной причиной его разработки стало законодательное закрепление возможности обновление прошивки ЭБУ не специализированным дилерским сервисом, а любым желающим. Собственно, если каждый желающий может обновить прошивку на своем телефоне, то почему он не может это сделать со своим автомобилем.

Самый доступный импортный аналог стоит в районе 200 долл. США. Как впоследствии оказалось, два одинаковых устройства, удовлетворяющие стандарту J2534, могут работать по-разному с одним и тем же программным обеспечением. Поэтому изначально пришлось привязаться к конкретному производителю и его устройству.

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

На днях, в прцессе портирования FreeRTOS на микроконтроллер с ядром Cortex-M1, о котором я уже писал, возник маленький вопрос, который совершенно неожиденно яростно сопротивлялся всем попыткам найти на него ответ при помощи ГУГЛА всемогущего. Причем в процессе поиска выяснилось, что этот вопрос интересовал не меня одного, а, значит, не может быть следствием врожденной (либо приобретенной) тупости вопрошающего, ну или, в крайнем случае, свидетельствует, что таковая встречается не столь уж редко. Слегка озадаченный невозможностью применить обычный способ поиска ответов, решил прибегнуть к более экзотическому и слегка забытому — подумать и найти ответ самостоятельно. К сожалению, тоже не получилось, равно как не помогла и попытка проконсультироваться с другими неглупыми людьми (сам себя не похвалишь — весь день ходишь как оплеванный). Поскольку на Хабре таковых должно быть в избытке, попробуем экстенсивный путь решения путем вовлечения в этот процесс еще большего количества специалистов. Поэтому вместо победного поста пишу пост жалобный — помогите, люди добрые, кто чем может. Итак, переходим к сути проблемы.

Уязвимость позволяет локальному пользователю повысить привилегии до root.
Уязвимые версии ядра c 2.6.31-rc3 по 3.15-rc5.
CVE-2014-0196

Проблема вызвана ошибкой в функции n_tty_write (drivers/tty/n_tty.c), в которой некорректно обрабатывалась ситуация доступа к виртуальному терминалу при использовании флагов «LECHO & !OPOST», что позволяло пользователю инициировать повреждение областей памяти ядра.

В одном из четырех случаев использование эксплоита вызывает крах ядра.

Эксплоит работает только на ядрах >= v3.14-rc1, т.к. в нем добавили:

tty: Halve flip buffer GFP_ATOMIC memory consumption

git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=acc0f67f307f52f7aec1cffdc40a786c15dd21d9
На который опирается эксплоит.

Добрый день, уважаемые хабровчане. В этом цикле статей мы с вами пройдем достаточно длинный, но весьма интересный путь по превращению обычного роутера в мини-компьютер с LCD-дисплеем. Для этого мы разработаем сначала USB-видеокарту на базе микроконтроллера STM32F103, потом тестовый драйвер, который позволит нам выводить на него графику, и, наконец – полноценный драйвер фреймбуффера, благодаря которому можно будет запустить настоящие графические приложения, такие как x-сервер. Заодно мы научимся включать наш код в дерево исходников OpenWRT, допиливать его ядро и делать прочие полезные вещи.
Ну а в самом конце мы получим результат, который, я надеюсь, вызовет ностальгическую слезу у многих читателей. Я постараюсь излагать материал таким образом, чтобы в конце каждого этапа мы получали осязаемый результат, не дающий угаснуть энтузиазму. Итак, начнем.

Для кого эта статья

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

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

Ingenic представила крошечный, основанный на MIPS, Newton COM для носимых компьютеров и IoT-устройств, работающих на Android или Linux под Xburst SoC, и с встроенными модулем WiFi и другими сенсорами.

О платформе «компьютер на модуле» от Newton сообщили как китайская полупроводниковая компания Ingenic Semiconductor, так и Imagination Technologies, которая лицензирует интеллектуальную собственность MIPS для Ingenic. Сообщение Imagination относилось только к носимым компьютерам, а Ingenic упомянула их только как первые в ряду приложений Internet of Things (IoT).

Кроме того, Newton может применяться в здравоохранении, бытовой технике, сфере безопасности, биометрии, промышленного контроля и потребительской электроники. Imagination также рассчитывает на применение Newton в качестве платформы для нового Android Wear от Google, хотя Ingenic об этом не упомянула.

QML технология красивая и радует глаз. Меня она очень заинтересовала, и я решил ее освоить. Но не тут то было, ибо я оказался тупым и беспомощным. Нигде в сети не нашел примера «для чайников» (наверно плохо искал), чтобы с нуля построить простейшее приложение QML и C++ в связке. Везде чего-то не хватало: или не учитывался Qt Creator, или код выдавал ошибки, или отсутствовали целые моменты, которые пользователи должны были сами знать. Официальная документация и примеры здесь на хабре также были с этими недостатками. Вот и решил после долгих попыток и ошибок написать такую статью для начинающих с подробнейшим описанием.

Задача. Нужно написать программу QML в связке с С++, где
1. На форме располагается кнопка, строка ввода, и поле вывода.
2. Требуется считать из строки ввода число, прибавляется 1, и ответ выводится в поле вывода.
3. Интерфейс написан на QML.
4. Функционал на С++, то есть нам нужно обеспечить взаимосвязь между QML и C++: кнопка QML вызывает С++ функцию, а функция меняет свойства QML объектов.

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

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

Написал мне вчера lfatal1ty, говорит, домашний роутер на x86 с CentOS как-то странно себя ведет, грузит канал под гигабит, и какой-то странный процесс «atddd» загружает процессор. Решил я залезть и посмотреть, что же там творится, и сразу понял, что кто-то пробрался на сервер и совершает с ним непотребства всякие. В процессах висели wget-ы на домен dgnfd564sdf.com и процессы atddd, cupsdd, cupsddh, ksapdd, kysapdd, skysapdd и xfsdxd, запущенные из /etc:

Начальный анализ

Сначала я полез смотреть, что же вообще происходит и насколько серьезно была скомпрометирована система. Первое, что мне пришло в голову проверить — /etc/rc.local. Там было следующее:

cd /etc;./ksapdd
cd /etc;./kysapdd
cd /etc;./atddd
cd /etc;./ksapdd
cd /etc;./skysapdd
cd /etc;./xfsdxd

«Хмм, ладно», подумал я. Полез в root'овский crontab