Блог*
Когда-то тридцатилетие казалось чем-то далёким. А теперь мне 30 ближе, чем 20. Не хочу(
Ну, с другой стороны, теперь уже можно на молодых давить возрастом 🌚
🤡1
#prog #article #retroit
Графика древности: от текста к видеоиграм
Или про историю пиксельной графики (с неизбежной привязкой к истории развития железа)
Графика древности: от текста к видеоиграм
Или про историю пиксельной графики (с неизбежной привязкой к истории развития железа)
Хабр
Графика древности: от текста к видеоиграм
Вот уже много лет в игровой индустрии вместе с самыми последними графическими технологиями успешно сосуществует пиксельная графика практически в том же самом виде, в каком она существовала в играх для...
❤4🤡1
#prog #rust
Важный фикс для std: Cell::swap теперь паникует для частично перекрывающихся аргументов. Почему? Потому что без этого нормально выглядящий код, который использует
Демонстрация проблематичного кода (паникует на nightly, но падает с double free на stable):
Важный фикс для std: Cell::swap теперь паникует для частично перекрывающихся аргументов. Почему? Потому что без этого нормально выглядящий код, который использует
Cell
, может привести к use after free или чему похуже в комбинации с Cell::swap
.Демонстрация проблематичного кода (паникует на nightly, но падает с double free на stable):
use std::cell::Cell;
use std::mem::transmute;
use std::convert::TryInto;
// This ought to be sound.
fn as_cell_of_array<T, const N: usize>(
c: &[Cell<T>; N]
) -> &Cell<[T; N]> {
unsafe { transmute(c) }
}
fn main() {
// Oops, now this safe code can cause a use-after-free.
let x = [
Cell::new(vec![1]),
Cell::new(vec![2]),
Cell::new(vec![3]),
];
let x1: &Cell<[_; 2]> =
as_cell_of_array(x[0..2].try_into().unwrap());
let x2: &Cell<[_; 2]> =
as_cell_of_array(x[1..3].try_into().unwrap());
x1.swap(x2);
}
GitHub
make Cell::swap panic if the Cells partially overlap by RalfJung · Pull Request #114795 · rust-lang/rust
The following function ought to be sound:
fn as_cell_of_array<T, const N: usize>(c: &[Cell<T>; N]) -> &Cell<[T; N]> {
unsafe { transmute(c) }
}
However, due to Cell...
fn as_cell_of_array<T, const N: usize>(c: &[Cell<T>; N]) -> &Cell<[T; N]> {
unsafe { transmute(c) }
}
However, due to Cell...
👍9🤡1
Господа подписчики, из тех, кто сейчас живёт в Армении. Как вы тратите деньги со счётов в российских банках?
Вопрос не праздный, потому как сейчас я перевожу деньги в наличные драмы весьма неоптимальным способом — через переводы Unistream — и, что гораздо хуже, несколько армянских банков больше с ними не работают.
Вопрос не праздный, потому как сейчас я перевожу деньги в наличные драмы весьма неоптимальным способом — через переводы Unistream — и, что гораздо хуже, несколько армянских банков больше с ними не работают.
🤡4
Forwarded from Новости Москвы
🤔 Вчера открыли МЦД-4 и теперь на карте метро есть пентаграмма
👍14🔥4🌚2
Новости Москвы
🤔 Вчера открыли МЦД-4 и теперь на карте метро есть пентаграмма
Хотя для чего-то, что называется "Московский центральный диаметр", это выглядит на редкость криво
🥴5🤡2
#prog #rust #article
Using Kani to Validate Security Boundaries in AWS Firecracker
Thanks to Kani, the Firecracker team was able to verify critical areas of code that were intractable to traditional methods. These include our noisy-neighbor mitigation, a rate limiter, where interactions with the system clock resulted in traditional testing being unreliable, as well as our VirtIO stack, where the interaction with guest memory lead to a state space impossible to cover by other means.
We found 5 bugs in our rate limiter implementation, the most significant one a rounding error that allowed guests to exceed their prescribed I/O bandwidth by up to 0.01% in some cases. Additionally, we found one bug in our VirtIO stack, where a untrusted guest could set up a virtio queue that partially overlapped with the MMIO memory region, resulting in Firecracker crashing on boot. Finally, the debug assertions added to the code under verification allowed us to identify a handful of unit tests which were not set up correctly. These have also been fixed.
Using Kani to Validate Security Boundaries in AWS Firecracker
Thanks to Kani, the Firecracker team was able to verify critical areas of code that were intractable to traditional methods. These include our noisy-neighbor mitigation, a rate limiter, where interactions with the system clock resulted in traditional testing being unreliable, as well as our VirtIO stack, where the interaction with guest memory lead to a state space impossible to cover by other means.
We found 5 bugs in our rate limiter implementation, the most significant one a rounding error that allowed guests to exceed their prescribed I/O bandwidth by up to 0.01% in some cases. Additionally, we found one bug in our VirtIO stack, where a untrusted guest could set up a virtio queue that partially overlapped with the MMIO memory region, resulting in Firecracker crashing on boot. Finally, the debug assertions added to the code under verification allowed us to identify a handful of unit tests which were not set up correctly. These have also been fixed.
Kani Rust Verifier Blog
Using Kani to Validate Security Boundaries in AWS Firecracker
Security assurance is paramount for any system running in the cloud. In order to achieve the highest levels of security, we have applied the Kani model checker to verify safety-critical properties in core components of the Firecracker Virtual Machine Monitor…
👍3🤯2🤡1