Акела промахнулся! В смысле, Интел обосрался

[Flash-04]

Почему не обсуждаем?
Я уже представил, что будет если на работе все будет на 30% медленнее...

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

Я давно забиваю всем в голову, что НЕЛЬЗЯ ВЕРИТЬ РАЗДЕЛЕНИЮ ЮЗЕРОВ. Верить можно только разделению VM да и то аккуратно. А так, если есть юзер А, то что в винде что в линуксе считаем что он РУТ. И дело в шляпе. Пусть хоть уписается и всю память кернела прочитает, он и так ее может через /proc читать, ничего это ему не даст.

А так конечно дырка красивая. Бесполезная но красивая.

Здрасьте, ещё как тащится. POC в тырнете в избытке.

[helg]

https://www.engadget.com/2018/01/09/mic ... d-patches/

Microsoft выпустила обновление для meltdown. Означенное обновление предсказуемо кирпичизирует материнки с AMD. Microsoft говорит, что у них в Microsoft всё работает, а виновата AMD. Но проталкивание обновления таки остановили.

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

[helg]

,

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

Да без проблем можно читать память друго процесса (под тем же юзером).
Даже код свой можно исполнять в адресном пространстве другого процесса.

https://msdn.microsoft.com/en-us/librar ... s.85).aspx

Во-первых, этой функцией запускается не "свой" код, а тот, который присутствует в адресном пространстве "чужого" процесса. Во-вторых, для получения дескриптора с требуемой привилегией PROCESS_CREATE_THREAD требуются права отладчика, которых может и не быть. А в-третьих, система безопасности в Windows претерпевает кардинальные изменения с каждой новой версией - и это как-то не внушает к ней доверия.

[helg]

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

Да верно, надо быть админом.

В нормальных ОС не нужны вызовы этих многоэтажных монстров и ворох мутных привилегий. Можно читать-писать файл /proc/${PID}/mem

[zVlad]

По IBM Power Family появилась свежая информация:

https://www.ibm.com/blogs/psirt/potenti ... er-family/

[zVlad]

По IBM System z тоже есть инфа в свтази с темой. Привожу ее полностью потому что нужен доступ к IBM ResourceLink (не у всех он есть):

Summary
Google has announced a wide-spread CPU architectural issue potentially impacting system security. More information can be found in Google's disclosure https://security.googleblog.com/2018/01 ... -need.html

Our engineering teams are working to determine resolutions to any potential impact. Affected IBM Z product information and mitigation approaches will be issued through this portal as soon as possible.
The most immediate action clients can take to protect themselves is to prevent execution of untrusted software on any system. Clients are always advised to follow good security practices.

This security notice will be updated as more information becomes available.

Details
in order to leverage this vulnerability, a person must have the ability and authorization to run their code on the target system. Secure engineering practices for code development and deployment, when in place, offer a significant control point for activity of this type and the IBM Z team stands ready to provide advice and best practice recommendations in this area. The nature of the exposure varies depending upon the variant type and the operating system environment. IBM Z is working on mitigations, where appropriate for affected z environments.

The z machine generations potentially affected by these vulnerabilities, depending upon operating system deployed are:

z196 / z114
zEC12 / zBC12
z13 / z13s
z14
LinuxONE models Rockhopper, Emperor and Emperor II


Operating System environments affected are:

Linux on z
z/VM
z/OS


Operating system environments unaffected are:

z/TPF
z/VSE


Mitigations may include firmware and operating system updates. Mitigations for Linux and z/VM will be available on January 9th. Further mitigation details for z/OS will be released as they become available.

Ecosystem components not affected:

Mainframes prior to z196
All models of Hardware Master Console (HMC)
All models of Service Element (SE)
All models of Trusted Key Entry (TKE)
Coupling Facility (CF)

Remediation

General Comments:
.... убрано за ненадобности и экономии места и времени для чтения.....

z/VM:
The Meltdown (CVE 2017-5754) variant is not a concern for z/VM.

z/VM 6.4 Security APAR VM65396 (PTF UM34851) will be made available via the normal service process
to mitigate Spectre variants 1 & 2 (CVE-2017-5715 & CVE-2017-5753). Some performance degradation is likely as a result of applying this fix. Therefore, IBM strongly recommends first applying the PTF in a test environment to help understand any potential impact on your workload. A z/VM system that IPLs with the PTF applied will enable protection to mitigate variant 1 by default. The PTF adds a new CP command, SET SPECEX, that can enable additional mitigation for variant 2. The command has system wide options and userid (virtual machine) specific settings. The z/VM help files have been updated to reflect this new command.

The z/VM PTF has dependencies on the installation of the MCL, and therefore the MCLs are a perquisite as described below. IBM strongly recommends that the MCL be applied prior to the z/VM PTF to avoid a second IPL of the z/VM System. (See the Machine Microcode section for information based on your IBM Z or LinuxONE server.) Any performance impact will be dependent on the workload and enablement settings. As described below, there will likely be a moderate processor time increase after applying the PTF and a larger increase when SPECEX is set off (i.e. the protection is enabled). IBM strongly recommends that you do performance testing at the various settings that could impact performance prior to putting this into production. Testing variations should include various settings for SET SPECEX and guest patch settings.

When installing the PTF on production systems, you should consider using SSI and LGR to help avoid system wide application outages. It is also possible, based on your security evaluation, to run different members of an SSI cluster with different settings. For example, you could place your most critical workloads on a member of the SSI cluster with all the new mitigations enabled.

Machine Microcode:
All MCL code can be installed and activated concurrently. MCLs updates will be made available via normal service process.

Fix MCLs to mitigate Spectre

· Driver 32 MCL 068 in ECStream P42604 Bundle S20 (This fix addresses all models of z14 including LinuxONE Emperor II )
· Driver 27 MCL 075 in ECStream P08414 Bundle S62 (This fix addresses all models of z13, z13s, including LinuxONE Emperor and LinuxONE Rockhopper)
· Driver 15 MCL 103 in ECStream H49561 Bundle 84 (This fix addresses all models of zEC12, zBC12)
· MCLs for z196 and z114 are planned.


Notes:
Application of these MCLs without applying the applicable operating system software PTFs is recommended but will not provide mitigation for Spectre unless the applicable operating software PTFs are also installed.
Application of these MCLs without applying operating system software PTFs will not have an impact on system performance.
Application of both the MCLs and application of the applicable operating system software PTFs are required to mitigate Spectre.

Don’t understand what further details.

Linux:
The Meltdown (CVE 2017-5754) variant is not a concern for Linux on Z and LinuxONE.

Please consult your Linux distribution partner of choice (Red Hat, SUSE, Canonical) to determine if they have made any information and any Linux OS patches available to mitigate Spectre and you have applied all applicable patches. Dependent on workload, there are likely to be performance impacts after applying these patches. IBM strongly recommends you conduct performance tests with your workload on a test system before applying the patches to a production environment.

The Linux patches have dependencies on the MCL fix for Spectre as described above and must also be installed for mitigation. The MCLs are a prerequisite to the installation of any Linux OS patches. It is recommended that MCL fixes be applied prior the Linux OS patches being applied.

Performance Statement:
We strongly encourage clients to independently test in a nonproduction environment their systems to determine the level of performance impact that will be experienced after 1) applying the VM APAR (VM65396) and corresponding MCL, then 2) changing the setting of SPECEX to disable speculative execution for either the entire z/VM system or a subset of guest servers.

The z/VM PTFs for Spectre will likely cause some performance implications (z/VM is not exposed to Meltdown). After applying the PTF and MCL, z/VM will likely see a moderate performance impact due to mitigation for Spectre Variant #1. Setting SPECEX OFF to disable speculative execution is the mitigation for Spectre Variant #2 and will likely have additional larger performance implications.

The impact of enabling the z/VM and Linux mitigations may be greater when multithreading (MT-2) is in use in the partition.

Test Considerations:
A key factor impacting performance from a z/VM perspective is the higher the z/VM CP portion of processor time in a workload, the greater the increase in overall processor time. Some performance products show this as the Total to Virtual Ratio (T/V Ratio). In Performance Toolkit for z/VM on the SYSSUM (FCX225) report, you will see "T/V" shown over time. In testing, you should use a test environment that has a similar T/V Ratio as your production environment.

Similar to z/VM, applying the Linux patch in conjunction with the MCL will likely cause a small performance impact by default and a larger impact if fully enabled. The key factor is the higher the Linux kernel portion of processor time in a workload, the greater the increase in overall processor time. There could also be distribution dependencies, so check with your Linux distributor.

[zVlad]

Пока что все для IBM System z крутится вокруг zVM и Linux.
К сожалению я не смог найти деталей z/VM APAR VM65396 (не опубликован пока на IBM ServiceLink, хотя PTF UM34851 доступен. Завтра может появиться, или на дных).
Нет также деталей про микрокодe upgrade. По крайней мере очевидно что все три находки адресуются без необходимости ждать новых zCPU - фиксится на уровне микрокода.

[zVlad]

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

http://www.oracle.com/us/solutions/benc ... 67486.html

Например эта пара:
http://www.oracle.com/us/solutions/benc ... 502957.pdf
http://www.oracle.com/us/solutions/benc ... 497509.pdf

Небольшой (!) мидрейнжевый сервер оказался почти в два раза быстрее, при этом загрузка ЦП была в два раза ниже (Он почти линейно масштабируется по процессору на разных задачах до упора. Их в хозяйстве было много.) Обычный честный batch.

Цена Т4-4 на тот момент меньше 100к.
Если верить прайсу выше, то аналогичный z 2097-709 1Q 08 $6,141,671 . Пусть IBM сторгуется в 3 раза, но это всё равно в 20 раз дороже.

Там еще есть одни и те же тесты на базе обычных Intel и Z.

Эти тесты я несколько лет назад здесь подробно анализировал и показывал что в них не так. Если коротко, то, несмотря на IBM logo, ibm-овцев создатели этих тестов не приглашали и оптимизацию на МФ никакую, даже элементарную, не проводили.
Сами IBM никаких подобных тестов не проводят, понимая и обясняя что это контрпродуктивно в принципе.
У нас есть mainframe с 1 (одним) процессором/кором производительностью в 20 с лишним раз, искусственно, заниженой (50 MIPS) относительно максимальной производительность одного же процессора с полной, не заниженной, мощностью (1064 MIPS).
На этом МФ выполняется три (было четыре) системы zOS. Одна выполняет Production приложение (база данных, монитор транзакций, бизнес логика), другая - Dev, QA этого же приложения. Третья система - Sandbox для системщиков, где мы тестируем новые патчи и просто играемся. С этим MF работает некоторое количество пользователе, программисты, операторы. Этот же MF управляет централизованно всеми batch jobs на наших Wintel, Linux, и Unix серверах - сотни если не тысячи серверов.

Может этa информация Вам даст представление о безотносительности найденых Вами тестов к реальности. Можно и так сказать что те тесты были построены чтобы таким как Вы показать насколько МФ дороги и слабы, Т4-4 хорош и дешев. Хотите им верить - верьте на здоровье. Мой многолетний опыт работы с МФ говорит о совсем другом.

[Dmitry67]

Влад, на Луну летали еще на более крошечных мощностях. Так что все это ни о чем не говорит.

Когда вы приводили данные своих баз, выяснилось что они крошечные и на интел сервере спокойно бы поместились в кэш

[zVlad]

Влад, на Луну летали еще на более крошечных мощностях. Так что все это ни о чем не говорит.

Когда вы приводили данные своих баз, выяснилось что они крошечные и на интел сервере спокойно бы поместились в кэш

Уже много лет это приложение пытаются перевести на Intel сервер в MS SQL. Я даже видел базу данных созданную на одном из серверов. И это было бы очень правильно потому что держать такой маленький МФ совершенно нецелесообразно. Но годы проходят и клиент снова и снова покупает отдельный МФ под это приложение. Может девелоперы тупят, может еще что - я не знаю. Говорят есть готовые аналоги этой функциональности. Что с ними проблематично я тоже не заню.
Боле того, и я об этом тоже писал здесь, было у нас два клиента этого приложения. Так вот один ушел пару лет назад от нас.... но тоже остался на МФ, который арендовал где-то в другом месте. Вот такая, Дима, фигня происходит в жизни порой. Казалось бы из-за цены уже много лет назад должны были соскочить, но есть видимо другие обстоятельства, более важные. С технической точки зрения это приложение ничего особeнного чтобы использовать МФ не представляет - учет проводов и кабелей.

[zVlad]

Влад, на Луну летали еще на более крошечных мощностях. ....

Кстати про Луну и крошечные мощности. Когда в СССР делали ПРО (на границе 50х-60х), то там были машины и перефирия по мощности превышающие то чего в ЕС ЭВМ достигли к концу 70 может быть. Это были секретные разработки - только для ПРО, но они были. Возможно те машины (и многомашинные комплексы с мультупроцессированием) были мощнее американских тоже.

[mskmel]

Если коротко, то, несмотря на IBM logo, ibm-овцев создатели этих тестов не приглашали и оптимизацию на МФ никакую, даже элементарную, не проводили.

А не противоречит ли IBM лицензии выкладывание таких тестов в паблик?

[zVlad]

Если коротко, то, несмотря на IBM logo, ibm-овцев создатели этих тестов не приглашали и оптимизацию на МФ никакую, даже элементарную, не проводили.

А не противоречит ли IBM лицензии выкладывание таких тестов в паблик?

Не знаю. Там какой-то совместный центр существовал. Формальный, как я понимаю. Под его эгидой какие-то умельцы что-то погоняли, померили, составили отчеты с заранее задаными результатами.
Внешне выглядит объективно и технически корректно. Но на мэйнфрэйм таких нагрузок не гоняют, не для этого берут мэйнфрэйм, не так грузят. Все не так. Количество заданий, помнится критиковал - с какой стати оно должно равняться количеству коров? Что-то в этом роде. Разбираться заново не буду, не хочу тратить время и копаться в заведомо грязной, не профессиональной, работе.

[zVlad]

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

http://www.oracle.com/us/solutions/benc ... 67486.html

Например эта пара:
http://www.oracle.com/us/solutions/benc ... 502957.pdf
http://www.oracle.com/us/solutions/benc ... 497509.pdf

Небольшой (!) мидрейнжевый сервер оказался почти в два раза быстрее, при этом загрузка ЦП была в два раза ниже (Он почти линейно масштабируется по процессору на разных задачах до упора. Их в хозяйстве было много.) Обычный честный batch.
....

В этом "обычном честном batch" в одном случае (z10) пускалось 8 job streams, а во втором (Sun T4) 96 job streams.

Обясните почему? Можно ли считать что выполнялся один и тот же тест в таком разе?

P.S. Это, кстати, лишь один из моментов наперстничества. Есть еще минимум два: диски и размеры RAM-ов. Сравните их тоже. Но главным остается первый: количество job streams.

[mskmel]

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

А какие гоняют? Вроде как по мне правоверная DB2.
Нашёл у нас Z10, работал(ет) под MQ чисто. Доступа туда естественно у меня нет и не будет

В этом "обычном честном batch" в одном случае (z10) пускалось 8 job streams, а во втором (Sun T4) 96 job streams.

Меня это тоже удивило. Видимо следущий шаг это 16, а загрузка уже была 70%+. Почему люди массово боятся 100% CPU usage мне так и не ясно за 20+ лет работы.
На Т4 потоки еще остались, зачем вообще Т4-4 было брать, если есть меньшие модельки.

[Flash-04]

Ну вообще-то система становится задумчивой при 100% нагрузке.

[zVlad]

Ну вообще-то система становится задумчивой при 100% нагрузке.

Обычные системы да, становятся задумчивыми. Но не zOS. Я в пиковые часы при 100% busy прекрасно работаю и наши пользователи тоже.

[alex_127]

Меня это тоже удивило. Видимо следущий шаг это 16, а загрузка уже была 70%+. Почему люди массово боятся 100% CPU usage мне так и не ясно за 20+ лет работы.

Потому что загрузка 60% не означает что кран открыт и их него течет 60% пропускной способности. Например это значит что в течении 600 миллисек в последней сек загрузка была 100%. Или 6 процессоров из 10 были заняты 100%. Кроме этого есть много тонкостей - длина квантума, ИО буст... Поэтому зависимость между загрузкой и например временем ответа нелинейна.

[zVlad]

....

В этом "обычном честном batch" в одном случае (z10) пускалось 8 job streams, а во втором (Sun T4) 96 job streams.

Меня это тоже удивило. Видимо следущий шаг это 16, а загрузка уже была 70%+....

То что загрузка "уже" была 70% ровным счетом ни о чем не говорит. Отдача МФ может расти и после того как достигнута загрузка CPU 100%. Вопрос лишь в том что мы будем понимать под "отдача".

Мой поинт прост. Мэйнфрэйм не был даже загружен на 100%, что означет что и МФ с меньшими возможностями мог бы работу теста выполнить с задаными ожиданиями. Вообще для пакетных заданий нормальные ожидания это: когда выполнится тогда и ладно. Что можно тестировать и увидеть гоняя абстрактые задания с не установленными показателями качества выполнения (обычно с заданиями связымваю пропускную способность) я понимать отказываюсь. Поэтому в общем и целом все такие тесты - это спекуляции на кофейной гуще.

На других платформах боятся 100% ЦПУ потому что система может прекратить выдавать любую работу, "сдуться" может, уйти "в нуль". Причем может уйти в нуль и с невысокой загрузкой CPU, а, например, из-за размера RAM.

[mskmel]

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

№1
Вырожденный вариант - CPU bound process, 1 процессор.
Есть SLA: время отклика (ВО) 1сек,
Экспериментально установлено, что при 1-99% загрузки CPU имеем ВО < 0.1сек.
Каким образом 100% будет проблемой? Почему мониторим CPU, а не ВО? или run queue?

№2
Лет 10+ назад работал на одного достаточно жадного оператора связи, с постргессом и ораклом на биллинге. Серверы тарификации были в 100% 1-2 недели в месяц, остальное время отдыхали. Но пока они делали работу, которую они должны сделать никого это особо не беспокоило. Никому не надо было выставлять месячные счета за 1 час, за 2 недели вполне нормально. Запас в 2 раза это отлично. Даже поговаривали убрать парочку, чтобы уменьшить стоимость лицензий.

№3
Более сложный для понимания. Дано сервер х86 с 4мя или 8ю сокетами.
Средняя загрузка CPU 10%, но mpstat показывает что NumeNode0 Core0 = 100% всё время, и сервер в одной подсети имеет pings 100msec. После исследования выясняется, что оно занято IRQ сетевых карт. Как поможет знание что Total CPU usage всего 10%?

Очевидно что еще можно придумать сценарии, но направление мысли понятно. 100% CPU usage != у нас проблемы. Также как и с памятью кстати.

[mskmel]

Мэйнфрэйм не был даже загружен на 100%, что означет что и МФ с меньшими возможностями мог бы работу теста выполнить с задаными ожиданиями.

Стоимостью в 20 раз ниже? Не уверен.

[Dmitry67]

Отдача МФ может расти и после того как достигнута загрузка CPU 100%.

Именно, до 146% CPU

[mskmel]

Ну вообще-то система становится задумчивой при 100% нагрузке.

Экспериментальным путём установлено, что юзеры нихрена не замечают пока загрузка не станет 200% Т.е. грубо говоря два CPU bound процесса на ядро.

В Z, судя по всему, процессоры очень быстрые на один поток, так что всё должно быть ОК при 100% нагрузке. При их стоимости иметь 70% это выкидывать несколько сотен тыщ или даже миллионы $ в год.