Taylor R Campbell wrote:
> > 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 ap
Maxime Villard wrote:
> Le 29/03/2017 ? 00:49, Alexander Nasonov a ?crit :
> > I think this should be either all-or-nothing. You either have rdtsc as
> > a time source or you don't. Similar for rdpmc (and other performance
> > counters).
>
> Well, the idea was to make the availability more fine-gr
On Tue, Apr 04, 2017 at 05:39:35PM +0200, Maxime Villard wrote:
> sorry for the delay
>
> Le 31/03/2017 ? 19:23, Andreas Gustafsson a ?crit :
> > It's ASLR that's broken, not rdtsc, and I strongly object to
> > restricting the latter just to that people can continue to gain
> > a false sense of se
sorry for the delay
Le 31/03/2017 à 19:23, Andreas Gustafsson a écrit :
It's ASLR that's broken, not rdtsc, and I strongly object to
restricting the latter just to that people can continue to gain
a false sense of security from the former.
For your information, side-channels are not only limit
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
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
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
>> 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
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
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 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
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
> 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,
>
> 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
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
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
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 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
> 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
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
21 matches
Mail list logo
