AsyncSocket: Update AsyncSocket_GetRemoteIPAddress for IPv6 support.
AsyncSocket_GetRemoteIPAddress offered the return of the IP in integer and
string formats, none of the callers cared for the integer return so remove it.
Update name appropriately
AsyncSocket_GetRemoteIPAddress->AsyncSocket_GetRemoteIPStr.
AsyncSocket_GetRemoteIPAddress only supported the returning of a IPv4 string,
utilize Posix_GetNameInfo that uses getnameinfo which is IPv6 compliant.
AsyncSocket_BindUDP is unused, and looking at it I am not sure if it ever worked
as described, since it did not actually bind to the port specified, just a UDP
listener.
Allow for future use of AF_UNSPEC in AsyncSocket library
Create a socketFamily switch in AsyncSocket_Connect and
AsyncSocket_ConnectWebSocket for future IPv6 integration.
Allow for future use of AF_UNSPEC when a connection does not care if it is
AF_INET or AF_INET6. Since AsyncSocket does not fully support AF_INET6 yet and
our AF_INET6 test bed is not yet completed, hard code all callers to AF_INET.
Update AsyncSocketResolveAddr to allow AF_UNSPEC and AF_INET6 ai_family.
AsyncSocketResolveAddr currently only accepts searches for AF_INET. Update it to
search for AF_INET6 or both with AF_UNSPEC. Since we no longer need to return
sockaddr_in for AsyncSocket_SendTo, only populate sockaddr. Also add a
convenient IP string generation after resolve so all callers do not need to do
the same operation tp log the IP string with port number.
desktopEvents: Leave libICE rug firmly under libSM.
While the libICE spec's section on error handling suggests applications
close libICE connections in response to I/O errors, libSM (which
sits atop libICE) continues to refer to such deceased libICE
connections, and doing so during shutdown leads to an app crash.
(libSM should've registered an I/O error handler of its own which would
run before the application's, but it doesn't. Oh well.)
To work around this, we'll detach the ICE connection from our
application event loop but leave its handle alone.
Fix AsyncSocket reference leak when using IVmdbPoll
A reference is taken when an AsyncSocket callback is registered in
IVmdbPoll to protect the AsyncSocket from being freed while the callback
has been scheduled to run. That reference is released when the callback
is unregistered if the callback is not going to run, or from the
callback itself if it is already scheduled. The current code does not
correctly handle the case when the callback unregister itself, as it
needs to explicitly release the reference in that case. This change
also adds a Bool to AsyncSocket so we can distinguish between send
callback that is registered as a timer callback so that we know which
type of callback to remove, which is necessary to keep the reference
count correct.
Prior to this change, vi client would say that the Guest OS was
"Other (32 bit)" whenever Tools were running in an ESXi guest.
Now, the Guest OS is reported as "VMware ESXi 5.x."
This change provides limited VMware Tools support for ESXi 6.0
guests. The powerOps and guestInfo plugins are supported.
Only IPv4 addresses are reported, since those are the only
ones we can get through the vmkuser library.
VMware Tools for ESXi 6.0 are packed as two VIBs on a single
ISO image. One VIB contains the glib libraries that are
missing from the standard ESX distribution, and the other
VIB contains the tools themselves.
We are doing a popen("lsb_release... ") when attempting to
determine host details in hostinfoPosix.c. Using popen means that
$PATH is walked when looking for the lsb_release binary, and that
may give an attacker the ability to run a malicious version of
lsb_release.
This change does two things,
a) Hard code the path to lsb_release. I've searched around
the web and I believe the path is always "/usr/bin/lsb_release"
so let's not leave this up to chance.
b) Stop running HostinfoGetCmdOutput with elevated privileges. Drop
to non-root when possible. If someone sneaks in a new call to
HostinfoGetCmdOutput and doesn't use a full path, then we will
hopefully avoid a firedrill. I'm only applying this to Linux
because the Fusion build barfed when I tried to compile with
without the vmx86_linux.
I think either (a) or (b) would be enough but I'm doing both,
because each individually is correct. Also note that in the blog
post by Tavis Ormandy calls out doing (a) as not enough,
http://blog.cmpxchg8b.com/2013/08/security-debianisms.html
His example uses a bash feature that allows functions to be
exported. I haven't been able to get that to work on my Ubuntu
machine.
To test I'm manually run Linux WS and Fusion and verified that
the logs look correct.
HGFS: Clean up HGFS server unpack file name V3 arguments
The HGFS server unpack file name argument for V3 packets generates coverity
warnings as it stands. It is also just plain dubious in its usage using the
out argument even when not initialized in the failure case.
Change glib logging in RpcChannel to use Debug/Warning/Panic.
Change glib logging in RpcChannel to use Debug/Warning/Panic so RpcChannel
logging can be controlled by different logging stubs in different
applications(rpctool/vgauth/toolsd etc).
HGFS: Partial fix for corruption when using different file handles to the same file
File is corrupted while our customer using two threads to read or write a
file via Linux HGFS client. This is because the read handle interferes with
the writes by causing a revalidation of the inode's file attributes. These
were mishandled wrt to flushing out the cached pages. If the new attributes
were different for modification time or file size then the pages in the cache
were invalidated. This causes pages of valid data to be thrown away and the
writes lost. Therefore resulting in a file with gaps of blocks of zero bytes
where writes were not sent to the HGFS server.
This is fixed by replicating what NFS does in this regard, which is only invalidate
the cache if the HGFS server returned file size only differs from the cached
inode value and only then if the new size is greater.
Cleaned up the write begin and end which was initially causing problems due
to very buggy code. Have now based this on simplicity from fs/libfs.c and
the simple_write_begin/simple_write_end which shows what the minimal settings
should do handling writes to pages and partial page writes.
These can be viewed under you favorite linux source cross-reference website.
Fix AssertOnCompileFailed for GCC 4.8 (kernel 3.10+)
GCC 4.8 now includes -Wunused-local-typedefs as part of -Wall. This
causes it to spew a gazillion warnings when compiling our modules on
3.10+ kernels. Because it's a typedef we can't use the (void) cast
trick, so we need to use attributes. This change introduces
UNUSED_TYPE to vm_basic_types.h and uses it where appropriate to make
the compiler happy when building our modules.
Right now we use vmalloc()/alloc_page() for our guest queuepair pages
(and bitmap page) and then do a virt_to_phys() before passing them down
to the device. That's not going to work if DMA remapping is enabled,
since the IOMMU has no idea about the mappings. Switch to
pci_alloc_consistent() instead. We still allocate each page
individually, since there's no guarantee that we'll get a contiguous
block of physical for an entire queuepair (especially since we allow up
to 128 MiB!).
Also made split between guest and host in the kernelIf struct much
clearer. Now it's obvious which fields are which.
Finally, drop the PINNED flag from Linux. That was only ever used by
vVol-Filter, and that's been moved over vPageChannel, which doesn't use
queuepairs but has custom rings.
Once this is in I'll port it to upstream. I considered doing upstream
only, but that would mean pre-3.9 guests would be unable to use
IOMMU support. We should really freeze the in-house driver after
this...
Enhancing existing log statements to be useful, moving open flags utility function
into the utility file as in the future it should be used by open and create
entry points.
VMI was gone a long time ago. There are a few remnants
still present.
- includeCheck has a VMIROM macro that can go, plus all
locations it was copy-n-pasted into
- vmcore/public/paravirtualInterface.h was totally unreferenced.
The Linux HGFS client miscalculated the number of 512 byte blocks to set
in the inode for the file size. It was incorrectly using the HGFS
hardcoded block size instead of 512, which was 1024. This causes the
block count to be half the correct number and so du on a file reports
the incorrect size. fstat also retrieves this block count in the stat
structure so it is likely more applications will break.
Change GuestLIB SDK to use new RpcChannel API.
1) Change RpcOut_* calls to RpcChanneel_* calls.
2) guestlib SDK now has extra dependency on GLIB and vmtoolslib as
secure guestRPC brings a lot new dependencies (rpcin, asyncsocket, ssl,
datamap, hashmap etc).
3) ship new glib and vmtoolslib for linux and windows packages.
4) merge logging functions (Debug(), Warning()) in vmtools and guestlib
into one to avoid having same function names defined in two libs.
5) update build in open vm tools.
6) app monitor needs to do similar thing, which will be handled by HA
team.
The kernel buffer holding the symlink name was being freed incorrectly
when it was used by the VFS layer. This resulted in corruption and
invalid names being used when trying to lookup the symlink's target.
The HgfsFollowlink should not be calling vfs_follow_link but calling
nd_set_link to save the link target name that HGFS allocated. To deal
with the release of the name, HgfsPutlink has now been added which the
VFS layer will call as needed and this function retrieves the name from
the name structure using nd_get_link and releases the buffer. Then for
completeness calls nd_set_link with NULL to clear it from the name
structure. The VFS layer internally calls vfs_follow_link after the
HgfsFollowlink call passing the link target name from the name object
that HGFS stored. Hence, why HGFS should not call it directly.
When doing partial page writes the Linux HGFS client would trash the
initial part of the page leading up to the start of the write and also
trash the remaining part of the page after the written segment of the
page.
This trashing of the initial part of the page was incorrect and
overwrites earlier partial page writes to that page. This was also
incorrect as the arguments for the offsets into the page were
miscalculated.
. Fix FileIO_CloseAndUnlink() to handle unlink failures.
. Add Debuan 7,1 to the list of known OSes
. changes in shared code that don't affect open-vm-tools functionality
Fix parsing logic in guestInfo to parse vlan configured NICs
The regular expression used to parse routes /proc/net/route and
/proc/net/ipv6_route fail when the device names contain "." eg: eth0.80
which is how the interface names appear when we have VLANs configured.
This fix modifies the regex to handle this case by parsing until a
whitespace character is encountered.
Use g_debug instead of g_warning in RpcChannel_Error
With esx5.1GA Tools, when there are more two Terminal Sessions
connect to a Windows VM, each TS sould have one vmtoolsd running
but actually only max two vmtoolsd run. The Windowds Application
Event log fills up with the warning messages of
"[vmusr:vmusr] Error in the RPC receive loop: RpcIn: Unable to send."
repeatly until close some TS' to have max two TS connected. Some
customers had vmtoolsd crashed but some didn't. This message is from
RpcChannel_Error. After replace g_warning() by g_debug(), the problem
is resolved. This is a workaround for esx5.1x.
1) Fix some assertion for reconnect.
2) Call VMCISock_GetAFValueFd so we do not hold vsock usage all the time.
2) Cut off the dependency of SIGUSR1 with dndcp plugin.
3) Change function name vmware_unblock_vmware_user to send_vmware_user_sigusr1.
Avoid logging non-fatal messages without logging system initialization.
Logs that come before logging system intialization spam the
console output. Therefore, we make the logging a no-op for
non-fatal messages until logging system has been initialized.
Usually, we initialize the logging system when process starts up,
so we will swallow only those non-fatal log messages that are
generated during very early stages of process initialization.
While cleaning up the usage of the HGFS packet abstraction it meant that
the arguments to the HGFS server packet send callback could be cleaned up.
The arguments for the packet buffer and size are now unused as this too
arguments are extracted from the HGFS packet object.
Therefore, remove the unused arguments from the send callback.
. Tools,DND,X11: Constrain detection window to desktop work area
. dndcpx11: Adjust style to match Hosted UI guidelines
. changes in shared code that don't affect open-vm-tools functionality
Deal with the broken reply packet part of the abstraction.
Fix the get reply packet function call to separate out the reply data
size passed in and the reply packet buffer size which is returned.
Add the reply data size field in the HgfsPacket object so that the reply
data size and reply buffer size can be separated out and not overloaded.
This allows the transport channel send routines to extract the reply
details from the packet object and not need the buffer and size
arguments. The send function channel callback API will be cleaned up in
a separate change.
The get reply function for the packet now sets the meta packet data size
too when it is used for the reply packet. This is used by the VMCI
channel which now only maps and copies the correct amount of reply data
into the guest VM shared memory.
The reply packet size is randomly overwritten from the total packet size
available for the reply to hold the amount of written data in the reply.
This however, does not have any effect, since, the reply data size is
passed to the send function which then knows how much data to send, and
for VMCI, the meta part of the packet is used to transfer data to the
guest shared memory so the reply part is essentially unused. This is now
deleted.
This change is supporting a 64bit MPN for hosted products.
Assumptions taken:
1. Kindly note that currently we do not have systems supporting 64bit
memory. So hosted vmmon 64 bit MPN is a container to store whatever
monitor passes to it. The underlying assumption is that the higher
32bits will be zero.
2. Physmem tracker still does page walk using 32 bit values and we have
put checks to make sure that MPN64 is just a container with actually 32
bit values. This was a design decision taken after talking to kevinc and
jpool.
3. The CrossPage code is still 32 bit and I typecast MPN64 to accept 32
bit values for the crosspage code.
4. Vmkernel already has another definition of MPN64 and I have retained
their definition for vmkernel specific code.
typedef uint8 * MPN64;
typedef uint64 MPN64;
5. Additional changes were required in bora-vmsoft vmballoon module
which earlier used MPN and called functions expecting MPN64 as an input.
I have however *NOT* changed the PageHandle code of Vmballoon. I have
typecasted to MPN64 where common MacOS page handling functions which
require MPN64 are used.
Pass RPCI channel info to guestrpc command hanlders.
Since now we have secure guestRpc, some commands like namespace manager
needs to handle vsocket/backdoor connections differently. main changes
are in guest_rpc.c, guest_rpc.h, and namespaceMgr.c. Changes in other
files just function sinature changes.
Tools/DnD X11: Logging improvements and cosmetic touchups.
===== Logging =====
A large chunk of the Tools DND code included function call tracing via
log entries at the debug level. However, it had some problems, such as
generating a lot of noise in all buildtypes. (Remember that Tools only
has 3-4 log levels: debug, info, warning, and error.) There was also a
problem with inconsistency w/r/t logging when a function went out of
scope.
To address this, I whipped up a dummy tracing object and shove it in
bora-vmsoft/lib/public. By including tracer.hh, one just inserts
TRACE_CALL(); at the beginning of a function to log entry/exit.
Additionally, it works only in developer builds; it's a ifdef'd out
everywhere else.
Another thing I did was centralize logging of GuestCopyPasteMgr's
session ID and state updates. We now long old/new values upon update.
More of the DND code has been fixed to log to the dndcp GLib log domain,
making it easier for folks to isolate dndcp logs. (This explains the
switch from Debug to g_debug.)
===== Readability ====
There was a list of some 10+ sigc signals that, due to indentation and
such, was kinda hard to read & easily skim. I replaced this with a
macro which reduces each signal hookup to one line.
Switch utf::string from g_utf8_validate to Unicode_IsBufferValid.
In the version of glib we currently use g_utf8_validate rejects strings
containing the non-characters U+FFFE and U+FFFF. This was marked as a
bug and resolved (see https://bugzilla.gnome.org/show_bug.cgi?id=694669)
but until that is released we need a workaround. Our internal UTF-8
validation routine accepts these characters as valid so use that
instead.
Fix VMHSUtilFileMove and clarify comments of File_Replace
VMHSUtilFileMove has been broken since 2008 and no one has noticed,
so I would be happy to remove the entire mv command from VMHS if
no one would miss it.
Change the lspci parameters to avoid crash dangerous and offer more readable information.
Currently our WS `vm-support` runs:
lspci -H1 -M
lspci -H1 -M -vn
The -H parameter is dangerous. In better case it will crash your server,
in worse case it will corrupt your data.
So change them to:
runcmd "lspci -M -vvv -nn -xxxx" "/tmp/lspci1.$$.txt"
runcmd "lspci -t -v -nn -F /tmp/lspci1.$$.txt" "/tmp/lspci2.$$.txt"
runcmd "lspci -vvv -nn" "/tmp/lspci3.$$.txt"
Adding in the new fields to indicate the size of the valid data, not the
size of the buffer. Previously, the two were combined which meant that
the buffer size was ultimately used instead making the data copies very
inefficient.
Another transitional change to get this stuff moved over to handle the
total pack size and valid data sizes separately. Currently, VMCI has to
use the total packet sizes only and so maps in 16 pages and copies all
the data back and forth because it can't tell how much is actually
valid. When I switch the VMCI transport header to support V2 it will
have the correct data size and packet ID - asynchronous will then work
too.
Mac OS Tools: Make system-wide services launchd-compliant
Since day 1, the way we have started the tools services has been: at
boot, launchd executed the process "services.sh --start", which:
1) Loaded kexts.
2) Started the long-lived vmsvc as a daemon.
3) Exited.
According to http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html ,
launchd sends it a SIGTERM. See "SIGTERM".
This change fixes the above two issues, by turning things upside down:
since vmsvc is already a long-lived process, let's:
o Have launchd start vmsvc directly, without daemonizing it, just like
launchd already does with the vmusr process.
o Modify vmsvc so that the first thing it does is load the kexts.
I kept the "services.sh --stop" interface (I just re-implemented it
differently), because it is useful to testers, but more importantly
because it is called from two places:
The tools preinstall package script (possibly in a tools package older
than this change).
The tools uninstallation script.
This change makes use of __thread on Linux for storing the vthread
base pointer and the thread ID. We still also store the value with
pthreads_setspecific so that we have consistent behavior on thread
destruction (using the pthreads destructor). But this allows the
VThread_CurID path to skip loading the pthread key, skip checking if
the key is initialized, and skip the call into pthread_getspecific.
(With VThread_CurID taking its own fast path, it's not clear there's
much benefit at all from optimizing the path for the base pointer, but
I did so for consistency's sake.)
I tried using my USB bandwidth test to measure the performance impact
of this on a Linux host. Unfortunately I found the test to be much
more noisy under Linux. The results claimed 1.6% faster overall, but
I have almost no faith in that number.
Still, having inspected the new code and looked at the contents of
pthread_getspecific, I think it's safe to claim that this should be
better overall even if its difficult to quantify how much. And though
it makes the code slightly more crufty, such ugliness is confined to
two functions.
Sometimes when we make preprocessor tables we have to blow past 80
columns. But in x86cpuid.h we had a table with plenty of internal
whitespace which was 81 columns long. No reason to have to suffer
with that.
The HGFS server sets the packet's ID field as the HGFS protocol request
ID. This should not occur and it overloads that the packet ID which
should be private to the transport channel which has nothing to do with
the HGFS request ID. The HGFS request ID has it's own field in the HGFS
header used by the request and reply.
Remove the HGFS server modifying the packet ID. This is currently safe,
as the clients do not receive any asynchronous replies from any HGFS
server where the packet ID in the reply is used.
projects / thirdparty / open-vm-tools.git / log
