Ну почему. Это примерно как если у нас есть механизм уровней привилегий на аппаратном уровне, а мы как-то смогли его обойти. Здесь примерно тоже самое. PAC это важный механизм аппаратной защиты и его получилось обойти. Пейпер очень важный по разным причинам. Сам факт обхода PAC - тут все очевидно. Далее, удалось зареверсить эпловские чипы, про которые мы ничего не знает. Организовать side-channel атаку. При чем говорят этот чип не дает доступа к высокоточным таймерам, но им все равно удалось провернуть атаку. Далее, атака работает даже в отношении указателей в ядре - вот это уже очень важно. Потому что одно дело в юзерспейсе атаку провернуть и ROP цепочки. Другое дело, когда у тебя есть указатель в ядре, а ты сам в юзерспейсе. Это как раз прямой путь к "получить доступ к ядру ОС и даёт полный контроль над атакованным устройством". Атаке не мешают разные уровни привилегий. Модель угроз ядра строится как раз на предположении, что злоумышленник получил контроль над указателем. PAC должен нас тут защитить, а теперь получается и он не может.
Здесь речь об атаке конкретно на PAC механизм. Похожим методом, что использовался в meltdown и spectre, удалось подобрать правильные PAC значения и обойти эту защиту. Но PAC это просто механизм защиты. Само себе это ничего не дает. Просто это упрощает написание эксплоита, когда у нас на руках есть реальная уязвимость, но PAC мешает ее эксплуатировать. А под комбинацией тут имеется ввиду, что сама атака на PAC осуществляется посредством уже имеющегося бага в работе с памятью, что позволяет уже эксплуатировать уязвимость в железе, в механизме спекулятивного исполнения. Собственно, если у тебя нет бага, то нет и надобности PAC обходить. Так что в итоге смысл уязвимости просто в том, что PAC удалось обойти.
Многие баги, связанные с ручным управлением памяти, могут приводить к ROP атакам. Double free, например. Аутентификация указателей призвана быть барьером дополнительным. Баги есть и будут, их невозможно избежать в небезопасных языках, как мы это видим на практике. Кардинальное решение это сменить язык. Временное решение - огородить код вокруг, чтобы минимизировать ущерб. Stack cookies, guard pages, ASLR и прочее и прочее это ведь все тоже самое - дополнительные уровни защиты, чтобы баги в работе с памятью не приводили к реальному эксплоиту.
Дык, таракан не аналитическая же база. Конечно упрется, это OLTP база. Под каждый тип нагрузок нужно свой сторадж иметь. Хотя бы разные движки, если база позволяет. Singlestore, судя по документации, имеет сомнительную консистентность, когда в списке неподдерживаемых MySQL фич видишь foreign keys и referential integrity. А поддерживаемый уровень изоляции - read committed. Я сторадж с такими же гарантиями на какой-нить касандре смогу собрать. Хочется аналитику - кликхуаз, пожалуйста.
Давно я не знаю насколько было много энтузиазма строить это все. Сейчас быстро быстро пытаются, но станка нет. Недавно на хабре даже статья была про это как раз - завод то строится, а вот оборудования нет и самим его сделать непонятно когда получится, хотя работы вроде тоже начали. И ведь речь не только об РФ, а обо всем мире. Китай вон. У них есть все возможности, но помогло им это построить конкурента TSMC и прочим? Нет, потому что оборудование не дают по прихотити одной страны известной. А дали бы может быть мы сейчас смогли бы справиться с дефицитом производственных мощностей на современных техпроцессах. А не так, что весь мир обеспечивают самсунг и тсмц.
Чтобы конфликт вызревал, для этого нужны две стороны конфликта, которые не хотят и/или не могут друг с другом работать. Здравомыслящие ли люди по обоим сторонам - я думаю да. И да, речь совсем не про нашего соседа по границе, он тут вообще не при чем. Такое ощущение, что текущая ситуация это чья-то прихоть. Нет и это предельно очевидно. Это чуть ли не вынужденный шаг и здравомыслящим людям это понятно вполне и говорили люди с обоих стороны это очень давно. Все этого ждали, это и получили. Вопрос только, насколько дальше зайдет конфликт.
Точно также предельно очевидно, что скоро TSMC накроется медным тазом по одной известной всем причине. И США к этому сценарию пытаются готовиться, перенося себе производство, но пока не очень успешно. Даже со всеми их ресурсами и доступом к технологиям это банально очень долго.
Много лет назад было много лет назад. Сейчас ничего не продают и поднять производство на общих технологиях невозможно. Это всего лишь ответ на влажные мечты выше. Конечно было бы лучше, но мир так не работает наш.
Так текущая ситуация вполне вписывается в логику здравомыслящих людей. Геополитически все вполне себе логично и давно просматривалось. И к этому как раз стоило и можно было готовиться, конфликт назревал уже многие многие годы. Собственно, я не удивлюсь, если все потуги импортозамещения, хайпа эльбрусов и т.д. были направлены именно на подготовку к этому. Мне так же вполне очевидно, что к текущей ситуации готовились давно.
Видимо копипаста с 80 ядерной версии. Там 32МБ как раз. А вот SLC называть L3 - тут я даже не знаю, насколько это технически неправильно. Чисто формально, это 3 уровень кэширования. Эксклюзивный кэш это вполне себе традиционная стратегия кэширования.
Смысл работы в том, что в выключенном режиме айфоны держат включенными кучу беспроводных чипов. На них крутится постоянно какой-то код, и он может делать что угодно. Это еще один вектор атаки. Предыдущий вектор основной заключался в эмуляции выключенного телефона, но AP процессор оставался активным. Это жрет слишком много энергии и палевно. Тут же получается AP выключен, а все остальное в режиме энергосбережения и человек этого даже не знает. Далее, современные айфоны имеют bluetooth чипы без secure boot - прошивки без подписи и без шифрования. К тому же, поддерживаются команды по патчингу кода прямо в рилтайме - память в bluetooth чипе доступна одновременно и для записи, и для выполнения. Это не говоря о том, что постоянно работающий NFC, bluetooth, UWB позволяют атаковать телефон в выключенном состоянии и залить туда эксплоит. Так что таки и "через Bluetooth" в том числе.
Выводы здесь не в том, что jail надо делать и все сложно. Вывод в том, что поверхность атаки намного шире нынче и людям, которые волнуются за прослушку, теперь недостаточно просто убедиться, что телефон выключен. Надо еще либо сниффер ставить беспроводной связи, либо класть трубку в клетку фарадея. И все это слабо документировано Apple.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
virt-launcher-vm-4sd8h 1/1 Running 0 2d13h
$ kubectl exec -it virt-launcher-vm-4sd8h -- bash
bash-5.0# virsh list
Id Name State
1 default_vm running
Т.е. для хоста это обычные виртуалки. По сути, это прямо как Vsphere/proxmox кластер получается. Просто контрол плейном выступает кубер в связке с kubevirt.
Это HCI, т.е. это комплексное решение для развертывания разных нагрузок - и виртуальных, и контейнерных. Это business-talk, так сказать. Технически, это просто обычный кубер с прикрученным kubevirt, уже выбранным за тебя распределенным хранилищем, CNI и прочими плюшками. По сути, все тоже самое можно собрать руками спокойно за исключением наверное только web-ui. Кубер это конструктор и каждый из него собирает свое.
С учетом, что bankoff дает визу зарубежную и с нее никак не забрать деньги, т.к. прямые переводы с банками РФ не работают, то первая цель здесь не подходит. Bankoff в первую очередь нужен для вывода денег из РФ и оплаты западных сервисов.
Так что здесь видятся исключительно репутационные риски визы и страйпа.
Статья какой-то лютый бред. Ванильный постгре, никаких кастомных конфигов и надстроек, statefulset, 2 реплики, раздельный сторадж. Это что вообще и как? В итоге запустилось два постгре совершенно независимых и никак не связанных. Зачем это нужно? Statefulset не превратит постгре магическим образом в HA базу.
Нежелание ткать базу в кубер это уже больше устаревшие предрассудки. Особенно в свете наличия всяких разных HA cloud-native реализаций. Если у вас сетевой сторадж, то пофиг вообще где база запущена, в кубере или нет. Точно так же iscsi/ceph/gluster цепляете и вперед. Можно базу прибить к ноде, если там какой-то хитрый сторадж. Главный профит от контейнера - унификация окружения. Добавлять в этот микс виртуалки себе дороже. Если уж поднимать взрослый инстанс базы, то брать под это отдельную железку с четко подобранные компонентами, настроенным ядром и т.д.
В случае субд контейнерной в swarm или кубернетес следует указывать конкретную ноду, на которой будет произведён запуск контейнера. Иначе тома не будет, в случае запуска на произвольной норде.
Все зависит от storage класса. Кубер просто не запустит под, если он не сможет подцепить том. Если том какой-нить localpath, который сам по себе всегда прибит к ноде, то пока это нода лежит, поды тоже будут лежать и ждать своего часа. А ежели это ceph и прочие облачные стораджи, то спокойно подцепит том с любой ноды, т.к. том сам по себе сетевой. Ваша ситуация может произойти в случае использования hostpath. Там да, под может оказаться на любой ноде и можно попасть в забавную ситуацию, когда внезапно все данные из базы пропали. Просто потому что под мигрировал на другую ноду и запустился с пустым хранилищем.
Вот про две реплики действительно непонятно. В итоге получаются два постгре, которые друг про друга ничего не знают. У них свои независимые вольюмы.
Ну почему. Это примерно как если у нас есть механизм уровней привилегий на аппаратном уровне, а мы как-то смогли его обойти. Здесь примерно тоже самое. PAC это важный механизм аппаратной защиты и его получилось обойти. Пейпер очень важный по разным причинам. Сам факт обхода PAC - тут все очевидно. Далее, удалось зареверсить эпловские чипы, про которые мы ничего не знает. Организовать side-channel атаку. При чем говорят этот чип не дает доступа к высокоточным таймерам, но им все равно удалось провернуть атаку. Далее, атака работает даже в отношении указателей в ядре - вот это уже очень важно. Потому что одно дело в юзерспейсе атаку провернуть и ROP цепочки. Другое дело, когда у тебя есть указатель в ядре, а ты сам в юзерспейсе. Это как раз прямой путь к "получить доступ к ядру ОС и даёт полный контроль над атакованным устройством". Атаке не мешают разные уровни привилегий. Модель угроз ядра строится как раз на предположении, что злоумышленник получил контроль над указателем. PAC должен нас тут защитить, а теперь получается и он не может.
Здесь речь об атаке конкретно на PAC механизм. Похожим методом, что использовался в meltdown и spectre, удалось подобрать правильные PAC значения и обойти эту защиту. Но PAC это просто механизм защиты. Само себе это ничего не дает. Просто это упрощает написание эксплоита, когда у нас на руках есть реальная уязвимость, но PAC мешает ее эксплуатировать. А под комбинацией тут имеется ввиду, что сама атака на PAC осуществляется посредством уже имеющегося бага в работе с памятью, что позволяет уже эксплуатировать уязвимость в железе, в механизме спекулятивного исполнения. Собственно, если у тебя нет бага, то нет и надобности PAC обходить. Так что в итоге смысл уязвимости просто в том, что PAC удалось обойти.
Многие баги, связанные с ручным управлением памяти, могут приводить к ROP атакам. Double free, например. Аутентификация указателей призвана быть барьером дополнительным. Баги есть и будут, их невозможно избежать в небезопасных языках, как мы это видим на практике. Кардинальное решение это сменить язык. Временное решение - огородить код вокруг, чтобы минимизировать ущерб. Stack cookies, guard pages, ASLR и прочее и прочее это ведь все тоже самое - дополнительные уровни защиты, чтобы баги в работе с памятью не приводили к реальному эксплоиту.
Может с помощью вот этого https://github.com/argoproj-labs/argocd-vault-plugin Из всех решений выглядит как наиболее простое и прозрачное
Дык, таракан не аналитическая же база. Конечно упрется, это OLTP база. Под каждый тип нагрузок нужно свой сторадж иметь. Хотя бы разные движки, если база позволяет. Singlestore, судя по документации, имеет сомнительную консистентность, когда в списке неподдерживаемых MySQL фич видишь foreign keys и referential integrity. А поддерживаемый уровень изоляции - read committed. Я сторадж с такими же гарантиями на какой-нить касандре смогу собрать. Хочется аналитику - кликхуаз, пожалуйста.
Давно я не знаю насколько было много энтузиазма строить это все. Сейчас быстро быстро пытаются, но станка нет. Недавно на хабре даже статья была про это как раз - завод то строится, а вот оборудования нет и самим его сделать непонятно когда получится, хотя работы вроде тоже начали. И ведь речь не только об РФ, а обо всем мире. Китай вон. У них есть все возможности, но помогло им это построить конкурента TSMC и прочим? Нет, потому что оборудование не дают по прихотити одной страны известной. А дали бы может быть мы сейчас смогли бы справиться с дефицитом производственных мощностей на современных техпроцессах. А не так, что весь мир обеспечивают самсунг и тсмц.
Чтобы конфликт вызревал, для этого нужны две стороны конфликта, которые не хотят и/или не могут друг с другом работать. Здравомыслящие ли люди по обоим сторонам - я думаю да. И да, речь совсем не про нашего соседа по границе, он тут вообще не при чем. Такое ощущение, что текущая ситуация это чья-то прихоть. Нет и это предельно очевидно. Это чуть ли не вынужденный шаг и здравомыслящим людям это понятно вполне и говорили люди с обоих стороны это очень давно. Все этого ждали, это и получили. Вопрос только, насколько дальше зайдет конфликт.
Точно также предельно очевидно, что скоро TSMC накроется медным тазом по одной известной всем причине. И США к этому сценарию пытаются готовиться, перенося себе производство, но пока не очень успешно. Даже со всеми их ресурсами и доступом к технологиям это банально очень долго.
Много лет назад было много лет назад. Сейчас ничего не продают и поднять производство на общих технологиях невозможно. Это всего лишь ответ на влажные мечты выше. Конечно было бы лучше, но мир так не работает наш.
Было бы, но наши соседи так не хотят. Иначе бы у всех давно было по станку ASML.
Так текущая ситуация вполне вписывается в логику здравомыслящих людей. Геополитически все вполне себе логично и давно просматривалось. И к этому как раз стоило и можно было готовиться, конфликт назревал уже многие многие годы. Собственно, я не удивлюсь, если все потуги импортозамещения, хайпа эльбрусов и т.д. были направлены именно на подготовку к этому. Мне так же вполне очевидно, что к текущей ситуации готовились давно.
Видимо копипаста с 80 ядерной версии. Там 32МБ как раз. А вот SLC называть L3 - тут я даже не знаю, насколько это технически неправильно. Чисто формально, это 3 уровень кэширования. Эксклюзивный кэш это вполне себе традиционная стратегия кэширования.
Да. Даже если телефон ушел в разряд и сам выключился, чипы все равно активируются и работают в режиме низкого энергопотребления.
Смысл работы в том, что в выключенном режиме айфоны держат включенными кучу беспроводных чипов. На них крутится постоянно какой-то код, и он может делать что угодно. Это еще один вектор атаки. Предыдущий вектор основной заключался в эмуляции выключенного телефона, но AP процессор оставался активным. Это жрет слишком много энергии и палевно. Тут же получается AP выключен, а все остальное в режиме энергосбережения и человек этого даже не знает. Далее, современные айфоны имеют bluetooth чипы без secure boot - прошивки без подписи и без шифрования. К тому же, поддерживаются команды по патчингу кода прямо в рилтайме - память в bluetooth чипе доступна одновременно и для записи, и для выполнения. Это не говоря о том, что постоянно работающий NFC, bluetooth, UWB позволяют атаковать телефон в выключенном состоянии и залить туда эксплоит. Так что таки и "через Bluetooth" в том числе.
Выводы здесь не в том, что jail надо делать и все сложно. Вывод в том, что поверхность атаки намного шире нынче и людям, которые волнуются за прослушку, теперь недостаточно просто убедиться, что телефон выключен. Надо еще либо сниффер ставить беспроводной связи, либо класть трубку в клетку фарадея. И все это слабо документировано Apple.
Судя по коду, kubevirt работает через /dev/kvm Плюс вот это https://gist.github.com/zulhfreelancer/1ce85228499e69e1c707855bbbda1092
Т.е. для хоста это обычные виртуалки. По сути, это прямо как Vsphere/proxmox кластер получается. Просто контрол плейном выступает кубер в связке с kubevirt.
Это HCI, т.е. это комплексное решение для развертывания разных нагрузок - и виртуальных, и контейнерных. Это business-talk, так сказать. Технически, это просто обычный кубер с прикрученным kubevirt, уже выбранным за тебя распределенным хранилищем, CNI и прочими плюшками. По сути, все тоже самое можно собрать руками спокойно за исключением наверное только web-ui. Кубер это конструктор и каждый из него собирает свое.
С учетом, что bankoff дает визу зарубежную и с нее никак не забрать деньги, т.к. прямые переводы с банками РФ не работают, то первая цель здесь не подходит. Bankoff в первую очередь нужен для вывода денег из РФ и оплаты западных сервисов.
Так что здесь видятся исключительно репутационные риски визы и страйпа.
Статья какой-то лютый бред. Ванильный постгре, никаких кастомных конфигов и надстроек, statefulset, 2 реплики, раздельный сторадж. Это что вообще и как? В итоге запустилось два постгре совершенно независимых и никак не связанных. Зачем это нужно? Statefulset не превратит постгре магическим образом в HA базу.
Нежелание ткать базу в кубер это уже больше устаревшие предрассудки. Особенно в свете наличия всяких разных HA cloud-native реализаций. Если у вас сетевой сторадж, то пофиг вообще где база запущена, в кубере или нет. Точно так же iscsi/ceph/gluster цепляете и вперед. Можно базу прибить к ноде, если там какой-то хитрый сторадж. Главный профит от контейнера - унификация окружения. Добавлять в этот микс виртуалки себе дороже. Если уж поднимать взрослый инстанс базы, то брать под это отдельную железку с четко подобранные компонентами, настроенным ядром и т.д.
Все зависит от storage класса. Кубер просто не запустит под, если он не сможет подцепить том. Если том какой-нить localpath, который сам по себе всегда прибит к ноде, то пока это нода лежит, поды тоже будут лежать и ждать своего часа. А ежели это ceph и прочие облачные стораджи, то спокойно подцепит том с любой ноды, т.к. том сам по себе сетевой. Ваша ситуация может произойти в случае использования hostpath. Там да, под может оказаться на любой ноде и можно попасть в забавную ситуацию, когда внезапно все данные из базы пропали. Просто потому что под мигрировал на другую ноду и запустился с пустым хранилищем.
Вот про две реплики действительно непонятно. В итоге получаются два постгре, которые друг про друга ничего не знают. У них свои независимые вольюмы.
Просто в статье я вижу два хоста и никакого кворума. Как это вообще может работать надежно?