For a given CPU, the I/O wait time is the time during which that CPU was idle (i.e. didn’t execute any tasks) and there was at least one outstanding disk I/O operation requested by a task scheduled on that CPU (at the time it generated that I/O request).

https://veithen.io/2013/11/18/iowait-linux.html
#cpu #iowait

Что стоит за Ctrl+C и темная сторона прерываний в unix

#rust

https://sunshowers.io/posts/beyond-ctrl-c-signals/

5 Days To Virtualization: A Series On Hypervisor Development

Day 0: Setting up test environment, scripts, shared folders, and WinDbg shortcuts.
This article will detail what testing environment will be used throughout the series, how to setup both serial and network debugging, writing scripts to aid in efficient and fast stand-up for testing, and creating WinDbg shortcuts to quicken debugging init.
Day 1: Driver skeleton, introduction to virtualization, type definitions and the reasoning behind detailing them, compiling, and running unit tests.
This will provide a walk-through on constructing a basic driver skeleton for usage, explain the different pieces and their purpose, introduce virtualization and the various components in great detail, and then provide type definitions, their purpose, and where more information can be found. We’ll close with compiling and running unit tests to verify that everything is written properly and running as expected. (You may find this boring, but it is an incredibly important part of any project.)
Day 2: Writing communication channel for client and VMM, defining important context structures, detailed explanation of important VMM regions, allocating, building, and testing initialization of basic constructs on a single processor.
This will likely be lengthy, more lengthy than the previous two, and be the most important one to read all the way through. It will provide details on communicating with your driver, the importance of designing the structure of your hypervisor before implementation, and will explain the various VMM regions required for basic initialization and entrance into VMX operation. All of this will be done for a single processor to lower complexity, Day 3 will begin multi-processor initialization.
Day 3: Multi-processor initialization, setting up VMM regions on MP systems, error checking, VMX instructions, and the importance of unwinding actions.
In this article we’ll discuss multi-processor initialization, and the various ways to initialize all cores. As well as implementing solid error checking mechanisms and procedures, introducing VMX instructions and their nuances, and the article will conclude with the importance of unwinding actions (the ability to gracefully recover from errors, free what has been allocated, and return to a stable system state.)
Day 4: VMCS initialization, the differences in guest state versus host state, operation visualization, and the use of intrinsic functions.
This article will be detailed, fast paced, with lots of reference material. There is an entire chapter in the Intel SDM Volume 3C dedicated to VMCS encoding, init, and guest/host state operation. We will only be covering the very basics for understanding. I will also help the reader visualize how operation is entered, exited, and resumed to make it easier to understand the abstractness. We will also cover the implementation of important intrinsic functions required for setting up various guest and host VMCS components.
Day 5: Implementing unconditional vmexit handlers, and testing start-up and shutdown.
This day will cover the introduction and details on segmentation on Intel x86-64, demystifying initialization of guest and host segment data. Also, including implementation of the vmexit handler to handle unconditional exits that will occur, explaining the assembly stubs, and will conclude with a test of the hypervisor to verify that it starts and runs stably, and shuts down gracefully returning the system to a stable pre-operation state.

https://github.com/bytedance/vArmor/tree/main
#github #sec #varmor #epbf #seccomp #apparmor

Распробовал на днях утилиту sq. Если jq - это инструмент для выборки и красивой визуализации данных из джейсонок, то sq - это все тоже самое (и даже чуть больше), но для баз данных. Выглядит прикольно, использовать (после jq) достаточно интуитивно, есть прикольные плюшки (например, просмотр диффа двух таблиц), умеет импортировать/экспортивароть данные. И, естественно, это опенсорсный проект. В общем, мне понравлось настолько, что не стыдно и вам показать https://sq.io/

На просторах Github мы наткнулись на репозиторий KubernetesCRInjection. Он определенно будет полезен, если вы пишите свой Kubernetes controller и хотите избежать возможных уязвимостей еще на стадии его проектирования.

Когда мы имеем дело с уязвимым Kubernetes controller нужно понимать что, злоумышленники могут контролировать определенные пользовательские ресурсы и внедрять вредоносные полезные нагрузки, которые могут вызвать вредоносное поведение, когда контроллер анализирует, обрабатывает, хранит кастомные ресурсы или генерирует другие связанные ресурсы.

Примеры того как можно классифицировать такие инъекции и реальные примеры таких уязвимостей можно в репозитории.

https://github.com/duke-git/lancet
#github #go #lib

Как небольшой «тюнинг» Talos Linux увеличил производительность NVMe SSD в 2.5 раза для k8s
https://habr.com/ru/articles/852536/

Спойлер:
iommu.strict=0

Шикарный пример пряморукой визуализации. Товарищ наглядно изобразил, как устроены задержки при межсерверной коммуникации внутри и между зонами доступности на примере амазоновского us-east-2 датика.
Цель проекта? Да пёс его знает. Красиво и наглядно показывает, что коммуникация внутри AZ всегда быстрее, даже если все машины физически в одном месте.

https://benjdd.com/az/

Циферки брал вот так: https://www.bitsand.cloud/posts/cross-az-latencies

Я вот как-то писал про свою личную OPS практику - периодический рестарт программ в проде (https://tttttt.me/itpgchannel/370)

Вот, хороший текст, подтверждающий эффективность такого подхода:

https://pushtoprod.substack.com/p/netflix-terrifying-concurrency-bug

"We created a rule in our central monitoring and alerting system to randomly kill a few instances every 15 minutes. Every killed instance would be replaced with a healthy, fresh one"

И я, кстати, совершенно не кривил душой, говоря про это.

Вот, например, я периодически рестартую свои haproxy и ssh туннели для обхода блокировок (https://tttttt.me/itpgchannel/2262) в своей #lab #home_lab - https://github.com/pg83/lab/blob/master/lab/cg.py#L455-L457

https://matt.blwt.io/post/regular-restarts-are-good-actually/

TL;DR - еще один взгляд на тему "почему регулярные рестарты - хорошо".

Я написал очень длинный и очень интересный текст про Юникод. Поскольку в Telegram пост такого размера не помещается, выложил на сайт:

https://blo.gepar.do/v0/unicode.html

Все бегом читать :)

Я думаю, многие слышали кучу наставлений, что CPU limits в kubernetes не нужны. Началось это все со знаменитого поста Tim Hockin.
Но вот нюанс, с похожей ситуацией и я столкнулся, если ваше приложение ориентируется на cpuset cgroup, то придется делать под Guaranteed (нет, это нужно не только для static полиси).
Мораль такова: что не все, что большие мужи говорят - стоит принимать за истину.