Ну, гигабайт — далеко не вся память. И опять же это может зависеть от ОС. Замапленная память ядра — понятно зачем нужно, чтобы не переключать карту памяти для большинства системных вызовов, и если её убрать — действительно понизится быстродействие. И поэтому скорее всего так будет сделано по умолчанию во всех вменяемых современных ОС (до того, как привлекли внимание к обсуждаемой особености процов). Замапаленная просто рандомная (или вообще вся) физическая память — просто небольшое удобство и на быстродействие почти не влияет.
as well as the entire kernel space, which typically also has all physical memory (in-use) mapped
видимо это нововведение 64-битных ядер (т.е. зависит от ОС, и не указано какой ОС, в каких-то этого может и не быть), из-за которого красть данные теперь можно не только из ядра, но и из соседних процессов (которые теперь там тоже выставлены на обозрение) тоже. Хорошо у меня 32-битное ядро хоть и на 64-бит проце.
Уже выложили https://spectreattack.com/spectre.pdf
Как я понял это баг не совсем в конкретной реализации, а в самой идее предсказания ветвлений и предварительной подготовки к выполнению будущих инструкций, считая чтение операцией, не меняющей состояние (а она давно не такая из-за кеща). Если там всё по-честному проверять — предсказание ветвлений будет иметь гораздо меньше смысла. Если нет — получается вот такой read-only доступ куда не следует.
И эти заплатки с изоляцией системной памяти от чего-то защитят, но всё равно могут оставить дыру в эксплуатации особенностей исполнения ядерного кода (в нём то ядерная память доступна и могут непреднамеренно быть конструкции, использующиеся в эксплойте с входными данными от юзера — когда его писали никто про такое не думал, да и даже зная о такой "особенности" сложно это предусмотреть везде).
Но не всё так плохо. Получить доступ на чтение к ядерной памяти тут относительно легко, а вот к памяти соседнего процесса — намного сложнее, если вообще возможно (как описанным в статье способом так и тем вторым, что останется после этих заплаток). А важные данные типа паролей/ключей хранятся как раз обычно в памяти процессов, а не в ядре.
FreeBSD jails всё тоже самое умели ещё давным давно. Ну или почти тоже самое, без красивой обёртки. Но мы не будем пользоваться нормальной серверной системой, а лучше прикрутим очередной костыль к их нагромождению.
Нет, тут (и не только тут) так нельзя. Нельзя написать в договоре что захочешь и потом им отмахиваться от претензий. Если договор (в данном случае — ваша "политика обработки") противоречит законам, то он признаётся недействительным, и не только галочка, но и реальная нотариально заверенная подпись контрагента под ним не будет значить совершенно ничего.
Её и не было. Это всегда было семантическим выделением группы тегов, не рисующих ничего не странице, для удобства тех кто их пишет/читает (людей, не браузера). Браузеры его всегда, вроде бы, игнорировали, так же как и <html> и <body> (но не игнорировали аргументы этих тегов).
Проблема в железе, да. Но конкретно эта проблема есть наверно уже 20 лет (когда там биос на флеш с программной неотключаемой перезаписью стали хранить?). Вирусы, затирающие биос, уже были в 90х, но исходную уязвимость никто и не думал исправлять с тех пор. https://ru.wikipedia.org/wiki/CIH
То, что старые валидаторы не ругаются на устаревшие атрибуты при устаревших доктайпах — не показатель.
Не показатель чего?
Для браузеров это всё равно будет неправильный HTML5
Всё же, если браузер неправильно отображает старую страницу, которая раньше отображалась правильно, то неправильный тут всё-таки браузер. А страница — не "неправильный html5" а вообще не html5, а, может быть например, правильный html3.2.
Зачем? Если вам важен смысл этого тега то и так и так придётся узнавать о нём. Если вы его просто где-то увидели случайно — игнорируйте и его и его закрывающий вариант, как будто он там не написан (как и делают браузеры с неизвестными тегами).
у меня всё прекрасно инкрементально парсилось
Ну вот EvilFox утверждал обратное по сути, я ему поверил. Может быть это не проблема самого парсера а проблема его интеграции в браузер, но сути это не меняет.
О том, что задачу пытаются впихнуть в рамки какого-то "инструмента" общего назначения (не говоря уже о том, что этот "инструмент" сам по себе плохой).
Парсер html хотят убрать и вставить вместо него парсер xml. Но xml-парсеры не знают о том, что тег <br> одиночный — давайте им в угоду его изуродуем в <br />. Xml-парсеры испытывают проблемы с инкрементальным парсингом исходника — ничего, подождёте пока страница догрузится, инет ведь быстрый. Не надо таких "оптимизаций".
Не раз видел аналогичные истоиии (но в локальном масштабе): а вот у нас тут супер модная технология, давайте её внедрим. Правда она не поддерживает некоторые удобные фичи (которые у нас УЖЕ есть), придётся их убрать, но это всё мелочи.
Чем он более дыра, чем <script src="">? Если я правильно понял, то это примерно то же самое, но с возможностью отложенной загрузки и проверкой на дублирование урла.
В Москве на самих остановках пишется сколько времени осталось до автобуса/троллейбуса/трамвая. И обычно более менее правильно. По-моему это намного лучший вариант чем сувать всё это на какие-то сайты. Правда, в сожалению, по диагностическим надписям на этих табло видно что они скорее всего всё же используют инфраструктуру интернета для своей работы.
Вообще в линуксах принято все нужные прошивки делать в рантайме по мере запуска компа или обнаружения соответствующих устройств, и не сохранять из в долговременной памяти (кроме файловой системы на диске), т.е. они слетают при перезапуске компа и заново прошиваются на старте системы. Микрокод проца в том числе.
Давайте вообще импорт продуктов питания запретим тогда.
Я понимаю что это сказано с сарказмом, но всё же, если убавить в этой фразе категоричности (не "запретить всё" а заметно ограничить) то это хорошая идея.
Я может быть не там смотрю, но по ссылке я вижу главным образом обсуждение сходств/различий между браузерами, а на втором плане — желание отразить реальность в стандарте и какие-то предложения насчёт max-width. Предложения про аналог max-column-width я там не вижу.
Ну, гигабайт — далеко не вся память. И опять же это может зависеть от ОС. Замапленная память ядра — понятно зачем нужно, чтобы не переключать карту памяти для большинства системных вызовов, и если её убрать — действительно понизится быстродействие. И поэтому скорее всего так будет сделано по умолчанию во всех вменяемых современных ОС (до того, как привлекли внимание к обсуждаемой особености процов). Замапаленная просто рандомная (или вообще вся) физическая память — просто небольшое удобство и на быстродействие почти не влияет.
А, упустил деталь
тут https://meltdownattack.com/meltdown.pdf написано
видимо это нововведение 64-битных ядер (т.е. зависит от ОС, и не указано какой ОС, в каких-то этого может и не быть), из-за которого красть данные теперь можно не только из ядра, но и из соседних процессов (которые теперь там тоже выставлены на обозрение) тоже. Хорошо у меня 32-битное ядро хоть и на 64-бит проце.
Уже выложили https://spectreattack.com/spectre.pdf
Как я понял это баг не совсем в конкретной реализации, а в самой идее предсказания ветвлений и предварительной подготовки к выполнению будущих инструкций, считая чтение операцией, не меняющей состояние (а она давно не такая из-за кеща). Если там всё по-честному проверять — предсказание ветвлений будет иметь гораздо меньше смысла. Если нет — получается вот такой read-only доступ куда не следует.
И эти заплатки с изоляцией системной памяти от чего-то защитят, но всё равно могут оставить дыру в эксплуатации особенностей исполнения ядерного кода (в нём то ядерная память доступна и могут непреднамеренно быть конструкции, использующиеся в эксплойте с входными данными от юзера — когда его писали никто про такое не думал, да и даже зная о такой "особенности" сложно это предусмотреть везде).
Но не всё так плохо. Получить доступ на чтение к ядерной памяти тут относительно легко, а вот к памяти соседнего процесса — намного сложнее, если вообще возможно (как описанным в статье способом так и тем вторым, что останется после этих заплаток). А важные данные типа паролей/ключей хранятся как раз обычно в памяти процессов, а не в ядре.
FreeBSD jails всё тоже самое умели ещё давным давно. Ну или почти тоже самое, без красивой обёртки. Но мы не будем пользоваться нормальной серверной системой, а лучше прикрутим очередной костыль к их нагромождению.
Нет, тут (и не только тут) так нельзя. Нельзя написать в договоре что захочешь и потом им отмахиваться от претензий. Если договор (в данном случае — ваша "политика обработки") противоречит законам, то он признаётся недействительным, и не только галочка, но и реальная нотариально заверенная подпись контрагента под ним не будет значить совершенно ничего.
А конкретнее? Имеется ввиду с одобрения/заказа владельцев того сайта, но api они не дали?
Её и не было. Это всегда было семантическим выделением группы тегов, не рисующих ничего не странице, для удобства тех кто их пишет/читает (людей, не браузера). Браузеры его всегда, вроде бы, игнорировали, так же как и <html> и <body> (но не игнорировали аргументы этих тегов).
Проблема в железе, да. Но конкретно эта проблема есть наверно уже 20 лет (когда там биос на флеш с программной неотключаемой перезаписью стали хранить?). Вирусы, затирающие биос, уже были в 90х, но исходную уязвимость никто и не думал исправлять с тех пор. https://ru.wikipedia.org/wiki/CIH
Отучением от инстаграма наверно скоро займётся РКН. А в частном порядке подобные действия и правда чреваты потерей клиентов, как уже написали.
Не показатель чего?
Всё же, если браузер неправильно отображает старую страницу, которая раньше отображалась правильно, то неправильный тут всё-таки браузер. А страница — не "неправильный html5" а вообще не html5, а, может быть например, правильный html3.2.
Плохо.
Зачем? Если вам важен смысл этого тега то и так и так придётся узнавать о нём. Если вы его просто где-то увидели случайно — игнорируйте и его и его закрывающий вариант, как будто он там не написан (как и делают браузеры с неизвестными тегами).
Ну вот EvilFox утверждал обратное по сути, я ему поверил. Может быть это не проблема самого парсера а проблема его интеграции в браузер, но сути это не меняет.
О том, что задачу пытаются впихнуть в рамки какого-то "инструмента" общего назначения (не говоря уже о том, что этот "инструмент" сам по себе плохой).
Парсер html хотят убрать и вставить вместо него парсер xml. Но xml-парсеры не знают о том, что тег <br> одиночный — давайте им в угоду его изуродуем в <br />. Xml-парсеры испытывают проблемы с инкрементальным парсингом исходника — ничего, подождёте пока страница догрузится, инет ведь быстрый. Не надо таких "оптимизаций".
Не раз видел аналогичные истоиии (но в локальном масштабе): а вот у нас тут супер модная технология, давайте её внедрим. Правда она не поддерживает некоторые удобные фичи (которые у нас УЖЕ есть), придётся их убрать, но это всё мелочи.
Лично я рад что его закопали. Вся эта xml-ная гадость в html-коде (впрочем, и не только в нём) раздражает.
Чем он более дыра, чем <script src="">? Если я правильно понял, то это примерно то же самое, но с возможностью отложенной загрузки и проверкой на дублирование урла.
В Москве на самих остановках пишется сколько времени осталось до автобуса/троллейбуса/трамвая. И обычно более менее правильно. По-моему это намного лучший вариант чем сувать всё это на какие-то сайты. Правда, в сожалению, по диагностическим надписям на этих табло видно что они скорее всего всё же используют инфраструктуру интернета для своей работы.
Вообще в линуксах принято все нужные прошивки делать в рантайме по мере запуска компа или обнаружения соответствующих устройств, и не сохранять из в долговременной памяти (кроме файловой системы на диске), т.е. они слетают при перезапуске компа и заново прошиваются на старте системы. Микрокод проца в том числе.
Хотя возможно я "отстал" и всё уже испортили.
Я понимаю что это сказано с сарказмом, но всё же, если убавить в этой фразе категоричности (не "запретить всё" а заметно ограничить) то это хорошая идея.
С чего это?
Не надо, мне будет лень.
Я может быть не там смотрю, но по ссылке я вижу главным образом обсуждение сходств/различий между браузерами, а на втором плане — желание отразить реальность в стандарте и какие-то предложения насчёт max-width. Предложения про аналог max-column-width я там не вижу.