[vbox-dev] getting object name in VirtualBox gui

[Klaus Espenlaub]

Hi Mihai,

On 25.09.2018 20:21, Mihai Hanor wrote:
> Hi Klaus,
>
> When you say that the devs have been working on it, are you referring
> to the 5.2.18 release build, the testing builds or the svn? I've build
> today a svn on Windows 10 and the Windows Narrator is not able to read
> the VM window menu controls. All I hear for it is "pain"/"main" or
> something similar, I'm not sure what it's saying. It's only able to
> read the VM window title. The same thing happens with 5.2.18.

The work on accessibility has been during the 5.2 development mainly
(requiring a new approach since Qt5 manages accessibility quite
differently than Qt4). And one of our GUI devs just confirmed that both
Microsoft Narrator and NVDA do a reasonable job with reading the
majority of the manager UI (which has been the topic so far) from the
latest 5.2.19 test build (actually a more recent one which isn't
available publicly, but there were no significant changes in a while).
"Reasonable job" means that they're correctly reading the text for UI
elements where the mouse cursor is hovering.

So we'd need more details about what aspect of accessibility isn't
behaving adequately.

> From my perspective (building VirtualBox and crashing things), the
> fact that the OS or the debugger are unable to get a "handle" on the
> hardened process, it's something missing. WER just lets the process
> exit, because it can't attach to it. Windbg also can't attach to the
> process. I'm only able to save a dump when there's no default
> debugger, when the OS puts a message box that the process has crashed,
> then I start Process Explorer as admin and dump the process. I haven't
> found a way to do automatic process memory saving. That's the
> experience I remember, because I haven't had a crash in some time. A
> build-in crash handler could help users report crashes, it could be
> useful.

Debuggers simply have no business in a process doing virtualization work
(just like random, untrusted DLLs which some applications inject into
every executable, some of them totally destroying any remaining bit of
security, interestingly mostly done by apps promising to increase
security). They could corrupt the state of the VM which can end up
trashing kernel memory, i.e. being a security issue. So this "loss" is
entirely intentional (i.e. that the VM process handle which is passed to
other parties is seriously stripped down). It's a different question
what to do for post-mortem dumping, because at that point the VM is
already effectively dead. But IIRC Windows adds a new thread to it, kind
of bringing it partially back from the dead. Which would again end up
being questionable from the security perspective.

Klaus
>
> Regards,
> Mihai
>
> On Tue, Sep 25, 2018 at 8:52 PM Klaus Espenlaub
> <klaus.espenlaub at oracle.com <mailto:klaus.espenlaub at oracle.com>> wrote:
>
>     Wait... is it really confirmed that Narrator can't work with
>     (hardened) VirtualBox either? That would mean our devs must have
>     been testing the wrong thing for quite a while now. It certainly
>     hasn't reached my attention so far.
>
>     For many reasons we cannot recommend that random people run
>     non-hardened builds. What might be a way out (not with the current
>     builds, they would be affected by hardening) is to ship an
>     additional compilation of the VM UI which is not subject to
>     hardening and can be used solely with the "separate VM/UI process"
>     option which VirtualBox has already. Would bring some minor
>     feature losses, but if that would bring back full accessibility I
>     can see a good justification for spending the necessary time.
>
>     Klaus
>
>     On 25.09.2018 19:26, Mihai Hanor wrote:
>>     Hello,
>>
>>     I'm not a developer, but I have some experience with VirtualBox.
>>     The reason why not even Microsoft's narrator is able to work with
>>     VirtualBox is the hardening of the VirtualBox process, which is
>>     enforced to protect the VM from eavesdropping (I think). You can
>>     look at the VirtualBox SDK, but you'll probably not find what
>>     you're looking for. Also, integrating the NVDA client controller
>>     is probably not going to happen and it doesn't look useful,
>>     because it requires VirtualBox to send stuff to NVDA (by looking
>>     at the C example), which would require considerable effort to
>>     rewrite the GUI. The most achievable task might be to build
>>     VirtualBox OSE for Windows, without hardening. A much harder task
>>     would be to separate the the frontend/GUI part from the VM
>>     process and make the frontend run in a normal process. In the
>>     upcoming major release of VirtualBox, it looks like the devs have
>>     made a move to separate the VM process, but I'm don't know to
>>     what end. The frontend still runs in a hardened process.
>>
>>     Regards,
>>     Mihai Hanor
>>
>>     On Fri, Sep 21, 2018 at 12:30 PM Илья Пащук
>>     <ilusha.paschuk at gmail.com <mailto:ilusha.paschuk at gmail.com>> wrote:
>>
>>         helo.
>>
>>
>>         I'm a nvda (nvaccess.org <http://nvaccess.org>) screenreader
>>         addon developer
>>
>>         I need the way to get some object text in vbox gui, that
>>         unaccessable by
>>         standard methods.
>>
>>         are there any api interface to get this info from vbox gui?
>>
>>
>>         i'm using python.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20180926/18d497e3/attachment.html>