# side channel Published articles for side channel. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Security Week 2623: слежка за пользователями через SSD DevFeed: [Security Week 2623: слежка за пользователями через SSD]() Original publisher: [Read original article]() Author: Kaspersky\_Lab ("Лаборатория Касперского") Published: 2026-06-01T17:31:16Z Content type: news Language: ru Sources: ["Лаборатория Касперского" RU]() Topics: [Security](), [Filesystems](), [Google Chrome](), [JavaScript](), [Linux](), [macOS]() Tags: [google-chrome](), [javascript](), [linux](), [mac](), [macos](), [security](), [side-channel](), [ssd](), [tag-9fe8963de219]() ### AI overview Researchers from Graz University of Technology described FROST, a browser-based contention side-channel attack that uses repeated SSD access through the Origin Private File System to infer running programs and visited websites from storage-performance delays. The attack runs in JavaScript without user intervention and was tested with Google Chrome on Linux and macOS systems. ### Source excerpt На прошлой неделе исследователи из Грацского технического университета в Австрии опубликовали научную работу, в которой предложили метод отслеживания пользовательской активности через браузер. Варианты атак, в которых вкладка с вредоносным сайтом может, например, определять, какие страницы открыты по соседству, предлагались и ранее, но полагались в основном на особенности работы браузеров. Новая атака FROST также использует особенности браузеров, но основным каналом утечки оказываются не они, а производительность накопителя данных. Общая схема атаки выглядит следующим образом: пользователя заманивают на вредоносную страницу, которая при помощи стандартных технологий браузеров реализует активный и регулярный обмен данными на SSD. Производительность SSD ниже, чем у оперативной памяти, что вызывает определенные задержки при обмене, когда к накопителю также обращаются другие программы и веб-сайты. Как выяснилось, паттерны этих задержек позволяют с достаточно высокой надежностью выявлять не только запущенные на ПК программы, но и посещаемые веб-сайты. Читать далее ## A hacking hat-trick: previewing three PortSwigger Research publications coming to DEF CON & Black Hat USA DevFeed: [A hacking hat-trick: previewing three PortSwigger Research publications coming to DEF CON & Black Hat USA]() Original publisher: [Read original article]() Author: James Kettle Published: 2024-07-02T12:57:08Z Content type: article Language: en Sources: [PortSwigger Research]() Topics: [Hacking](), [releases](), [Parser](), [Scripting](), [Open Source](), [ctf]() Tags: [attacks](), [automated](), [black-hat](), [ctf](), [hacking](), [open-source](), [parsing](), [releases](), [research](), [scripting](), [side-channel]() ### AI overview PortSwigger Research previews three publications scheduled for Black Hat USA and DEF CON 32. The article highlights practical timing attacks using timing oracles, including techniques for uncovering server secrets, masked misconfigurations, blind data-structure injection, hidden routes, and invisible attack surfaces. It also describes open-source tools for automated exploitation and attack scripting, a CTF, and a forthcoming session on the challenges of parsing email addresses. ### Source excerpt We're delighted to announce three major research releases from PortSwigger Research will be published at both Black Hat USA and DEF CON 32. In this post, we'll offer a quick teaser of each talk, info ## Transactional Memory and Tech Hype Waves DevFeed: [Transactional Memory and Tech Hype Waves]() Original publisher: [Read original article]() Published: 2019-08-14T15:09:26Z Content type: opinion Language: en Sources: [Jessie Frazelle]() Topics: [Concurrency](), [Deadlock](), [Database](), [intel]() Tags: [attacks](), [database](), [deadlock](), [intel](), [side-channel](), [synchronization]() ### AI overview The article explains transactional memory, including Intel's Transactional Synchronization Extensions (TSX), as a way to avoid deadlocks while potentially introducing livelocks. It compares transactional memory with database transactions and discusses speculative outcomes, TSX abort handlers, and possible side-channel security concerns. ### Source excerpt At lunch today I learned about Transactional Synchronization Extensions (TSX) which is an implementation of transactional memory. The conversation started as a rant about why transactional memory is bad but then it evolved into how this concept even came to be and how it even got implemented if it's such a terrible idea. What is transactional memory? First let's start by going over what transactional memory is. You might be familiar with a deadlock. A deadlock occurs when a process or thread is waiting for a specific resource, which is also waiting on a different resource that is being held by another waiting process. You can think of this as P1 needs R1 and has R2, while in turn P2 needs R2 and has R1. That is a deadlock. Transactional memory removes the possibility of getting a deadlock and replaces it with what is known as a livelock. A livelock happens when processes are constantly changing with regard to one another but neither of them move forward or progress in anyway. Imagine you are walking down the street while another person is heading towards you. You move to the right to avoid running into them as they also move in that direction to avoid running into you. You both then move to the other side so as to not run into each other. This repeats over and over again with no progress forward since both people are moving in the same direction. That is a livelock. With transactional memory you no longer have deadlocks but livelocks. Why is this? Well, transactional memory works very similarly to database transactions. A transaction is a group of operations that can execute and commit changes as long as there are no conflicts. If there is a conflict, it will start from state zero and try to run again until there are no conflicts. Therefore, until there is a successful commit of a run, the outcome of any operation is speculative. Intel's implementation of TSX behaves in such a way that when a transaction aborts due to a hardware exception, it does not fire typical e ## Reflections on SGX DevFeed: [Reflections on SGX]() Original publisher: [Read original article]() Published: 2019-02-19T17:16:52Z Content type: opinion Language: en Sources: [Jessie Frazelle]() Topics: [Security](), [Cloud](), [Containers](), [Docker]() Tags: [cloud](), [containers](), [docker](), [opinion](), [security](), [side-channel]() ### AI overview The author revisits Intel SGX after receiving additional context about its origins as DRM technology and its later use for code execution in enclaves. The article discusses HAVEN, encrypted memory for using cloud services without trusting the provider, running Docker containers inside enclaves, and unresolved side-channel attack challenges. ### Source excerpt I like to consider all the variables in a problem space before coming to a conclusion. As humans we have a tendency to jump to conclusions rather quickly. I try not to do this but everyone makes mistakes. More information about Intel SGX was brought to my attention after my initial blog post on it. I'd like to take the time to go through that information and my current thoughts on the technology after having this extended context. Trammel Hudson (@qrs) pointed out to me yesterday that SGX was originally built for the use case of DRM for Netflix, Microsoft, etc. Having this context makes the problems that arise when you try to do code execution inside an enclave seem like a forgivable sin. It was not until the HAVEN paper that people even considered using enclaves as an execution environment. In that regard, the HAVEN paper was truly novel. I may disagree with shoving an entire operating system in there, but the idea of executing code in an environment with encrypted memory as a way to use the cloud without trusting the cloud is a respectable feat. Another person who I truly respect and admire for the thought they put into what they build is Joanna Rutkowska (@rootkovska). She recently started working at golem a shared compute providing company focused on security and privacy. She wrote an awesome blog post considering all the tradeoffs of a technology such as SGX. The post links to other posts where she really weighs the pros and cons of the technology. This is why I really respect her thoughts on the matter. The solution is pretty cool in that you can run docker containers inside the enclave. It's better than the SCONE paper, which also runs containers, in my opinion, because it doesn't do the crazy syscall toss outside the enclave. It's more aligned with the HAVEN paper in that it includes all the code inside the enclave. Her post is great; it really goes into detail on their thought process and what they designed their solution to prioritize. Considering SGX was ## Speculative Execution Threat Model DevFeed: [Speculative Execution Threat Model]() Original publisher: [Read original article]() Author: Adam Published: 2018-03-15T00:00:00Z Content type: opinion Language: en Sources: [Shostack & Friends Blog]() Topics: [execution](), [side channel](), [Vulnerabilities](), [Hardware](), [context]() Tags: [context](), [disclosure](), [execution](), [hardware](), [prevent](), [side-channel](), [vulnerabilities]() ### AI overview A commentary on Matt Miller's threat model for speculative execution side-channel hardware vulnerabilities. It describes primitives such as conditional and indirect branch misprediction and exception delivery or deferral, along with disclosure gadgets and mitigation models. ### Source excerpt [no description provided] ## Observing interrupts from userland on x86 DevFeed: [Observing interrupts from userland on x86]() Original publisher: [Read original article]() Author: Mark Seaborn (noreply@blogger.com) Published: 2018-01-08T20:39:00Z Content type: tutorial Language: en Sources: [Mark Seaborn]() Topics: [x86](), [cpu](), [Kernel](), [Linux](), [Processes]() Tags: [architecture](), [c](), [cpu](), [kernel](), [linux](), [process](), [side-channel](), [x86]() ### AI overview This article explains how a userland process on x86 can detect that it has been interrupted without timing measurements. Setting %fs or %gs to 1 allows the x86 IRET instruction to reset the register to 0 when returning from an interrupt handler; a C program demonstrates the behavior on Linux. ### Source excerpt In 2016, I noticed a quirk of the x86 architecture that leads to an interesting side channel. On x86, it is possible for a userland process to detect when it has been interrupted by an interrupt handler, without resorting to timing. This is because the usual mechanism for handling interrupts (without using virtualisation) doesn't always preserve all userland registers across an interrupt handler. If a process sets a segment selector register such as %fs or %gs to 1, the register will get set to 0 when the process gets interrupted by an interrupt. Specifically, the x86 IRET instruction will reset the register to 0 when returning to userland -- this is the instruction that kernels use for returning from an interrupt handler. I have not seen this quirk explicitly documented anywhere, so I thought it was worthwhile documenting it via this blog post. The following C program demonstrates the effect: #include #include void set_gs(uint16_t value) { __asm__ volatile("mov %0, %%gs" : : "r"(value)); } uint16_t get_gs() { uint16_t value; __asm__ volatile("mov %%gs, %0" : "=r"(value)); return value; } int main() { uint16_t orig_gs = get_gs(); set_gs(1); unsigned int count = 0; /* Loop until %gs gets reset by an interrupt handler. */ while (get_gs() == 1) ++count; /* Restore register so as not to break TLS on x86-32 Linux. This is not necessary on x86-64 Linux, which uses %fs for TLS. */ set_gs(orig_gs); printf("%%gs was reset after %u iterations\n", count); return 0; } This works on x86-32 or x86-64. I tested it on Linux. It will print a non-deterministic number of iterations. For example: %gs was reset after 1807364 iterations Why this happens x86 segment registers are a bit weird, because each one has two parts: A program-visible 16-bit "segment selector" value, which can be read and written by the MOV instruction. A hidden part. When you write to a segment register using the MOV instruction, the CPU also fills out the hidden part. The hidden part includes ## L3 cache mapping on Sandy Bridge CPUs DevFeed: [L3 cache mapping on Sandy Bridge CPUs]() Original publisher: [Read original article]() Author: Mark Seaborn (noreply@blogger.com) Published: 2015-04-27T21:59:00Z Content type: article Language: en Sources: [Mark Seaborn]() Topics: [Cache](), [cpu](), [intel](), [systems]() Tags: [cache](), [cpu](), [hash](), [intel](), [kernel](), [memory](), [paper](), [protocol](), [rowhammer](), [side-channel](), [slices](), [xor]() ### AI overview The article explains how physical addresses map to cache sets and slices in the L3 cache of Intel Sandy Bridge CPUs. It reports a previously published mapping for four-core CPUs and presents the author's mapping for two-core CPUs, with applications to kernel ASLR analysis and row-hammering research. ### Source excerpt In 2013, some researchers reverse-engineered how Intel Sandy Bridge CPUs map physical addresses to cache sets in the L3 cache (the last-level cache). They were interested in the cache mapping because it can be used to defeat kernel ASLR. I'm interested because the cache mapping can be used to test whether cached memory accesses can do row hammering (which can cause exploitable bit flips in some DRAM devices). The researchers published the details in the paper "Practical Timing Side Channel Attacks Against Kernel Space ASLR" (Ralf Hund, Carsten Willems and Thorsten Holz). They only published the mapping for 4-core CPUs, but I have figured out the mapping for 2-core CPUs as well. Some background: On Sandy Bridge CPUs, the L3 cache is divided into slices. Physical addresses are hashed to determine which slice of the L3 cache they will be stored in. The L3 cache is distributed and ring-based. There is one slice per core, but all the cores in a CPU can access all the cache slices via a ring bus which connects all the cores and their caches together. When a core accesses a memory location, the location will be slightly slower to access if it maps to a different core's cache slice, because it would take one or two hops around the ring bus to access it. The protocol used on the ring bus is based on QPI (Intel's QuickPath Interconnect). (QPI is a protocol used for connecting multiple CPUs together on high-end multi-socket systems.) Each cache slice contains 2048 cache sets. On lower-end CPUs, cache sets are 12-way associative, so a cache slice is 1.5MB in size (2048 sets * 12 ways * 64 bytes per cache line = 1.5MB). On higher-end CPUs, cache sets are 16-way associative, so a cache slice is 2MB in size (2048 sets * 16 ways * 64 bytes per cache line = 2MB). Cache mapping The researchers (Hund et al) figured out that the L3 cache uses the bits of a physical address as follows: Bits 0-5: These give the 6-bit byte offset within a 64-byte cache line. Bits 6-16: These give the 11-b