тут @netforhack в ЛС дельно подсказывает что ch340 нормально на linux работает, но поскольку у меня arch, по дэфолту ядро собрано без его поддержи. В Ubuntu должно быть норм.

А еще возможно я просто тупанул и не догадался набрать sudo modprobe ch341. То есть драйвер вроде есть. Дома перепроверю.

4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux модуль есть, работает из коробки

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852751

всем привет. есть у кого нибудь опыт постановки линукса на макбукпро?

на сиеру

попытался поставить rEFInd

не встает никак

А что пишет?

System Integrity Protection отключил в EFI?

SIP отключи, а ещё в архиве с rEFInd лежит .sh, который монтирует EFI раздел Можешь в этом разделе покопаться

Кстати, после отключения SIP (csrutil disable) не очищай NVRAM — включится обратно

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

Недавно появился SIP, но плясками его назвать трудно

Одна команда в recovery

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

В нормальных дистрибутивах всё будет работать "из коробки" в том числе при активированном Secure Boot.

я к тому, что зачем rEFInd тогда?

я к тому, что зачем rEFInd тогда?

Правильный выбор - долой этот костыль. Современные ядра Linux могут стартовать напрямую как EFI-бинарники. Называется EFIStub.

я уже несколько лет не слышал про проблемы с загрузкой линя на маках :)

я уже несколько лет не слышал про проблемы с загрузкой линя на маках :)

Потому что их нет

Сейчас уже спокойно грузится все

я уже несколько лет не слышал про проблемы с загрузкой линя на маках :)

Загрузка с USB/DVD/etc — не проблема Возникают сложности при замене стандартного загрузчика

а зачем менять стандартный загрузчик?

В нормальных дистрибутивах всё будет работать "из коробки" в том числе при активированном Secure Boot.

Только надо понимать что у тебя не будет из коробки поддержки secure boot, у тебя будет поддержка костыля который делает бесполезным secure boot даже при его наличии

Только надо понимать что у тебя не будет из коробки поддержки secure boot, у тебя будет поддержка костыля который делает бесполезным secure boot даже при его наличии

В нормальном дистрибутиве есть поддержка хуков "kernel installed-removed". Добавляешь туда свой собственный, который будет подписывать ядро твоим ЦА, который заранее был добавлен в список доверенных в Secure Boot.

Для нормальной поддержки secure boot в лине нужно собирать ядро и initramfs в виде одного блоба, подписывать его и грузить на прямую через efi stub

При этом все остальное содержимое диска должно быть зашифрованным

Для нормальной поддержки secure boot в лине нужно собирать ядро и initramfs в виде одного блоба, подписывать его и грузить на прямую через efi stub

Этот механизм называется EFIStub и уже давно рекомендуется к использованию на всех UEFI-совместимых конфигурациях.

В нормальном дистрибутиве есть поддержка хуков "kernel installed-removed". Добавляешь туда свой собственный, который будет подписывать ядро твоим ЦА, который заранее был добавлен в список доверенных в Secure Boot.

Это НЕ поддержка secure boot, это обход secure boot

При этом все остальное содержимое диска должно быть зашифрованным

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

Ох уж этот Виталий, старый добрый Виталий %) здравствуйте!

Поддержка secure boot это когда он защищает твою систему от коспроментации

Это НЕ поддержка secure boot, это обход secure boot

Сертификаты Microsoft и загрузчик - это как раз адский костыль и попытка его обхода.

Поддержка secure boot это когда он защищает твою систему от коспроментации

Он и защищает. Твоё ядро и базовый стартовый пакет подписаны твоим собственным доверенным CA.

Он и защищает. Твоё ядро и базовый стартовый пакет подписаны твоим собственным доверенным CA.

Так из коробки без перекомпиляции ядра такого нет вообще нигде

Сертификаты от Microsoft нужно сносить первым же делом после покупки новой материнской платы ибо дырище.

Так из коробки без перекомпиляции ядра такого нет вообще нигде

google://efistub

Перекомпиляция ядра не нужна совершенно.

Это irrelevant, помимо него тебе нужна вторая сущность которая будет проверять целостность initramfs, в ядре такой сущности нет, поэтому тебе нужно собрать и ядро и initramfs в виде одного блоба что бы фирмварь могла чекать целостность сразу всего

Т.е., единственный способ сделать это на линуксе что бы оно реально защищало от evil maid атак -- это собирать все в один self containable бинарник и шифровать диск

Это irrelevant, помимо него тебе нужна вторая сущность которая будет проверять целостность initramfs, в ядре такой сущности нет, поэтому тебе нужно собрать и ядро и initramfs в виде одного блоба что бы фирмварь могла чекать целостность сразу всего

В нормальных дистрибутивах ядро уже собирается с включённой опцией CONFIG_EFI_STUB.

Далее один-единственный post-install хук делает всё, что тебе нужно.

Ты читать умеешь? Походу нет

У тебя помимо ядра есть initramfs который маунтит зашифрованную ФС, во всех дистрибутивах он лежит на бут партиции как отдельный файл -- фирмварь не имеет представления о его наличии поэтому прочекать его целостность она не может. Ядро тоже не имеет штатной опции что бы проверять подпись initramfs

У тебя помимо ядра есть initramfs который маунтит зашифрованную ФС, во всех дистрибутивах он лежит на бут партиции как отдельный файл -- фирмварь не имеет представления о его наличии поэтому прочекать его целостность она не может. Ядро тоже не имеет штатной опции что бы проверять подпись initramfs

У нормальных людей /boot вынесен в отдельный незашифрованный раздел.

Там есть только опция позволяющая засунуть его внутрь самого бинарника ядра

Всё остальное уже зашифровано.

У нормальных людей /boot вынесен в отдельный незашифрованный раздел.

Да, на этом разделе у тебя лежит неподписанный initramfs

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

И подписанное ядро

Их можно склеить в один подписанный бинарник, но из коробки этого нигде нет

Их можно склеить в один подписанный бинарник, но из коробки этого нигде нет

"kernel post-install" скрипты в помощь.

Из коробки EFIStub нет нигде кстати.

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

Перечитай ещё раз и вникни в то что я писал, я как раз и подразумевал не зашифрованный бут раздел

в чатике @secinfosec, с вашими оборотами, уже была бы поножовщина, братки уже выезжали бы спрашивать за базар %)

Из коробки во всех дистрибутивах идёт стандартный набор "Grub2-efi, подписанный ключом Microsoft".

Да, и это хуйня полная

Да, и это хуйня полная

Да, ибо по сути обход SecureBoot.

ERROR: S client not available

На деле тот же Grub 2 может загрузить вообще что угодно.

Да, я это и говорю

И из коробки по-нормальному не сделано ни в одном мажорном дистре

И для поддержки initramfs вкомпиленного в ядро нужно ВНЕЗАПНО пересобирать ядро

И из коробки по-нормальному не сделано ни в одном мажорном дистре

Пока ещё живы non-efi системы такого к сожалению не будет.

И у EFIStub есть очень серьёзный недостаток - нельзя без пересборки менять параметры ядра.

А зачем их менять?

В том же Grub 2 или любом другом загрузчике очень легко их добавлять/удалять.

А зачем их менять?

Иногда необходимо что-то добавить например пользователям различных проприетарных дров.

Это зло на самом деле, ядро очень легко нагнуть раком через эти параметрв

Они и должны быть жёстко зашиты в бинарник ядра а бинарник подписан

К сожалению, по-другому никак

Иначе будет решето

Проприетарщикам не привыкать к такому. ?

Например проприетарный драйвер карт от broadcom раньше явно требовал указывать параметры ядра.

Как сейчас я не знаю. Надеюсь, осилили modprobe.d конфиги.

Иногда необходимо что-то добавить например пользователям различных проприетарных дров.

А, ну это обычно при апгрейде железа надо, тоесть не так уж и часто

А, ну это обычно при апгрейде железа надо, тоесть не так уж и часто

ЕМНИП, у них раньше через параметры и режимы дебага включались.

Здрастите

Хоспода, нет идей о взаимодействии с toool?

Хоспода, нет идей о взаимодействии с toool?

привет, нет

у нас в рамках DEFCON локпик проходит

А кто-нибудь заморачивался обходом XSS фильтра в Bitrix?

на хабре не так давно пробегало

на сколько я знаю, на последних xss не сделать, а вот html injecion да

когда мне последний раз встречался битрикс и нужно было байпаснуть битриксовский ваф, в итоге я репортил html injection

Благодарю за наводку. Щас попробую. А то пока обойти не удалось всякими привычными штуками.