On 23.3.2015 22:26, Pavel Machek wrote:
> On Thu 2015-03-19 13:51:02, Vlastimil Babka wrote:
>> On 03/17/2015 02:21 AM, Andy Lutomirski wrote:
>>> On Mon, Mar 16, 2015 at 5:49 PM, Mark Seaborn wrote:
>>>
>>> The Intel people I asked last week weren't confident. For one thing,
>>> I fully expect
On Thu 2015-03-19 13:51:02, Vlastimil Babka wrote:
> On 03/17/2015 02:21 AM, Andy Lutomirski wrote:
> > On Mon, Mar 16, 2015 at 5:49 PM, Mark Seaborn wrote:
> >> On 16 March 2015 at 14:11, Pavel Machek wrote:
> >>
> >>> Can we do anything about that? Disabling cache flushes from userland
> >>>
> > > The Intel people I asked last week weren't confident. For one thing,
> > > I fully expect that rowhammer can be exploited using only reads and
> > > writes with some clever tricks involving cache associativity. I don't
> > > think there are any fully-associative caches, although the cache
On Thu 2015-03-19 13:51:02, Vlastimil Babka wrote:
On 03/17/2015 02:21 AM, Andy Lutomirski wrote:
On Mon, Mar 16, 2015 at 5:49 PM, Mark Seaborn mseab...@chromium.org wrote:
On 16 March 2015 at 14:11, Pavel Machek pa...@ucw.cz wrote:
Can we do anything about that? Disabling cache flushes
The Intel people I asked last week weren't confident. For one thing,
I fully expect that rowhammer can be exploited using only reads and
writes with some clever tricks involving cache associativity. I don't
think there are any fully-associative caches, although the cache
On 23.3.2015 22:26, Pavel Machek wrote:
On Thu 2015-03-19 13:51:02, Vlastimil Babka wrote:
On 03/17/2015 02:21 AM, Andy Lutomirski wrote:
On Mon, Mar 16, 2015 at 5:49 PM, Mark Seaborn mseab...@chromium.org wrote:
The Intel people I asked last week weren't confident. For one thing,
I fully
On 03/17/2015 02:21 AM, Andy Lutomirski wrote:
> On Mon, Mar 16, 2015 at 5:49 PM, Mark Seaborn wrote:
>> On 16 March 2015 at 14:11, Pavel Machek wrote:
>>
>>> Can we do anything about that? Disabling cache flushes from userland
>>> should make it no longer exploitable.
>>
>> Unfortunately
On 03/17/2015 02:21 AM, Andy Lutomirski wrote:
On Mon, Mar 16, 2015 at 5:49 PM, Mark Seaborn mseab...@chromium.org wrote:
On 16 March 2015 at 14:11, Pavel Machek pa...@ucw.cz wrote:
Can we do anything about that? Disabling cache flushes from userland
should make it no longer exploitable.
> > Can we just try getting rid of it except with global CAP_SYS_ADMIN.
> >
> > (Hmm. Rowhammer attacks targeting SMRAM could be interesting.)
>
CAP_SYS_RAWIO is the protection for "can achieve anything". If you have
CAP_SYS_RAWIO you can attain any other capability, the reverse _should_
not
> > Given that, I think it would still be worthwhile to disable
> > /proc/PID/pagemap.
>
> Having slept on this further, I think that unprivileged pagemap access
> is awful and we should disable it with no option to re-enable. If we
> absolutely must, we could allow programs to read all zeros
Can we just try getting rid of it except with global CAP_SYS_ADMIN.
(Hmm. Rowhammer attacks targeting SMRAM could be interesting.)
CAP_SYS_RAWIO is the protection for can achieve anything. If you have
CAP_SYS_RAWIO you can attain any other capability, the reverse _should_
not be true.
Given that, I think it would still be worthwhile to disable
/proc/PID/pagemap.
Having slept on this further, I think that unprivileged pagemap access
is awful and we should disable it with no option to re-enable. If we
absolutely must, we could allow programs to read all zeros or to
On Mon, Mar 16, 2015 at 5:49 PM, Mark Seaborn wrote:
> On 16 March 2015 at 14:11, Pavel Machek wrote:
>> On Mon 2015-03-09 23:11:12, Kirill A. Shutemov wrote:
>> > From: "Kirill A. Shutemov"
>> >
>> > As pointed by recent post[1] on exploiting DRAM physical imperfection,
>> > /proc/PID/pagemap
On 16 March 2015 at 14:11, Pavel Machek wrote:
> On Mon 2015-03-09 23:11:12, Kirill A. Shutemov wrote:
> > From: "Kirill A. Shutemov"
> >
> > As pointed by recent post[1] on exploiting DRAM physical imperfection,
> > /proc/PID/pagemap exposes sensitive information which can be used to do
> >
On Mon 2015-03-09 23:11:12, Kirill A. Shutemov wrote:
> From: "Kirill A. Shutemov"
>
> As pointed by recent post[1] on exploiting DRAM physical imperfection,
> /proc/PID/pagemap exposes sensitive information which can be used to do
> attacks.
>
> This is RFC patch which disallow anybody without
On Mon, Mar 16, 2015 at 5:49 PM, Mark Seaborn mseab...@chromium.org wrote:
On 16 March 2015 at 14:11, Pavel Machek pa...@ucw.cz wrote:
On Mon 2015-03-09 23:11:12, Kirill A. Shutemov wrote:
From: Kirill A. Shutemov kirill.shute...@linux.intel.com
As pointed by recent post[1] on exploiting
On 16 March 2015 at 14:11, Pavel Machek pa...@ucw.cz wrote:
On Mon 2015-03-09 23:11:12, Kirill A. Shutemov wrote:
From: Kirill A. Shutemov kirill.shute...@linux.intel.com
As pointed by recent post[1] on exploiting DRAM physical imperfection,
/proc/PID/pagemap exposes sensitive information
On Mon 2015-03-09 23:11:12, Kirill A. Shutemov wrote:
From: Kirill A. Shutemov kirill.shute...@linux.intel.com
As pointed by recent post[1] on exploiting DRAM physical imperfection,
/proc/PID/pagemap exposes sensitive information which can be used to do
attacks.
This is RFC patch which
On 03/09/2015 05:19 PM, Andy Lutomirski wrote:
> per-pidns like this is no good. You shouldn't be able to create a
> non-paranoid pidns if your parent is paranoid.
That sounds like a reasonable addition that shouldn't be hard to add.
> Also, at some point we need actual per-ns controls. This
On Mon, Mar 9, 2015 at 5:11 PM, Kees Cook wrote:
> On Mon, Mar 9, 2015 at 2:11 PM, Kirill A. Shutemov
> wrote:
>> From: "Kirill A. Shutemov"
>>
>> As pointed by recent post[1] on exploiting DRAM physical imperfection,
>> /proc/PID/pagemap exposes sensitive information which can be used to do
On Mon, Mar 9, 2015 at 2:11 PM, Kirill A. Shutemov wrote:
> From: "Kirill A. Shutemov"
>
> As pointed by recent post[1] on exploiting DRAM physical imperfection,
> /proc/PID/pagemap exposes sensitive information which can be used to do
> attacks.
>
> This is RFC patch which disallow anybody
On Tue, Mar 10, 2015 at 12:11 AM, Kirill A. Shutemov
wrote:
> From: "Kirill A. Shutemov"
>
> As pointed by recent post[1] on exploiting DRAM physical imperfection,
> /proc/PID/pagemap exposes sensitive information which can be used to do
> attacks.
>
> This is RFC patch which disallow anybody
On 03/10/2015 12:11 AM, Kirill A. Shutemov wrote:
> From: "Kirill A. Shutemov"
>
> As pointed by recent post[1] on exploiting DRAM physical imperfection,
> /proc/PID/pagemap exposes sensitive information which can be used to do
> attacks.
>
> This is RFC patch which disallow anybody without
From: "Kirill A. Shutemov"
As pointed by recent post[1] on exploiting DRAM physical imperfection,
/proc/PID/pagemap exposes sensitive information which can be used to do
attacks.
This is RFC patch which disallow anybody without CAP_SYS_ADMIN to read
the pagemap.
Any comments?
[1]
From: Kirill A. Shutemov kirill.shute...@linux.intel.com
As pointed by recent post[1] on exploiting DRAM physical imperfection,
/proc/PID/pagemap exposes sensitive information which can be used to do
attacks.
This is RFC patch which disallow anybody without CAP_SYS_ADMIN to read
the pagemap.
On 03/10/2015 12:11 AM, Kirill A. Shutemov wrote:
From: Kirill A. Shutemov kirill.shute...@linux.intel.com
As pointed by recent post[1] on exploiting DRAM physical imperfection,
/proc/PID/pagemap exposes sensitive information which can be used to do
attacks.
This is RFC patch which
On Tue, Mar 10, 2015 at 12:11 AM, Kirill A. Shutemov
kir...@shutemov.name wrote:
From: Kirill A. Shutemov kirill.shute...@linux.intel.com
As pointed by recent post[1] on exploiting DRAM physical imperfection,
/proc/PID/pagemap exposes sensitive information which can be used to do
attacks.
On Mon, Mar 9, 2015 at 2:11 PM, Kirill A. Shutemov kir...@shutemov.name wrote:
From: Kirill A. Shutemov kirill.shute...@linux.intel.com
As pointed by recent post[1] on exploiting DRAM physical imperfection,
/proc/PID/pagemap exposes sensitive information which can be used to do
attacks.
On Mon, Mar 9, 2015 at 5:11 PM, Kees Cook keesc...@chromium.org wrote:
On Mon, Mar 9, 2015 at 2:11 PM, Kirill A. Shutemov kir...@shutemov.name
wrote:
From: Kirill A. Shutemov kirill.shute...@linux.intel.com
As pointed by recent post[1] on exploiting DRAM physical imperfection,
On 03/09/2015 05:19 PM, Andy Lutomirski wrote:
per-pidns like this is no good. You shouldn't be able to create a
non-paranoid pidns if your parent is paranoid.
That sounds like a reasonable addition that shouldn't be hard to add.
Also, at some point we need actual per-ns controls. This
30 matches
Mail list logo
