thijsr

I may be biased, but I do think it is a very fun talk

(disclosure: I am the speaker)

A digital euro is intended to the the digital equivalent of cash. It is issued directly by the central bank. Currently, consumers cannot have an account at the central bank. They have a balance at a commercial bank, and the commercial bank has an account at the central bank. Right now, you must have a private middleman to do any banking. The digital euro should offer a public alternative to that.

(but it probably won't ever happen, because banks are lobbying against it with FUD campaigns, they feel like it threatens their existence)

Wero is something completely different. It allows consumers to easily pay merchants, mostly online. The digital euro is not a payment network in the same sense as Visa, Mastercard, iDEAL and others.

We've only verified EC2 during our research, but you do make a good point here. Nitro wasn't vulnerable. Firecracker might have been, considering that it is also built on top of KVM. Firecracker was not specifically designed to also defend against hardware vulnerabilities [1], so I don't see an immediate reason why it wouldn't have worked.

We had to limit the scope of the project somewhere unfortunately, but it would have been nice to check Firecracker and Lambda as well.

[1] https://github.com/firecracker-microvm/firecracker/blob/main...

Hi, author here. Thanks for posting this! I gave a talk yesterday at the 39th Chaos Communication Congress in Hamburg that goes into detail about how the vulnerability works [1]. Short summary, on affected CPUs, all of host physical memory can be read, despite commonly applied software mitigations. On Google Cloud, we were able to leak from all of the physical memory from other tenants as well, without having to interact with the victim virtual machine.

[1] https://media.ccc.de/v/39c3-spectre-in-the-real-world-leakin...

> I also don't love enums for errors because it means adding any new error type will be a breaking change

You can annotate your error enum with #[non_exhaustive], then it will not be a breaking change if you add a new variant. Effectively, you enforce that anybody doing a match on the enum must implement the "default" case, i.e. that nothing matches.

Scientific papers have an abstract, which already serves as a short summary.

This is a project that we've been working in collaboration with Google and AWS. We present a vulnerability that allows a malicious virtual machine to leak all physical memory of its host, including the memory of other virtual machines running on the system. L1TF Reloaded combines two long-known transient execution vulnerabilities, L1TF and (Half-)Spectre. By combining them, commonly deployed software-based mitigations against L1TF, such as L1d flushing and core scheduling, can be circumvented.

We've demonstrated our attack on real-world KVM-based cloud solutions. Both Google Cloud [1] and AWS [2] wrote a blog post in response to this attack, where they describe how they mitigate against L1TF Reloaded and how they harden their systems against unknown transient execution attacks. Google also decided to award us a bug bounty of $151,515, the highest bounty of their Cloud VRP yet.

PoC is available at https://github.com/ThijsRay/l1tf_reloaded

[1] this submission

[2] https://aws.amazon.com/blogs/security/ec2-defenses-against-l...

When you can modify the microcode of a CPU, you can modify the behaviour of the RDRAND/RDSEED instructions. For example, using EntrySign [1] on AMD, you can make RDRAND to always return 4 (chosen by a fair dice roll, guaranteed to be random)

[1] https://bughunters.google.com/blog/5424842357473280/zen-and-...

Rowhammer is an inherent problem to the way we design DRAM. It is a known problem to memory manufacturers that is very hard, if not impossible, to fix. In fact, Rowhammer only becomes worse as the memory density increases.

As far as I am aware, the course material is not public. Practical assignments are an integral part of the courses given by the VUSEC group, and unfortunately those are difficult to do remotely without the course infrastructure.

The Binary and Malware Analysis course that you mentioned builds on top of the book "Practical Binary Analysis" by Dennis Andriesse, so you could grab a copy of that if you are interested.

I like Quadlets. It nicely integrates with all other systemd services I run. Looking forward for the release of Debian Trixie so I can use it on stable Debian.

Disabling SMT alone isn’t enough to mitigate CPU vulnerabilities. For full protection against issues like L1TF or MDS, you must both enable the relevant mitigations and disable SMT. Mitigations defend against attacks where an attacker executes on the same core after the victim, while disabling SMT protects against scenarios where the attacker runs concurrently with the victim.

It depends on your threat model. If you don't run any untrusted code on your hardware (including Javascript), you can safely disable the mitigations. If you do run untrusted code, keep them enabled.

From the FAQ:

> While FLOP has an actionable mitigation, implementing it requires patches from software vendors and cannot be done by users. Apple has communicated to us that they plan to address these issues in an upcoming security update, hence it is important to enable automatic updates and ensure that your devices are running the latest operating system and applications.

RowHammer is not a thing of the past. In fact, modern DRAM chips are significantly more susceptible to RowHammer due to their increased chip density [1].

[1] https://arxiv.org/abs/2005.13121

The paragraph right after says

> Additionally, organizations may have their own billing information associated with the org itself. They can use this to sponsor the accounts of their members, allowing the billing for a tightly coupled group of users (e.g. staff members at a company or organization) to have access to centralized billing. Through this they can meet the 50% requirement without having individual members pay up.

Organizations can have centralized/simpler billing with this proposal

They have a status page for the WhatsApp Business API at https://metastatus.com/whatsapp-business-api

It currently shows major disruptions.

Yes, the CPU self-reported power usage is indeed fairly noisy. We've tried to mitigate this by executing certain tests multiple times in a row, and using the average power consumption across these executions. However, this is data is still quite noisy and is influenced by external factors, like the operating system, your hardware, power management settings, and a lot more. We mention this and possible mitigating actions in the README.

We chose for a test harness because one of our goals was to make it as easy as possible to run it on existing Rust projects. A lot of projects define tests, but benchmarks are not often not present. But maybe a bench harness would be a better and/or cleaner approach, will look into it!

Hey, I wanted to share a project that we've been working on! Coppers is a custom test harness for Rust that allows you to measure the energy consumption of your test suite. A use case for this could be to identify regressions in energy usage, or to do more targeted energy optimizations. Our goal was to make it as seamless as possible to integrate it with existing Rust projects. To make that work, we had to rely on some unstable and internal Rust compiler features that are only available in nightly. But the current implementation seems to be able to measure the energy consumption of almost every existing Rust crate we tested! (with the exception of embedded and system-specific crates, but that is a limitation we're looking into)