Having read several papers on the exploitation of cache latency to defeat
aslr (kernel or not), it appears that disabling the rdtsc instruction is a
good mitigation on x86. However, some applications can legitimately use it,
so I would rather suggest restricting it to root instead.
The idea is si
> Having read several papers on the exploitation of cache latency to
> defeat aslr (kernel or not), it appears that disabling the rdtsc
> instruction is a good mitigation on x86.
I don't really know x86. But, based on the little I do know, my
reactions are:
(1) Please provide a kernel build opti
On Tue, Mar 28, 2017 at 04:58:58PM +0200, Maxime Villard wrote:
> Having read several papers on the exploitation of cache latency to defeat
> aslr (kernel or not), it appears that disabling the rdtsc instruction is a
> good mitigation on x86. However, some applications can legitimately use it,
> so
On Tue, Mar 28, 2017 at 11:30:52AM -0500, David Young wrote:
> [...]
> What do you mean by "legitimately" use rdtsc? It seems to me that it
> is legitimate for a user to use a high-resolution timer to profile some
> code that's under development. They may want to avoid running that code
> with ro
On Tue, Mar 28, 2017 at 11:30:52AM -0500, David Young wrote:
> What do you mean by "legitimately" use rdtsc? It seems to me that it
> is legitimate for a user to use a high-resolution timer to profile some
> code that's under development. They may want to avoid running that code
> with root privi
Answering to each of your questions in one mail, with a few notes at the end.
First of all, it is just a wild idea from when I was in the train the other
day, and I haven't written any code for it. Then:
Le 28/03/2017 à 18:01, Mouse a écrit :
(1) Please provide a kernel build option to remove th
> There is however another technique (software clock) to try to compute
> the number of cycles an operation takes, but the resulting accuracy
> is very low, and not sufficient to detect cache misses via latency.
> [D]etecting cache misses implies having a precision of at least ~50
> cycles, and on
> Date: Tue, 28 Mar 2017 16:58:58 +0200
> From: Maxime Villard
>
> Having read several papers on the exploitation of cache latency to defeat
> aslr (kernel or not), it appears that disabling the rdtsc instruction is a
> good mitigation on x86. However, some applications can legitimately use it,
>
> Date: Mon, 20 Mar 2017 18:43:04 -0400
> From: Raunaq Kochar
>
> I am a Masters in Computer Science student at Stony Brook University
> looking to work as part of the Google Summer of Code on the Real
> Asynchronous I/O or Parallelize Page Queues projects.
> As I am new to the open source commun
On Tue, Mar 28, 2017 at 06:47:11PM +0200, Manuel Bouyer wrote:
> On Tue, Mar 28, 2017 at 11:30:52AM -0500, David Young wrote:
> > [...]
> > What do you mean by "legitimately" use rdtsc? It seems to me that it
> > is legitimate for a user to use a high-resolution timer to profile some
> > code that
> On Mar 28, 2017, at 2:37 PM, Taylor R Campbell
> wrote:
>
> [EXTERNAL EMAIL]
>
>> Date: Tue, 28 Mar 2017 16:58:58 +0200
>> From: Maxime Villard
>>
>> Having read several papers on the exploitation of cache latency to defeat
>> aslr (kernel or not), it appears that disabling the rdtsc instr
Le 28/03/2017 à 20:32, Mouse a écrit :
But, by repeating observations, it is possible to detect signals well
below the apparent noise floor. [...] my question was essentially asking
whether you believe the increase in work factor would be enough to make it
infeasible.
Theoretically, it does ind
On Tue, Mar 28, 2017 at 10:36:52PM +0200, Maxime Villard wrote:
> I already thought about this a few months ago, and my conclusion back then
> was that it is very difficult to achieve if we want both good performance
> and good security. This is a little off-topic, but the idea would consist in
> h
>> Hence also my question about changing the kernel's location at
>> runtime. If the address space base changes every second, say, any
>> technique to discover it that takes longer than a second becomes
>> useless.
> I already thought about this a few months ago, and my conclusion back
> then was
Maxime Villard wrote:
> Having read several papers on the exploitation of cache latency to defeat
> aslr (kernel or not), it appears that disabling the rdtsc instruction is a
> good mitigation on x86. However, some applications can legitimately use it,
> so I would rather suggest restricting it to
On Tue, Mar 28, 2017 at 04:58:58PM +0200, Maxime Villard wrote:
> Having read several papers on the exploitation of cache latency to defeat
> aslr (kernel or not), it appears that disabling the rdtsc instruction is a
> good mitigation on x86. However, some applications can legitimately use it,
> so
On 2017/03/24 8:13, Michael wrote:
Hello,
On Wed, 22 Mar 2017 16:35:21 +0900
Masanobu SAITOH wrote:
A) modify pci_mapreg_map(). Stop setting BUS_SPACE_MAP_PREFETCHABLE
by defalut when prefetchable bit is set. If a driver really know
the whole area of the BAR is prefetchable, set B
Hello,
I'm a computer science undergraduate at Harvard studying Operating Systems
and I'm interested in implementing ext3 for a Google Summer of Code
project.
First off, the project page states that several years of ext3 GSoC projects
have failed. I'm interested in finding out why, and figuring o
18 matches
Mail list logo
