Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
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 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 >>> replacement algorithm could make the attacks interesting. >> >> I've been thinking the same. But maybe having to evict e.g. 16-way cache >> would >> mean accessing 16x more lines which could reduce the frequency for a single >> line >> below dangerous levels. Worth trying, though :) > > How many ways do recent CPU L1 caches have? My i7 based desktop has 8-way L1, 8-way L2, 16-way L3. And it seems to be alarmingly vulnerable to the double-sided rowhammer variant. But to reliably miss L3 it seems I need at least 96 addresses colliding in L3, which are then also in different dram rows. Which naturally reduces frequency for the target pair of rows. I've been able so far to reduce/mask the overhead so that the target rows are accessed with 11x lower frequency than with clflush. Which doesn't seem enough to trigger bit flips. But maybe I can improve it further :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
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 > >>> should make it no longer exploitable. > >> > >> Unfortunately there's no way to disable userland code's use of > >> CLFLUSH, as far as I know. > >> > >> Maybe Intel or AMD could disable CLFLUSH via a microcode update, but > >> they have not said whether that would be possible. > > > > 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 > > replacement algorithm could make the attacks interesting. > > I've been thinking the same. But maybe having to evict e.g. 16-way cache would > mean accessing 16x more lines which could reduce the frequency for a single > line > below dangerous levels. Worth trying, though :) How many ways do recent CPU L1 caches have? > BTW, by using clever access patterns and measurement of access latencies one > could also possibly determine which cache lines alias/colide, without needing > to > read pagemap. It would just take longer. Hugepages make that simpler as well. > > I just hope we are not going to disable lots of stuff including clflush and > e.g. > transparent hugepages just because some part of the currently sold hardware is > vulnerable... Well, "some part" seems to be > 50% of all machines without ECC, which means > 50% notebooks. If your machine is not affected, disabling clflush will not be neccessary. But... I'd still like separate users on my machines to be separated (I use separate acount for browsing with Flash), and Android actually relies on that. And if it is exploitable without clflush, that's _bad_, because it means you can probably exploit it using Java/JavaScript from web browser. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rowhammer and pagemap (was Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace)
> > > 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 > > > replacement algorithm could make the attacks interesting. > > > > We should definitely get Intel/AMD to disable CLFLUSH, then. > > I doubt that would work, because you'd have to fix up all the faults from > userspace in things like graphics and video. Whether it is possible to > make the microcode do other accesses and delays I have no idea - but > that might also be quite horrible. > > A serious system should be using ECC memory anyway. and on things like > shared boxes it is probably not a root compromise that is the worst case > scenario but subtle undetected corruption of someone elses data > sets. Both are bad. It is fairly hard to do rowhammer by accident, so if you are hitting it, someone is probably doing it on purpose. And cloud providers seem to be case of "serious systems" without ECC... (I seem to remember accidental rowhammer with spinlocks, will have to check that again). > That's what ECC already exists to protect against whether its from flawed > memory and rowhammer or just a vindictive passing cosmic ray. Well, there's more than thre orders of magnitude difference between cosmic rays and rowhammer. IIRC cosmic rays are expected to cause 2 bit flips a year... rowhammer can do bitflip in 10 minutes, and that is old version, not one of the optimized ones. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
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 there's no way to disable userland code's use of >> CLFLUSH, as far as I know. >> >> Maybe Intel or AMD could disable CLFLUSH via a microcode update, but >> they have not said whether that would be possible. > > 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 > replacement algorithm could make the attacks interesting. I've been thinking the same. But maybe having to evict e.g. 16-way cache would mean accessing 16x more lines which could reduce the frequency for a single line below dangerous levels. Worth trying, though :) BTW, by using clever access patterns and measurement of access latencies one could also possibly determine which cache lines alias/colide, without needing to read pagemap. It would just take longer. Hugepages make that simpler as well. I just hope we are not going to disable lots of stuff including clflush and e.g. transparent hugepages just because some part of the currently sold hardware is vulnerable... Vlastimil > --Andy > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org";> em...@kvack.org > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rowhammer and pagemap (was Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace)
> > 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. > > 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 > > replacement algorithm could make the attacks interesting. > > We should definitely get Intel/AMD to disable CLFLUSH, then. I doubt that would work, because you'd have to fix up all the faults from userspace in things like graphics and video. Whether it is possible to make the microcode do other accesses and delays I have no idea - but that might also be quite horrible. A serious system should be using ECC memory anyway. and on things like shared boxes it is probably not a root compromise that is the worst case scenario but subtle undetected corruption of someone elses data sets. That's what ECC already exists to protect against whether its from flawed memory and rowhammer or just a vindictive passing cosmic ray. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
rowhammer and pagemap (was Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace)
> > 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 read > addresses that are severely scrambled (e.g. ECB-encrypted by a key > generated once per open of pagemap). > - It could easily leak direct-map addresses, and there's a nice paper > detailing a SMAP bypass using that technique. Do you have a pointer? > Can we just try getting rid of it except with global CAP_SYS_ADMIN. > > (Hmm. Rowhammer attacks targeting SMRAM could be interesting.) :-). > >> Can we do anything about that? Disabling cache flushes from userland > >> should make it no longer exploitable. > > > > Unfortunately there's no way to disable userland code's use of > > CLFLUSH, as far as I know. > > > > Maybe Intel or AMD could disable CLFLUSH via a microcode update, but > > they have not said whether that would be possible. > > 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 > replacement algorithm could make the attacks interesting. We should definitely get Intel/AMD to disable CLFLUSH, then. Because if it can be exploited using reads, it is _extremely_ important to know. As it probably means rowhammer can be exploited using Javascript / Java... and affected machines are unsafe even without remote users. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
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 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] >> > http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html >> >> Note that this kind of attack still works without pagemap, it just >> takes longer. Actually the first demo program is not using pagemap. > > That depends on the machine -- it depends on how bad the machine's > DRAM is, and whether the machine has the 2x refresh rate mitigation > enabled. > > Machines with less-bad DRAM or with a 2x refresh rate might still be > vulnerable to rowhammer, but only if the attacker has access to huge > pages or to /proc/PID/pagemap. > > /proc/PID/pagemap also gives an attacker the ability to scan for bad > DRAM locations, save a list of their addresses, and exploit them in > the future. > > 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 read addresses that are severely scrambled (e.g. ECB-encrypted by a key generated once per open of pagemap). Pagemap is awful because: - Rowhammer. - It exposes internals that users have no business knowing. - It could easily leak direct-map addresses, and there's a nice paper detailing a SMAP bypass using that technique. Can we just try getting rid of it except with global CAP_SYS_ADMIN. (Hmm. Rowhammer attacks targeting SMRAM could be interesting.) > > >> Can we do anything about that? Disabling cache flushes from userland >> should make it no longer exploitable. > > Unfortunately there's no way to disable userland code's use of > CLFLUSH, as far as I know. > > Maybe Intel or AMD could disable CLFLUSH via a microcode update, but > they have not said whether that would be possible. 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 replacement algorithm could make the attacks interesting. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
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 > > attacks. > > > > This is RFC patch which disallow anybody without CAP_SYS_ADMIN to read > > the pagemap. > > > > Any comments? > > > > [1] > > http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html > > Note that this kind of attack still works without pagemap, it just > takes longer. Actually the first demo program is not using pagemap. That depends on the machine -- it depends on how bad the machine's DRAM is, and whether the machine has the 2x refresh rate mitigation enabled. Machines with less-bad DRAM or with a 2x refresh rate might still be vulnerable to rowhammer, but only if the attacker has access to huge pages or to /proc/PID/pagemap. /proc/PID/pagemap also gives an attacker the ability to scan for bad DRAM locations, save a list of their addresses, and exploit them in the future. Given that, I think it would still be worthwhile to disable /proc/PID/pagemap. > Can we do anything about that? Disabling cache flushes from userland > should make it no longer exploitable. Unfortunately there's no way to disable userland code's use of CLFLUSH, as far as I know. Maybe Intel or AMD could disable CLFLUSH via a microcode update, but they have not said whether that would be possible. Cheers, Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
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 CAP_SYS_ADMIN to read > the pagemap. > > Any comments? > > [1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html Note that this kind of attack still works without pagemap, it just takes longer. Actually the first demo program is not using pagemap. Can we do anything about that? Disabling cache flushes from userland should make it no longer exploitable. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
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 mount option > stuff is hideous. So, per-pidns == bad per-ns == good If the pid namespace is the wrong place, which namespace is the right place? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
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
>> attacks.
>>
>> This is RFC patch which disallow anybody without CAP_SYS_ADMIN to read
>> the pagemap.
>>
>> Any comments?
>
> I prefer Dave Hansen's approach:
>
> http://www.spinics.net/lists/kernel/msg1941939.html
>
> This gives finer grained control without globally dropping the ability
> of a non-root process to examine pagemap details (which is the whole
> point of the interface).
per-pidns like this is no good. You shouldn't be able to create a
non-paranoid pidns if your parent is paranoid.
Also, at some point we need actual per-ns controls. This mount option
stuff is hideous.
--Andy
>
> -Kees
>
>>
>> [1]
>> http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
>>
>> Signed-off-by: Kirill A. Shutemov
>> Cc: Pavel Emelyanov
>> Cc: Konstantin Khlebnikov
>> Cc: Andrew Morton
>> Cc: Linus Torvalds
>> Cc: Mark Seaborn
>> Cc: Andy Lutomirski
>> ---
>> fs/proc/task_mmu.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
>> index 246eae84b13b..b72b36e64286 100644
>> --- a/fs/proc/task_mmu.c
>> +++ b/fs/proc/task_mmu.c
>> @@ -1322,6 +1322,9 @@ out:
>>
>> static int pagemap_open(struct inode *inode, struct file *file)
>> {
>> + /* do not disclose physical addresses: attack vector */
>> + if (!capable(CAP_SYS_ADMIN))
>> + return -EPERM;
>> pr_warn_once("Bits 55-60 of /proc/PID/pagemap entries are about "
>> "to stop being page-shift some time soon. See the "
>> "linux/Documentation/vm/pagemap.txt for details.\n");
>> --
>> 2.3.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
> --
> Kees Cook
> Chrome OS Security
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
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 without CAP_SYS_ADMIN to read
> the pagemap.
>
> Any comments?
I prefer Dave Hansen's approach:
http://www.spinics.net/lists/kernel/msg1941939.html
This gives finer grained control without globally dropping the ability
of a non-root process to examine pagemap details (which is the whole
point of the interface).
-Kees
>
> [1]
> http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
>
> Signed-off-by: Kirill A. Shutemov
> Cc: Pavel Emelyanov
> Cc: Konstantin Khlebnikov
> Cc: Andrew Morton
> Cc: Linus Torvalds
> Cc: Mark Seaborn
> Cc: Andy Lutomirski
> ---
> fs/proc/task_mmu.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 246eae84b13b..b72b36e64286 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1322,6 +1322,9 @@ out:
>
> static int pagemap_open(struct inode *inode, struct file *file)
> {
> + /* do not disclose physical addresses: attack vector */
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> pr_warn_once("Bits 55-60 of /proc/PID/pagemap entries are about "
> "to stop being page-shift some time soon. See the "
> "linux/Documentation/vm/pagemap.txt for details.\n");
> --
> 2.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
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 without CAP_SYS_ADMIN to read
> the pagemap.
>
> Any comments?
>
> [1]
> http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
>
> Signed-off-by: Kirill A. Shutemov
> Cc: Pavel Emelyanov
> Cc: Konstantin Khlebnikov
> Cc: Andrew Morton
> Cc: Linus Torvalds
> Cc: Mark Seaborn
> Cc: Andy Lutomirski
> ---
> fs/proc/task_mmu.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 246eae84b13b..b72b36e64286 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1322,6 +1322,9 @@ out:
>
> static int pagemap_open(struct inode *inode, struct file *file)
> {
> + /* do not disclose physical addresses: attack vector */
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
This interface is connected to /proc/kpagecount, /proc/kpageflags
and these files are readable only by root. So it's fine, but it's might
be better to change here file owner to root too.
> pr_warn_once("Bits 55-60 of /proc/PID/pagemap entries are about "
> "to stop being page-shift some time soon. See the "
> "linux/Documentation/vm/pagemap.txt for details.\n");
> --
> 2.3.1
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
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 CAP_SYS_ADMIN to read
> the pagemap.
>
> Any comments?
If I'm not mistaken, the pagemap file is used by some userspace that does
working-set size analysis. But this thing only needs the flags (referenced
bit) from the PTE-s. Maybe it would be better not to lock this file completely,
but instead report the PFN part as zero?
Other than this, I don't mind :) Although we use this heavily in CRIU we
anyway work only with the CAP_SYS_ADMIN, so adding the new one doesn't hurt.
Thanks,
Pavel
> [1]
> http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
>
> Signed-off-by: Kirill A. Shutemov
> Cc: Pavel Emelyanov
> Cc: Konstantin Khlebnikov
> Cc: Andrew Morton
> Cc: Linus Torvalds
> Cc: Mark Seaborn
> Cc: Andy Lutomirski
> ---
> fs/proc/task_mmu.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 246eae84b13b..b72b36e64286 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1322,6 +1322,9 @@ out:
>
> static int pagemap_open(struct inode *inode, struct file *file)
> {
> + /* do not disclose physical addresses: attack vector */
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> pr_warn_once("Bits 55-60 of /proc/PID/pagemap entries are about "
> "to stop being page-shift some time soon. See the "
> "linux/Documentation/vm/pagemap.txt for details.\n");
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace
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]
http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
Signed-off-by: Kirill A. Shutemov
Cc: Pavel Emelyanov
Cc: Konstantin Khlebnikov
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Mark Seaborn
Cc: Andy Lutomirski
---
fs/proc/task_mmu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 246eae84b13b..b72b36e64286 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1322,6 +1322,9 @@ out:
static int pagemap_open(struct inode *inode, struct file *file)
{
+ /* do not disclose physical addresses: attack vector */
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
pr_warn_once("Bits 55-60 of /proc/PID/pagemap entries are about "
"to stop being page-shift some time soon. See the "
"linux/Documentation/vm/pagemap.txt for details.\n");
--
2.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
