On 19.03.2015 16:04, Vlastimil Babka wrote:
On 03/18/2015 12:41 PM, Konstantin Khlebnikov wrote:
On 18.03.2015 12:57, Kirill A. Shutemov wrote:
I don't think it worth it. The only right way to fix the problem is ECC
memory.
ECC seems good protection until somebody figure out how to break
On 03/18/2015 12:41 PM, Konstantin Khlebnikov wrote:
> On 18.03.2015 12:57, Kirill A. Shutemov wrote:
>>
>> I don't think it worth it. The only right way to fix the problem is ECC
>> memory.
>>
>
> ECC seems good protection until somebody figure out how to break it too.
I doubt that kind of
On 19.03.2015 16:04, Vlastimil Babka wrote:
On 03/18/2015 12:41 PM, Konstantin Khlebnikov wrote:
On 18.03.2015 12:57, Kirill A. Shutemov wrote:
I don't think it worth it. The only right way to fix the problem is ECC
memory.
ECC seems good protection until somebody figure out how to break
On 03/18/2015 12:41 PM, Konstantin Khlebnikov wrote:
On 18.03.2015 12:57, Kirill A. Shutemov wrote:
I don't think it worth it. The only right way to fix the problem is ECC
memory.
ECC seems good protection until somebody figure out how to break it too.
I doubt that kind of attitude can
On 03/18/2015 08:08 AM, Konstantin Khlebnikov wrote:
> It seems the only option is memory zoning: kernel should allocate all
> normal memory for userspace from isolated area which is kept far far
> away from important data.
Yeah, except that the kernel has a pretty hard time telling which data
is
On Wed, Mar 18, 2015 at 5:11 PM, Dave Hansen wrote:
> On 03/18/2015 01:30 AM, Konstantin Khlebnikov wrote:
>> + /*
>> + * Read-only SUID/SGID binares are mapped as copy-on-read
>> + * this protects them against exploiting with Rowhammer.
>> + */
On 03/18/2015 01:30 AM, Konstantin Khlebnikov wrote:
> + /*
> + * Read-only SUID/SGID binares are mapped as copy-on-read
> + * this protects them against exploiting with Rowhammer.
> + */
> + if (!(file->f_mode & FMODE_WRITE) &&
> +
On 18.03.2015 12:57, Kirill A. Shutemov wrote:
On Wed, Mar 18, 2015 at 11:30:40AM +0300, Konstantin Khlebnikov wrote:
From: Konstantin Khlebnikov
Each user gets private copy of the code thus nobody will be able to exploit
pages in the page cache. This works for statically-linked binaries.
On Wed, Mar 18, 2015 at 11:30:40AM +0300, Konstantin Khlebnikov wrote:
> From: Konstantin Khlebnikov
>
> Each user gets private copy of the code thus nobody will be able to exploit
> pages in the page cache. This works for statically-linked binaries. Shared
> libraries are still vulnerable, but
From: Konstantin Khlebnikov
Each user gets private copy of the code thus nobody will be able to exploit
pages in the page cache. This works for statically-linked binaries. Shared
libraries are still vulnerable, but setting suid bit will protect them too.
[1]
On Wed, Mar 18, 2015 at 11:30:40AM +0300, Konstantin Khlebnikov wrote:
From: Konstantin Khlebnikov khlebni...@yandex-team.ru
Each user gets private copy of the code thus nobody will be able to exploit
pages in the page cache. This works for statically-linked binaries. Shared
libraries are
From: Konstantin Khlebnikov khlebni...@yandex-team.ru
Each user gets private copy of the code thus nobody will be able to exploit
pages in the page cache. This works for statically-linked binaries. Shared
libraries are still vulnerable, but setting suid bit will protect them too.
[1]
On 18.03.2015 12:57, Kirill A. Shutemov wrote:
On Wed, Mar 18, 2015 at 11:30:40AM +0300, Konstantin Khlebnikov wrote:
From: Konstantin Khlebnikov khlebni...@yandex-team.ru
Each user gets private copy of the code thus nobody will be able to exploit
pages in the page cache. This works for
On Wed, Mar 18, 2015 at 5:11 PM, Dave Hansen dave.han...@intel.com wrote:
On 03/18/2015 01:30 AM, Konstantin Khlebnikov wrote:
+ /*
+ * Read-only SUID/SGID binares are mapped as copy-on-read
+ * this protects them against exploiting with Rowhammer.
+
On 03/18/2015 01:30 AM, Konstantin Khlebnikov wrote:
+ /*
+ * Read-only SUID/SGID binares are mapped as copy-on-read
+ * this protects them against exploiting with Rowhammer.
+ */
+ if (!(file-f_mode FMODE_WRITE)
+
On 03/18/2015 08:08 AM, Konstantin Khlebnikov wrote:
It seems the only option is memory zoning: kernel should allocate all
normal memory for userspace from isolated area which is kept far far
away from important data.
Yeah, except that the kernel has a pretty hard time telling which data
is
16 matches
Mail list logo
