[vbox-dev] VirtualBox official debug builds/debug symbols
Klaus Espenlaub
klaus.espenlaub at oracle.com
Wed Apr 18 12:07:46 GMT 2018
Samuel,
you're using a non-hardened build (which is meant for direct use by a
developer, generally straight from out/..../bin, not for installing
system-wide) with the same permissions as a hardened build (i.e. suid
root). This explains why the result ends up running as root, because
only hardened builds have the code for dropping the privileges again to
the normal user.
While the system-wide install is probably not an issue in your case
(face it, many Linux installs are effectively used by only a single
person, so many security issues are irrelevant in such a context),
you'll need to adjust the permission, dropping the suid bit (04xxx)
Klaus
On 18.04.2018 12:09, Samuel Rats wrote:
> Hi everyone.
>
> First of all, thank you all for your replies!
>
> I have a strange behavior that is blocking me at the moment: my debug
> build of VBoxHeadless process is started with the root user, while it
> was started with the actual user with the official release build.
> Is this due to not using a hardened build, or am I missing something else?
>
> What I did was basically replace the official VBoxHeadless binary with
> my debug one.
> Access rights have been conserved (root:root, mode(4511)).
>
> 2018-04-13 12:16 GMT+02:00 Knut St. Osmundsen <knut.osmundsen at oracle.com>:
>> Hi all.
>>
>> The VBOX_ASSERT=no environment variable only works for ring-3 code and
>> will not be picked up by kernel drivers or raw-mode.
>>
>> The risk of hitting an assertion in the kernel drivers is reasonably low
>> these days. I run debug everything all the time and haven't seen any
>> spurious BSODs for years (I'm not counting the times I modified the
>> drivers and are testing the modifications).
>>
>> That said, we could probably make it possible to disable them in a
>> similar manner as SUPLoggerCtl uses. However, we're a bit busy at the
>> moment (or at least I am) so, that may take a while to surface.
>>
>> -bird.
>>
>>
>> On 2018-04-12 8:09 AM, Michael Thayer wrote:
>>> Indeed. We have an API function RTAssertSetMayPanic() which is
>>> available in the support driver but with no way of triggering it. Might
>>> make sense to add something, on the lines of
>>> SUP_IOCTL_LOGGER_SETTINGS/SUPLoggerCtl.
>>>
>>> Regards
>>> Michael
>>>
>>> 11.04.2018 20:48, Klaus Espenlaub wrote:
>>>> No it doesn't from what I remember. Env variables are not available in
>>>> kernel context. This means that unless on Windows you really like BSODs
>>>> (or have set up kernel debugging) or on the other platforms like panics
>>>> (or where applicable have set up kernel debugging) you really should go
>>>> for release builds of the kernel components. Not all of them are
>>>> executed in the context of a VM.
>>>>
>>>> Klaus
>>>>
>>>> On 11.04.2018 11:51, Michael Thayer wrote:
>>>>> I would not be able to answer that properly without investigation. I
>>>>> expect that it does, but that you need to work out how to pass that
>>>>> variable to the driver. (In Linux a module parameter might do it. The
>>>>> source code will know.)
>>>>>
>>>>> Regards
>>>>> Michael
>>>>>
>>>>> 11.04.2018 11:17, Mihai Hanor wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Does VBOX_ASSERT=no affect kernel mode assertions?
>>>>>>
>>>>>> Regards,
>>>>>> Mihai
>>>>>>
>>>>>> On Wed, Apr 11, 2018 at 11:30 AM, Michael Thayer
>>>>>> <michael.thayer at oracle.com <mailto:michael.thayer at oracle.com>> wrote:
>>>>>>
>>>>>> Hello Both,
>>>>>>
>>>>>> On the whole the debug build should be usable for day to day work for a
>>>>>> developer (not for an innocent person of course). Assertions can be
>>>>>> made non-fatal by either running in the debugger ("gdb VBoxSVC" in one
>>>>>> terminal and "gdb --args VirtualBox --startvm ..." in another) - the
>>>>>> preferred option - or setting the environment variable VBOX_ASSERT=no.
>>>>>> See the source file src/VBox/Runtime/VBox/RTAssertShouldPanic-vbox.cpp.
>>>>>> I must admit that I was never happy with the "gdb" option, to the extent
>>>>>> that I added the "wait" option for myself, but feel free to experiment.
>>>>>>
>>>>>> I would certainly recommend trying to investigate using a debug version.
>>>>>> That said, you can also build your own release version. Building with
>>>>>> "VBOX_WITHOUT_HARDENING=1" set will probably make you happier either
>>>>>> way.
>>>>>>
>>>>>> Regards
>>>>>> Michael
>>>>>>
>>>>>> 10.04.2018 22:35, Mihai Hanor wrote:
>>>>>> > Hi Samuel,
>>>>>> >
>>>>>> > The VirtualBox debug build is not for regular usage. The debug build
>>>>>> > runs unoptimized code and some of its code paths may differ from a
>>>>>> > release build. This includes debug assertions, that will stop your
>>>>>> VM or
>>>>>> > even the host OS without warning, if they trigger. On Windows, at
>>>>>> least,
>>>>>> > an assert in the VirtualBox kernel driver will stop your OS with a
>>>>>> BSOD
>>>>>> > -- I don't know how the Linux kernel handles a kernel module
>>>>>> fault. With
>>>>>> > a debug build, it may even be harder or impossible to reproduce a
>>>>>> > scenario. You can use the official build to see where it crashes, then
>>>>>> > use a self-build release build to obtain a detailed stack trace,
>>>>>> if the
>>>>>> > crash is in VirtualBox code. From this point forward, it depends
>>>>>> on the
>>>>>> > issue and your skills.
>>>>>> >
>>>>>> > Best regards,
>>>>>> > Mihai
>>>>>> >
>>>>>> > On Tue, Apr 10, 2018 at 6:31 PM, Samuel Rats <srats at genymobile.com
>>>>>> <mailto:srats at genymobile.com>
>>>>>> > <mailto:srats at genymobile.com <mailto:srats at genymobile.com>>> wrote:
>>>>>> >
>>>>>> > Hi VBox people!
>>>>>> >
>>>>>> > In order to investigate an issue I recently opened
>>>>>> > (https://www.virtualbox.org/ticket/17644
>>>>>> <https://www.virtualbox.org/ticket/17644>
>>>>>> > <https://www.virtualbox.org/ticket/17644
>>>>>> <https://www.virtualbox.org/ticket/17644>>), I was looking for some
>>>>>> > official debug builds of the VirtualBox package, but couldn't
>>>>>> manage
>>>>>> > to find any.
>>>>>> > Even the "testing" builds are release build.
>>>>>> >
>>>>>> > Can I find them somewhere, or should I build VirtualBox in debug
>>>>>> > mode myself?
>>>>>> > Additional question, do you know if the debug build is of
>>>>>> VirtualBox
>>>>>> > is much slower than a release build, or is it still usable for
>>>>>> > days-to-days operations?
>>>>>> >
>>>>>> > This issue is really bothering us, and I have time to
>>>>>> > investigate/fix it.
>>>>>> > Thanks in advance.
>>>>>> >
>>>>>> > --
>>>>>> > Samuel Rats
>>>>>> > _______________________________________________
>>>>>> > vbox-dev mailing list
>>>>>> > vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>
>>>>>> <mailto:vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>>
>>>>>> > https://www.virtualbox.org/mailman/listinfo/vbox-dev
>>>>>> <https://www.virtualbox.org/mailman/listinfo/vbox-dev>
>>>>>> > <https://www.virtualbox.org/mailman/listinfo/vbox-dev
>>>>>> <https://www.virtualbox.org/mailman/listinfo/vbox-dev>>
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > vbox-dev mailing list
>>>>>> > vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>
>>>>>> > https://www.virtualbox.org/mailman/listinfo/vbox-dev
>>>>>> <https://www.virtualbox.org/mailman/listinfo/vbox-dev>
>>>>>> >
>>>>>>
>>>>>> --
>>>>>> Michael Thayer | VirtualBox engineer
>>>>>> ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt
>>>>>>
>>>>>> ORACLE Deutschland B.V. & Co. KG
>>>>>> Hauptverwaltung: Riesstraße 25, D-80992 München
>>>>>> Registergericht: Amtsgericht München, HRA 95603
>>>>>>
>>>>>> Komplementärin: ORACLE Deutschland Verwaltung B.V.
>>>>>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister
>>>>>> der Handelskammer Midden-Nederland, Nr. 30143697
>>>>>> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>>>>>>
>>>>>>
More information about the vbox-dev
mailing list