View Issue Details

IDProjectCategoryView StatusLast Update
0007552Kali Linux[All Projects] General Bugpublic2022-06-28 11:55
Reportermax06 Assigned Tosbrun  
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionopen 
Product Version2021.4 
Target VersionFixed in Version 
Summary0007552: Popping Balloons
DescriptionA default Kali installation (or the live cd) in a virtual machine on hyper-v starts eating up all available memory shortly after logging in into xfce.
The consumption only shows in the hyper-v console, not in the guest itself.
It stops when the max. configured memory is reached. This might be 1TB of ram on a fresh vm without configuration changes, which basically breaks everything. Dynamic memory needs to be enabled for this (by default).
Steps To ReproduceCreate a new Hyper-V VM. (Recommendation: Don't use quick create.)
I went with
 - Generation 2
 - 1GB initial memory with dynamic memory active
 - the default switch
 - a new Harddrive (5Gb) which won't be used
 - and the kali live cd image as boot device

You can also install Kali with the default options, it won't change the result.

Before you start the instance: Edit its properties, disable secure boot and set a reasonable memory limit (16Gb here).

Watch the memory tab in the hyper-v manager once the instance booted. It might take 2-3 minutes for the data to show up. You won't see the consumed memory in the guest itself.

If the issue is reproducable: The memory balloon with grow and ultimately block your system once swapping starts.
Additional InformationWhen you run the instance without configuring a lower memory limit (overprovisioning), it will eventually create log entries about unhandled hv_ballooning events. Those happen so rapidly, they wrote 70GB of logs here in less than 20 minutes.

I tested the same scenario with an ubuntu live cd, it doesn't happen there. Also the rate of updates about the memory usage for the hypervisor is way faster, like one per second. With kali, it's something between 30s and a minute.

The effect only starts after being logged in. There's no difference if it's the regular console of the extended thingie with xrdp. Logging out/closing the console has no effect.

Relationships

has duplicate 0007602 closeddaniruiz Popping Balloons (in 2022.1) 

Activities

max06

2022-01-29 21:50

reporter   ~0015676

Sorry about the title, I had to... feel free to change that to something more suitable.

max06

2022-02-12 13:15

reporter   ~0015720

It's been 2 weeks. And... nothing? Really?

max06

2022-03-10 19:59

reporter   ~0015844

Congratulations. Absolute no reaction at all, except if you "need to" close duplicates.

The overall activity on this bugtracker doesn't promise good things. I can't recommend offensive security for our pen testers...

arnaudr

2022-03-11 02:37

manager   ~0015845

Hi,

> The overall activity on this bugtracker doesn't promise good things. I can't recommend offensive security for our pen testers...

There seems to be some misunderstanding about this bugtracker. Here's a a place where you report what you think might be bugs in Kali. If there's something we (Kali developers) can do about it, we answer and discuss the issue. OTOH, if there's nothing we can do about it, or if we think it's not a bug in Kali, then we'll close the bug report.

In this case, I think there's something wrong with your setup. If Kali was universally broken in Hyper-V, this bug report would have turned into an active conversation, with many other users joining and reporting the same issue. But it did not happen, nobody else reported a similar issue. Therefore it seems to be a problem on your side. I recommend that you try https://forums.kali.org/ or the Kali IRC channel. Thanks.

max06

2022-03-13 13:12

reporter   ~0015878

Hi,

> If Kali was universally broken in Hyper-V
You mean if people were knowing and actually using Hyper-V (Win X Pro only!) instead of VirtualBox, VMware player, or your WSL-Implementation.

> this bug report would have turned into an active conversation
When I opened this report, the overall activity here was at 0000020:0000010 posts every 7 days.

> Therefore it seems to be a problem on your side.
That's why there are steps to reproduce the issue. I "expected" one of you trying this, for confirming or contradicting my report, instead of "probably caused by his setup, let's not respond at all until he finds out on his own".

Talking about my setup: I'm using this system for a very long time now for daily business, without any issues. I even fired up another live distribution for testing and to confirm, the guest integration actually works as expected. I even narrowed it down to being related to the graphical interface. If I'd have had another hyper-v host here, I've would have tested it there as well. Based on 20 years of practical experience, I am pretty sure this is an issue with kali.

There's a communication issue. I'd be ashamed if I leave (potential) customers hanging for more than 2 hours, but that's my standard. A "yes, we got your issue and are investigating" mail after 24, maybe 48 hours is the bare minimum. 6 Weeks of silence...

Thanks for nothing.

arnaudr

2022-03-14 02:48

manager   ~0015882

Yep we should have answered earlier, that mistake was on us, granted.

This being said, I don't have setup to test Hyper-V. Those who have might just not have the time, not sure, I can ping some people but it's likely going to be "Ok, tried it, no problem on my side". Then we won't have the time and resources to drill down until we find the exact cause of the issue. That's why it's worth also trying to post on https://forums.kali.org/, maybe you'll be more lucky there.

> I'd be ashamed if I leave (potential) customers hanging for more than 2 hours, but that's my standard. A "yes, we got your issue and are investigating" mail after 24, maybe 48 hours is the bare minimum. 6 Weeks of silence...

What customers you're talking about? Kali is open-source, for everyone to use. The bug tracker is not a sales channel, and it's not your paid-for support either. It's true that it's a place where you can reach us (Kali developers), but then that's all, there's no promise for support. Our answers to bug reports are a best effort, we have limited time for it, and many other things to do. Some bug reports just don't receive much attention, don't seem to be actionable on our side, so we have to triage and leave some bugs aside, they will never be fixed here and that's fine. Maybe you came here with different expectations, hope that I clarified that.

kali-bugreport

2022-03-14 22:03

reporter   ~0015888

From my side as a user / reader:

Choosing a better fitting issue title from the start could have also helped to get more attraction to this issue report ;-)

max06

2022-06-11 13:02

reporter   ~0016251

Changing the following kernel configuration seems to fix the issue:

< CONFIG_HYPERV=m
> CONFIG_HYPERV=y

< CONFIG_HYPERV_BALLOON=m
> CONFIG_HYPERV_BALLOON=y

max06

2022-06-11 16:03

reporter   ~0016256

forget the previous one... try this:

1000c1002
< # CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE is not set
---
> CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y

max06

2022-06-11 21:14

reporter   ~0016262

Sharing the mailing list conversation with insights, why this change is required: https://lore.kernel.org/linux-hyperv/PH0PR21MB302513B8500C25CEADA56718D7A99@PH0PR21MB3025.namprd21.prod.outlook.com/T/#t

daniruiz

2022-06-15 18:52

manager   ~0016291

Thank you for the update.
I've shared it with the rest of the team to discuss about it, as I'm not familiar with this at all

daniruiz

2022-06-15 19:31

manager   ~0016295

This tweak should be probably suggested to Debian directly, as we mostly use their kernel configuration

max06

2022-06-15 19:31

reporter   ~0016296

This is correct. I hope, MS takes care of that.

rhertzog

2022-06-15 19:49

administrator   ~0016297

Thanks for the thread discussion. That is quite useful. However in Kali we are following Debian's kernel configuration and Debian's udev package so the changes should be requested to Debian directly.

A bug against "linux" to suggest enabling CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y with the link and rationale would be useful. I see no such request here:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=linux

A bug against "systemd" to request the udev rules might also be useful. I don't see any similar bug here: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=systemd
I don't know which package ships the udev rules in Ubuntu, but it might be useful to check if we should report this to "systemd" or to some other package. Also a pointer to the desired udev rules might be useful.

max06

2022-06-15 19:59

reporter   ~0016298

Do you have any experience how fast debian fixes such things? Might be worth adding the kernel config here temporarily, you could save me from rebuilding my kernel every time you update.

And I'll probably need the debian version you're building kali on for creating the reports.

Issue History

Date Modified Username Field Change
2022-01-29 21:49 max06 New Issue
2022-01-29 21:50 max06 Note Added: 0015676
2022-02-12 13:15 max06 Note Added: 0015720
2022-02-27 21:25 max06 Issue cloned: 0007602
2022-02-27 21:25 max06 Relationship added related to 0007602
2022-02-28 07:24 daniruiz Relationship replaced has duplicate 0007602
2022-03-10 19:59 max06 Note Added: 0015844
2022-03-11 02:37 arnaudr Note Added: 0015845
2022-03-13 13:12 max06 Note Added: 0015878
2022-03-14 02:48 arnaudr Note Added: 0015882
2022-03-14 22:03 kali-bugreport Note Added: 0015888
2022-03-25 13:50 g0tmi1k Priority high => normal
2022-03-25 13:57 g0tmi1k Severity major => feature
2022-03-25 13:58 g0tmi1k Severity feature => minor
2022-06-11 13:02 max06 Note Added: 0016251
2022-06-11 16:03 max06 Note Added: 0016256
2022-06-11 21:14 max06 Note Added: 0016262
2022-06-15 18:52 daniruiz Note Added: 0016291
2022-06-15 19:31 daniruiz Note Added: 0016295
2022-06-15 19:31 max06 Note Added: 0016296
2022-06-15 19:49 rhertzog Note Added: 0016297
2022-06-15 19:59 max06 Note Added: 0016298
2022-06-28 11:55 sbrun Assigned To => sbrun
2022-06-28 11:55 sbrun Status new => assigned