On 1/30/19 1:44 PM, Vlastimil Babka wrote:
> Close that sidechannel by always initiating readahead on the cache if we
> encounter a cache miss for preadv2(RWF_NOWAIT); with that in place, probing
> the pagecache residency itself will actually populate the cache, making the
> sidechannel useless.
I
On 1/31/19 1:08 PM, Jiri Kosina wrote:
> On Thu, 31 Jan 2019, Daniel Gruss wrote:
>
>> If I understood it correctly, this patch just removes the advantages of
>> preadv2 over mmmap+access for the attacker.
>
> Which is the desired effect. We are not trying to solve th
On 1/7/19 12:08 PM, Dominique Martinet wrote:
>> That's my bigger concern here. In [1] there's described a remote attack
>> (on webserver) using the page fault timing differences for present/not
>> present page cache pages. Noisy but works, and I expect locally it to be
>> much less noisy. Yet the
On 2017-05-05 17:53, Jann Horn wrote:
Ah, I think I understand. The kernel stacks are mapped, but
cpu_current_top_of_stack isn't, so you can't find the stack until after the CR3
switch in the syscall handler?
That's the idea. Only the absolute minimum that is required for a
context switch rema
On 2017-05-06 06:02, David Gens wrote:
Assuming that their patch indeed leaks per-cpu addresses.. it might not
necessarily
be required to change it.
I think we're not leaking them (unless we still have some bug in our
code). The basic idea is that any part that is required for the context
swi
Just did a quick test on my main KVM host, a 8 core Intel(R) Xeon(R)
CPU E3-1240 V2.
KVM guests are 4.10 w/o CONFIG_KAISER and kvmconfig without CONFIG_PARAVIRT.
Building a defconfig kernel within that guests is about 10% slower
when CONFIG_KAISER
is enabled.
Thank you for testing it! :)
Is th
On 2017-05-08 00:02, Richard Weinberger wrote:
Ahh, *very* recent is the keyword then. ;)
I was a bit confused since in your paper the overhead is less than 1%.
Yes, only for very recent platforms (Skylake). While working on the
paper we were surprised that we found overheads that small.
Wh
While it may be the case that in practice ARM systems do not have such a
side channel, I think that it is erroneous to believe that the
architectural TTBR{0,1} split ensures this.
The use of TTBR0 for user and TTBR1 for kernel is entirely a SW policy,
and not an architectural requirement. It is p
On 05.05.2017 10:23, Daniel Gruss wrote:
- How this approach prevent the hardware attacks you mentioned? You
still have to keep a part of _text in the pagetable and an attacker
could discover it no? (and deduce the kernel base address).
These parts are moved to a different section
On 08.05.2017 15:22, Mark Rutland wrote:
Specifically, I think this does not align with the statement in 2.1
regarding the two TTBRs:
This simplifies privilege checks and does not require any address
translation for invalid memory accesses and thus no cache lookups.
... since the use of the
On 06.05.2017 10:38, Daniel Gruss wrote:
On 2017-05-06 06:02, David Gens wrote:
Assuming that their patch indeed leaks per-cpu addresses.. it might not
necessarily
be required to change it.
I think we're not leaking them (unless we still have some bug in our code).
Just to correct my a
On 08.05.2017 16:09, Thomas Garnier wrote:
Just to correct my answer here as well: Although we experimented with fixed
mappings for per-cpu addresses, the current patch does not incorporate this
yet, so it indeed still leaks. However, it is not a severe problem. The
mapping of the required (per-c
After several recent works [1,2,3] KASLR on x86_64 was basically
considered dead by many researchers. We have been working on an
efficient but effective fix for this problem and found that not mapping
the kernel space when running in user mode is the solution to this
problem [4] (the correspond
Sorry, missed a file in the first mail (from some code cleanup), the
full patch is now attached.
Cheers,
Daniel
>From c4b1831d44c6144d3762ccc72f0c4e71a0c713e5 Mon Sep 17 00:00:00 2001
From: Richard Fellner
Date: Thu, 4 May 2017 14:16:44 +0200
Subject: [PATCH] KAISER: Kernel Address Isolation
On 04.05.2017 17:47, Christoph Hellwig wrote:
I'll try to read the paper. In the meantime: how different is your
approach from then one here?
https://lwn.net/Articles/39283/
and how different is the performance impact?
The approach sounds very similar, but we have fewer changes becau
On 04.05.2017 17:28, Thomas Garnier wrote:
Please read the documentation on submitting patches [1] and coding style [2].
I will have a closer look at that.
- How this approach prevent the hardware attacks you mentioned? You
still have to keep a part of _text in the pagetable and an attacker
I think that this idea to mitigate Rowhammer is not a good approach.
I wrote Rowhammer.js (we published a paper on that) and I had the first
reproducible bit flips on DDR4 at both, increased and default refresh
rates (published in our DRAMA paper).
We have researched the number of cache misse
On 29.10.2016 21:42, Pavel Machek wrote:
Congratulations. Now I'd like to take away your toys :-).
I'm would like you to do that, but I'm very confident you're not
successful the way your starting ;)
Not in my testing.
Have you tried music/video reencoding? Games? Anything that works with
On 29.10.2016 23:05, Pavel Machek wrote:
So far I did bzip2 and kernel compilation. I believe I can prevent
flips in rowhammer-test with bzip2 going from 4 seconds to 5
seconds... let me see.
can you prevent bitflips in this one?
https://github.com/IAIK/rowhammerjs/tree/master/native
Ok, le
On 29.10.2016 23:45, Pavel Machek wrote:
indy/sandy/haswell/skylake, so I'll just use the generic version...?)
yes, generic might work, but i never tested it on anything that old...
on my system i have >30 bit flips per second (ivy bridge i5-3xxx) with
the rowhammer-ivy test... sometimes even
On 30.10.2016 00:01, Pavel Machek wrote:
Hmm, maybe I'm glad I don't have a new machine :-).
I assume you still get _some_ bitflips with generic "rowhammer"?
1 or 2 every 20-30 minutes...
On 01.11.2016 07:33, Ingo Molnar wrote:
Can you suggest a method to find heavily rowhammer affected hardware? Only by
testing it, or are there some chipset IDs ranges or dmidecode info that will
pinpoint potentially affected machines?
I have worked with many different systems both on running ro
On 01.11.2016 09:10, Pavel Machek wrote:
cpu family : 6
model: 23
model name : Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz
stepping : 10
microcode: 0xa07
so rowhammerjs/native is not available for this system. Bit mapping
for memory hash functions would
23 matches
Mail list logo
