RAMBLEED - rowhammer exploit can read memory

https://rambleed.com/

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0174

Not known to have been exploited in the wild.

RAMBleed uses Rowhammer for reading data stored inside the computer's physical memory. As the physical memory is shared among all process in the system, this puts all processes at risk.

RAMBleed relies on Rowhammer-induced bit flips to read privileged memory. As such, any system that uses Rowhammer-susceptible DIMMs is vulnerable. Previous research has demonstrated bit flips on both DDR3 and DDR4 with TRR (targeted row refresh) enabled. While we demonstrated our attack on a desktop machine and an ECC enabled server machine, Rowhammer attacks have been demonstrated against both mobile devices and laptops. As such, we suspect that many classes of computers are susceptible to RAMBleed.

Users can mitigate their risk by upgrading their memory to DDR4 with targeted row refresh (TRR) enabled. While Rowhammer-induced bit flips have been demonstrated on TRR, it is harder to accomplish in practice.

Memory manufacturers can help mitigate this issue by more rigorously testing for faulty DIMMs. Furthermore, publicly documenting vendor specific TRR implementations will facilitate a stronger development process as security researchers probe such implementations for weaknesses.

2 Likes

Oo great. A threat that date back to 2016. And still a threat now. WTF.

Ok. About the TRR part. Is this something that enable and disable by the kernel or motherboard? This part remain unclear to me.

it's enabled by checking with the manufacturer to see if your current sticks have it and buying different ram if they don't.

It seem I don't need to worry about this on my 3 computer. Main computer used desktop ddr 4. My intel nuc used laptop ddr 4. Laptop used LPDDR3. Tested all three them using MemTest86 (Hammer Test). All 3 pass without any error.
Unless the hammer test was the wrong one. Then IDK. And no. I'm not contacting manufacturer when they don't even list the damn TRR as a feature.

Another possible mitigation is the use of memory encryption on newer AMD/Intel systems.

DDR4 also seems to be concerned, it's just more difficult to exploit ("we do not suspect DDR4 to be a fundamental limitation").

Care to explain how to that? I'm sure I can do it on my Ryzen 2700x. But unsure if that can be done on my Intel nuc skylake.

lscpu | grep sme
see if it turns up roses
(sme is secure memory encryption - it should be enabled by bios or firmware)

Hmm.. Did some digging and it looks like its a combo ..
First you need hardware that supports it.
Then your BIOS/firmware needs to enable it.
Then, depending on if your BIOS merely 'enables' SME but does not 'activate' it you can tell the kernel to do so (kernel support SME) by using this in grub params:

mem_encrypt=on

[I have done no testing - this is just some docs regurgitation]

Will. I got it working. So far. The one downside is nvidia driver don't work. I had to switch to nouveau. :slightly_frowning_face::cry:

[Update]
Fix most my issue with nouveau my switching to modesetting + compton

compton -CGzb --backend xr_glx_hybrid --vsync opengl-mswc --vsync-use-glfinish --paint-on-overlay --unredir-if-possible --glx-no-rebind-pixmap --glx-swap-method buffer-age --glx-swap-method 5 --xrender-sync --xrender-sync-fence

[Compton Update 2]

compton -CGb --backend glx --vsync opengl --vsync-use-glfinish --xrender-sync-fence --unredir-if-possible --glx-no-stencil --glx-no-rebind-pixmap --glx-swap-method copy --glx-swap-method -1 --refresh-rate 75

I upgrade compton. So I made some change over my old setup. I would have used --vsync opengl-swc. But it run really bad on my dual monitor set up. If you have single monitor. Then --vsync opengl-swc will be a great option. I add refresh rate change. So this way I can keep both monitor at max refresh rate 60 without it feeling like it dropping frames.

And I hope this is my last compton change. This is so much closer to using nvidia driver now.


Not sure if having two different --glx-swap-method is doing anything. But I been playing around with it.

Making one last update on this. TBH I was not happy with compton. So I started looking at desktop and window manager that have built in compositor. And boy I'm not fan of a lot desktop anymore. Mostly cuz I don't need all them eye candy stuff anymore. And manage to settle with Enlightenment. So why does nvidia driver don't work? I think it have something to do with DMA not allowing to get through. So, for this to work with nvidia driver. nvidia need to make source to work with DMA when SME is active. Witch I highly doubt there going to do. Making this post for other people that dare to try this with nvidia card. Know what there getting into. Know what to do when making the change. Yes, I'm still using modesetting witch still used nouveau. I guess it a better front end to it???? Anyway. Here my dmesg log.

[days@naia:~]$ dmesg | grep '(SME)'
[    0.000000] AMD Secure Memory Encryption (SME) active

[days@naia:~]$ dmesg | grep DMA
[    0.000000]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
[    0.000000]   DMA32    [mem 0x0000000001000000-0x00000000ffffffff]
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 27 pages reserved
[    0.000000]   DMA zone: 3999 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 14028 pages used for memmap
[    0.000000]   DMA32 zone: 897772 pages, LIFO batch:63
[    0.196347] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    0.301436] ata1: SATA max UDMA/133 abar m131072@0xf7680000 port 0xf7680100 irq 48
[    0.301438] ata2: SATA max UDMA/133 abar m131072@0xf7680000 port 0xf7680180 irq 48
[    0.301439] ata3: SATA max UDMA/133 abar m131072@0xf7680000 port 0xf7680200 irq 48
[    0.301440] ata4: SATA max UDMA/133 abar m131072@0xf7680000 port 0xf7680280 irq 48
[    0.301441] ata5: SATA max UDMA/133 abar m131072@0xf7680000 port 0xf7680300 irq 48
[    0.301443] ata6: SATA max UDMA/133 abar m131072@0xf7680000 port 0xf7680380 irq 48
[    0.301444] ata7: SATA max UDMA/133 abar m131072@0xf7680000 port 0xf7680400 irq 48
[    0.301445] ata8: SATA max UDMA/133 abar m131072@0xf7680000 port 0xf7680480 irq 48
[    0.301845] ata9: SATA max UDMA/133 abar m512@0xf7400000 port 0xf7400100 irq 49
[    0.301847] ata10: SATA max UDMA/133 abar m512@0xf7400000 port 0xf7400180 irq 49
[    0.302073] ata11: SATA max UDMA/133 abar m4096@0xf7a08000 port 0xf7a08100 irq 51
[    0.782747] ata9.00: ATA-9: Crucial_CT512MX100SSD1, MU01, max UDMA/133
[    0.823687] ata9.00: configured for UDMA/133
[    2.365024] ata6.00: ATA-10: ST2000LM007-1R8174, SBK2, max UDMA/133
[    2.484101] ata6.00: configured for UDMA/133
[    5.541412] snd_hda_intel 0000:23:00.1: SME is active, device will require DMA bounce buffers
[    5.541412] snd_hda_intel 0000:23:00.1: SME is active, device will require DMA bounce buffers
[    5.541534] snd_hda_intel 0000:25:00.3: SME is active, device will require DMA bounce buffers
[    5.541535] snd_hda_intel 0000:25:00.3: SME is active, device will require DMA bounce buffers
[    5.577838] iwlwifi 0000:1c:00.0: SME is active, device will require DMA bounce buffers
[    5.577839] iwlwifi 0000:1c:00.0: SME is active, device will require DMA bounce buffers
[    5.646313] nouveau 0000:23:00.0: SME is active, device will require DMA bounce buffers
[    5.646314] nouveau 0000:23:00.0: SME is active, device will require DMA bounce buffers
[    5.744960] nouveau 0000:23:00.0: SME is active, device will require DMA bounce buffers
[    5.744961] nouveau 0000:23:00.0: SME is active, device will require DMA bounce buffers
[    5.833975] [TTM] Initializing DMA pool allocator

[days@naia:~]$ dmesg | grep fb
[    0.000000] BIOS-e820: [mem 0x00000000dc279000-0x00000000dc3fbfff] usable
[    0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000dc279000-0x00000000dc3fbfff] usable
[    0.000000] reserve setup_data: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000]   node   0: [mem 0x00000000dc279000-0x00000000dc3fbfff]
[    0.000000] PM: Registered nosave memory: [mem 0xf8000000-0xfbffffff]
[    0.033399] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000)
[    0.033399] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in E820
[    0.059623] pci 0000:1c:00.0: [8086:24fb] type 00 class 0x028000
[    0.061115] pci 0000:23:00.0: BAR 3: assigned to efifb
[    0.061224] pci 0000:23:00.1: [10de:0fba] type 00 class 0x040300
[    0.102427] system 00:00: [mem 0xf8000000-0xfbffffff] has been reserved
[    0.204334] efifb: probing for efifb
[    0.204341] efifb: framebuffer at 0xf1000000, using 14400k, total 14400k
[    0.204342] efifb: mode is 2560x1440x32, linelength=10240, pages=1
[    0.204342] efifb: scrolling: redraw
[    0.204342] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    0.209523] fb0: EFI VGA frame buffer device
[    0.301942] ahci 0000:25:00.2: flags: 64bit ncq sntf ilck pm led clo only pmp fbs pio slum part 
[    5.646340] fb0: switching to nouveaufb from EFI VGA
[    5.745248] nouveau 0000:23:00.0: fb: 2048 MiB GDDR5
[    6.352796] nouveau 0000:23:00.0: DRM: allocated 2560x1440 fb: 0xa0000, bo 00000000c511070f
[    6.353499] fbcon: nouveaufb (fb0) is primary device
[    6.740524] nouveau 0000:23:00.0: fb0: nouveaufb frame buffer device