LINUXTALKS.CO

Блоги

Смотрим youtube свободно там где он заблокирован.

Блоги — How-to
Группа How-to

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

Нам нужен будет duckduckgo (поисковик такой) поиск в нем откровенно хреновый но нам подойдет. Открываем duckduckgo.com (утка) или ddg.gg и пишем что конкретно мы хотим смотреть на ютубе, потом в строку поиска пишем еще site:youtube.com (не должно быть пробела после двоеточия) нажимаем поиск и потом переходим на вкладку video в duckduckgo выбираем видео и смотрим. Если появится предупреждение типа «посмотреть на youtube» игнорируем его и выбираем просмотр в окне утки.

И наслаждаемся просмотром любимого фильма, сериала или чего угодно. Примечание: после выбранного видео не будет показа следующего как на youtube но зато можно сделать автоматический повтор воспроизведения выбранного видео в контекстном меню.

 ,

XoFfiCEr ()

Набивка буфера стека возврата

Блоги — Переводы статей
Группа Переводы статей

Retbleed — это название класса уязвимостей спекулятивного исполнения, связанных с инструкциями возврата. Средства защиты от Retbleed попали в основное ядро, но на момент написания этой статьи некоторые остающиеся проблемы не позволили им попасть в стабильные выпуски обновлений. Защита от Retbleed может сильно снизить производительность, особенно на некоторых процессорах Intel. Томас Глейкснер (Thomas Gleixner) и Питер Зайлстра (Peter Zijlstra) считают, что они нашли лучший способ, который обходит существующие средства защиты и вводит в заблуждение механизмы спекулятивного выполнения процессора.

Для того чтобы процессор мог предсказать значение после инструкции возврата, он должен иметь некоторое представление о том, куда вернется код. В последних моделях процессоров Intel существует специальная скрытая структура данных, называемая «буфером стека возврата» (RSB), которая кэширует адреса возврата для спекуляций. RSB может содержать 16 записей, поэтому он должен отбрасывать самые старые записи, если цепочка вызовов идет глубже этого значения. При возврате глубокой цепочки вызовов RSB может переполниться. Можно было бы подумать, что спекуляция просто прекратится в этот момент, но вместо этого процессор прибегает к другим эвристикам, включая предсказание из буфера истории ветвлений. Увы, техники неправильного обучения буфера истории ветвей на данный момент хорошо изучены.

В результате длинные цепочки вызовов в ядре подвержены атакам спекулятивного выполнения. На процессорах Intel, начиная с поколения Skylake, единственным способом предотвратить такие атаки является включение «функции» процессора indirect branch restricted speculation (IBRS), которая была добавлена Intel в начале эры Spectre. IBRS работает, но у нее есть нежелательный побочный эффект - снижение производительности на целых 30%. По какой-то причине пользователи не испытывают энтузиазма по поводу этого решения.

Другой способ

Глейкснер и Зайлстра решили попробовать другой подход. Спекулятивным выполнением обратных вызовов на этих процессорах можно злоупотреблять только в том случае, если RSB недополнен. Таким образом, если недополнение RSB можно предотвратить, эта конкретная проблема исчезнет. А этого, похоже, можно добиться, «набивая» RSB всякий раз, когда есть риск, что в нем закончатся записи.

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

Состояние RSB отслеживается с помощью 64-битного значения для каждого процессора, которое первоначально установлено в:

    0x8000 0000 0000 0000

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

    0xfc00 0000 0000 0000 0000

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

Этим «что-то» является быстрая серия вызовов функций (закодированных на ассемблере и приведенных в конце этого патча), которая добавляет 16 записей в стек вызовов, а значит, и в RSB. Каждый из этих вызовов, при возврате из него, немедленно выполнит инструкцию int3; это остановит спекуляцию, если эти возвратные вызовы когда-либо выполнялись спекулятивно. Конечно, реальное ядро не хочет выполнять эти инструкции (или все эти возвраты), поэтому код RSB-stuffing увеличивает реальный указатель стека на только что добавленные кадры вызовов.

В итоге RSB больше не соответствует реальному стеку вызовов, но в нем полно записей, которые не причинят вреда, если в них спекулировать. В этот момент счетчик глубины вызовов может быть установлен в -1 (все единицы в представлении двойного дополнения), чтобы отразить тот факт, что RSB заполнен. Теперь ядро защищено от эксплуатации Retbleed – до тех пор, пока не произойдет еще одна цепочка из двенадцати возвратов, и в этом случае RSB нужно будет заполнить снова.

Затраты

Довольно много работы было проделано для минимизации накладных расходов этого решения, особенно в системах, где оно не нужно. Ядро собирается с прямыми вызовами своих функций, как обычно; во время загрузки, если выбрана опция retbleed=stuff, все эти вызовы будут исправлены, чтобы проходить через учетные транзакторы. Сами блоки размещены в огромном страничном отображении, чтобы минимизировать накладные расходы на буфер lookaside трансляции. Несмотря на это, как отмечается в сопроводительном письме, существуют издержки: «Мы оба, что неудивительно, весьма ненавидим результат».

Эти издержки проявляются в нескольких формах. Требуется «впечатляющий» объем памяти для хранения банков и связанной с ними домашней работы. Раздувание ядра влияет на производительность, даже в системах, где не включена функция RSB stuffing. Дополнительные инструкции увеличивают нагрузку на кэш инструкций, замедляя выполнение. Последняя проблема может быть несколько смягчена, говорится в сопроводительном письме, если выделять thunks в начале каждой функции, а не в отдельном разделе. Глейкснер подготовил патч для GCC, чтобы сделать это возможным, и сообщает, что при его использовании некоторые потери производительности уменьшаются.

Сопроводительное письмо содержит длинный список эталонных результатов, сравнивающих производительность RSB stuffing с производительностью полного отключения защиты и использования IBRS. Цифры для RSB stuffing поражают воображение, включая 382% регресс производительности для одного микробенчмарка. Однако во всех случаях RSB stuffing работает лучше, чем IBRS.

Однако лучшая производительность по сравнению с IBRS интересна только в том случае, если достигнута главная цель – блокирование атак Retbleed. В сопроводительном письме говорится следующее:

Предполагается, что набивка на 12-м возврате достаточна, чтобы прервать спекуляцию до того, как она попадет в недополнение и откат к другим предикторам. Тестирование подтвердило, что это работает. Йоханнес [Викнер], один из исследователей retbleed, пытался атаковать этот подход и подтвердил, что он снижает соотношение сигнал/шум до уровня хрустального шара.
Очевидно, что нет никаких научных доказательств того, что это выдержит будущие исследования, но все, что мы можем сделать прямо сейчас, это строить догадки на этот счет.

Итак, похоже, что RSB stuffing работает – по крайней мере, пока. Это должно сделать его привлекательным в ситуациях, когда защита от атак Retbleed считается необходимой; хостинг-провайдеры с недоверенными пользователями – один из очевидных примеров. Но никто не будет доволен накладными расходами, даже если они лучше, чем у IBRS. Для многих пользователей RSB stuffing будет рассматриваться как умный хак, который, к счастью, им не придется использовать.

Оригинал статьи на LWN

 , , , ,

cocucka ()

Взаимодействие через Google Meet при сильно отличающихся разрешениях экрана

Блоги — How-to
Группа How-to

По работе пришлось провести серию удаленных встреч с коллегой из Швейцарии. Он должен был кое-что настроить на тестовом контуре под моим наблюдением, чтобы попрактиковаться в настройке и потом выполнять похожие задачи самостоятельно. Соответственно, созвонились через Google Meet, он показал свой экран, а мне надо объяснять, что, собственно, надо настраивать, и контролировать процесс.

Проблема: у меня ноутбук 13" с Full HD экраном (масштаб шрифтов 125%), у него десктоп с монитором более высокого разрешения, и буквы в его терминале и браузере для меня слишком мелкие. И еще Google Meet не умеет честный полноэкранный режим и отъедает часть разрешения на заголовок «Коллега is presenting» вверху и панель с кнопочками внизу. Собственно, приходится напрягать глаза, что нездорово.

DE у меня - Cinnamon, у него какой-то tiling WM. Каждый раз просить коллегу сделать шрифты покрупнее не хочется, поэтому я исследовал возможность внедрения какого-нибудь костыля локально, чтобы увеличить часть экрана.

В Cinnamon встроенная экранная лупа на самом деле есть. Ее можно включить через Control Center: Accessibility > Visual > Enable zoom. Тогда через Alt + прокрутку вверх можно увеличить часть экрана. Вот только это не помогло. Были буковки из горстки пикселей, стали буковки из горстки увеличенных пикселей. Оказывается, я не только напрягал глаза, но и мозги, чтобы додумывать, что это там написано. То есть, оказывается, уже на этапе отрисовки картинки с экрана коллеги на мой экран (а может, еще и при передаче картинки) происходит серьезная потеря информации.

Иными словами, чтобы экранная лупа стала полезной, Chromium должен отрисовывать Google Meet в буфер с разрешением, большим, чем разрешение моего экрана. Этого можно добиться через xrandr:

xrandr --output eDP-1 --scale-from 3840x2160

Сработало, но ценой мелких букв уже у меня.

А на самом деле эта функциональность встроена в Cinnamon, и команду xrandr вручную вводить не надо. Называется эта функциональность Fractional Scaling, и Cinnamon при ее использовании также заставляет графические тулкиты рисовать UI в большем масштабе. Логика такая: выбранный пользователем масштаб округляется вверх до ближайшего целого (125% -> 200%), GTK настраивается на отрисовку с целочисленным масштабированием в виртуальный буфер, который средствами xrandr затем уменьшается до настоящего размера экрана. С точки зрения приложений, разрешение экрана составляет 3072x1728, и буквы на экране коллеги уже отображаются как буквы, а не как горстка пикселей. Лупе есть, что увеличивать, а мне не приходится напрягать ни глаза, ни мозги.

Ну и напоследок, можно задать нестандартный масштаб экрана в ~/.config/cinnamon-monitors.xml в теге <scale> в секции <logicalmonitor>. Например, при значении 1.0000001 срабатывает округление вверх до 200%, а потом масштабирование вниз, по сути, на те же 200%. С точки зрения приложений, разрешение экрана составляет 3840x2160, и лупа берет такую детальную картинку в качестве исходной, а с точки зрения пользователя, изменений практически нет. Поэтому я эту настройку так и оставил. Единственный обнаруженный негативный момент - в mpv появляется тиринг.

P.S. Трюк со scale 1.0000001 в ~/.config/monitors.xml также работает в Gnome. Но экранная лупа там сделана менее удобно, чем в Cinnamon. Вызывается через Alt + Super + 8, и надо настроить следование за курсором мыши и половинный размер в параметрах доступности. Неудобно, что лупа бывает только в пол-экрана или во весь экран, но не в четверть экрана.

 , ,

AEP ()

Passwordless login with U2F security key

Блоги — Персональные блоги участников
Группа Персональные блоги участников

Настроить passwordless login с Yubikey проще парёной репы.

Надо:

  1. Установить libpam_u2f.so из их репы

  2. Зарегистрировать свой ключ pamu2fcfg > ~/.config/Yubico/u2f_keys

  3. Добавить в соответствующие конфиги pam (минимум для sudo и для login manager) строчку auth sufficient pam_u2f.so перед строкой @include common-auth

  4. Добавить правило udev ACTION=="remove", ATTRS{idVendor}=="1050", RUN+="/bin/loginctl lock-sessions"

И всё, теперь для логина можно тапнуть по ключу или, если ключа нет, ввести пароль. Компьютер блокируется, когда вытаскиваешь ключ из usb порта.

Это репост моего мини-гайда с ЛОРа, раз уж там есть, то пусть и у нас будет.

 , , ,

cocucka ()

Как исправить мигание изображения и прочие глюки отрисовки на связке KDE Plasma + Wayland + Nvidia

Блоги — How-to
Группа How-to

Если вы используете KDE с Wayland на фирменном (проприетарном) видеодрайвере Nvidia, вы можете регулярно сталкиваться с миганием изображения, как будто кусок предыдущего кадра быстро чередуется с куском текущего. У меня, например, такое часто бывало в диалоге открытия/сохранения при прокрутке списка файлов, а также в экране гостевых систем VirtualBox.

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

Вот как можно исправить мерцание текстур и шрифтов на KDE Plasma + Wayland + Nvidia

  • Прежде всего, обновите Plasma, Qt, Wayland и драйвер Nvidia до самых последних версий. Возможно, в этих версиях досаждающие вам баги уже исправлены.
  • Избавьтесь от полупрозрачностей везде, где это возможно. Сочетание Wayland + Nvidia до сих пор криво обрабатывает размытые полупрозрачности, так что проблема может быть в них.
  • Если предыдущие меры не помогли, то откройте Konsole и выполните следующую команду: echo "export KWIN_USE_BUFFER_AGE=0" >> ~/.bash_profile, после чего перезапустите сеанс (т.е. выйдите из системы и залогиньтесь снова).

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

 , , , ,

l-xoid ()

Снятие компауда BGA-чипов на ноутбуках Lenovo

Блоги — How-to
Группа How-to

Как всем интересующимся темой известно, BGA-чипы у леново приклеены на выступающий компаундом эпоксидный клей.

Происходящее в ходе экзотермической реакции застывание смолы необратимо, и любая китайская химия, продающаяся по 50 баксов за 50 мл, может лишь размягчить, а вернее расширить наружный слой компаунда, проникнув в его микропоры, но никак не помочь с компаундом Lenovo/IBM, который находится под самой микросхемой в большом количестве.

Для правильного снятия чипа и для того что бы не ушатать плату, поотрывав все дороги, нам необходимо выполнить следующие действия:

Как всегда ставим плату на термостол, нам нужно довести её температуру до примерно 170-180 градусов


В качестве верхнего нагревателя используем фен, а не ИК-голову. Можно и так и так, но воздух в данном случае предпочтителен, задувая под углы чипа, он лучше размягчает клей.


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

Готово, вы прекрасны, максимум оторвались пара неиспользуемых контактов.

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

С самими микросхемами всё довольно просто, берём жало типа «топор» и счищаем всю ересь.

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

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

Отдельно отмечу что это куда быстрее и проще, нежели наркоманские варианты с химией или спиливанием краёв чипа

 , , , ,

Kaschenko ()

Запуск программ под другим пользователем через sudo при минимальной раздаче прав

Блоги — How-to
Группа How-to

Данное HOWTO объясняет как запускать команды под другим пользователем на примере запуска файлового менеджера MidNight Commander (mc) командами вида:

sudo -u mc_user /usr/bin/mc

Подготовка компьютера

Сначала если пользователь под которым мы хотим запускать команду отсутствует в системе то создаём его аккаунт:

adduser mc_user

Там надо ответить на несколько вопросов, подробности в справке команды adduser получить доступ к которой можно набрав man adduser.

Убедиться в наличии или отсутствии этого пользователя можно проведя поиск командой grep по файлу /etc/passwd

$cat /etc/passwd | grep mc_user 
mc_user:x:1001:1001::/home/mc_user:/bin/sh
$

Как можно видеть такая строка есть и значит пользователь mc_user присутствует в системе.
(Получение справки аналогично: man cat и man grep по поводу | искать в интернете по запросу перенаправление ввода-вывода linux.

Потом командой passwd mc_user надо задать ему пароль и отдав ту же команду с параметром -l провести БЛОКИРОВАНИЕ аккаунта если доступ будет осуществляться с директивой NOPASSWD или на оборот, разблокировать аккаунт если директива(опция) NOPASSWD использована не будет запустив команду с опцией -u)
Примеры:

adduser -l mc_user
adduser -u mc_user

Обратите внимание, блокировка и разблокировка пользователя на заданный ему пароль никак не влияют, если пароль не задан то после разблокировки пользователя он сам не появится, вы должны его самостоятельно задать.
(Или не задать если он вам не нужен и вы не боитесь что к вам из сети придёт гость. а он придёт и даже быстрее чем на винду, за БЕЗЗАБОТНЫМИ линуксойдами целая охота).

Более подробную информацию о команде passwd можно получить запросом в системе справки линух man passwd

Сбор информации нужной для настройки sudo

Затем надо посмотреть содержимое файла /etc/hostname

$ cat /etc/hostname
kitchen
$

Из этого можно узнать что в данном случае компьютер называется kitchen.
Затем файл /etc/hosts

$ cat /etc/hosts
127.0.0.1	localhost
127.0.1.1	kitchen.local	kitchen

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
$

В нём можно видеть 127.0.1.1 kitchen.local из этого можно узнать что компьютер входит в виртуальный домен .local.

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

Настройка sudo собственно как таковая

Для настройки sudo в каталоге /etc/sudoers.d создаётся один или несколько файлов с произвольными названиями которые заполняются строками вида:

user	kitchen.local=(mc_user:kitchen.local)      NOPASSWD:/usr/bin/mc

в этой строке

  • user это имя пользователя который ЗАПУСКАЕТ команду sudo
  • kitchen.local название моего компьютера при этом .local условный домен внутри компьютера.
    • при этом первое упоминание kitchen.local это компьютер с которого можно отдавать команду ЯВЛЯЯСЬ пользователем user.
    • а второе упоминание в круглых скобках это название компьютера на котором можно отдавать команду ОТ ИМЕНИ пользователя mc_user.
  • mc_user пользователь, от имени которого я запускаю команду.
  • NOPASSWD директива sudo запускать команду без запроса пароля запускающего её пользователя, если её не указать то пароль будет запрошен.
    (Как не трудно догадаться у sudo есть и другие директивы которые вы можете изучить в её руководстве пользователя в интернете или через man sudo)
  • /usr/bin/mc абсолютный путь к исполняемому файлу файлового менеджера MidNight Commander.

!!! ВАЖНО! команда sudo разрешает запускать команду без указания полного пути, но так делать не следует, потому что если не указать путь то будет запущенная первая найденная в указанных переменной окружения PATH директориях команда с таким именем!!!
Если вы не знаете полный путь к нужной вам команде то вы может просмотреть её ярлык как текстовый файл и найти параметр Exec или отдать команду

type 'your_prog_name'

которая выведет полный путь к указанной ей команде если она находится в одной из директорий указанных в переменной окружения PATH.

После этих настроек команда sudo -u mc_user /usr/bin/mc отданная под пользователем user должна работать.
(Но под другими пользователями, в том числе под root НЕ ДОЛЖНА!!!)

Дополнительные настройки

Так же рекомендую закомментировать в файле /etc/sudoers строки с
%sudo ALL=(ALL:ALL) ALL и root ALL=(ALL:ALL) ALL.
Что они делают и с другими настройками sudo разбирайтесь самостоятельно.

Я, torvn77, как оригинальный автор этого HOWTO даю разрешение на его распространение и использование на условиях лицензии CC BY-SA и обязательного указания ссылки на его первую публикацию https://linuxtalks.co/blogs/how-to/2611

 ,

torvn77 ()

Из чего состоит процесс обнародования информации об уязвимостях в ядре Linux?

Блоги — Переводы статей
Группа Переводы статей

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

( читать дальше... )

Оригинал статьи

 , , , ,

cocucka ()

На LinuxTalks появился новый раздел «Блоги»

Блоги — Персональные блоги участников
Группа Персональные блоги участников

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

Доступны категории:

  • Переводы статей

  • Персональные блоги участников

  • How-to

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

 ,

cocucka ()

RSS подписка на новые темы