Original pointer alpha update message is too specific for x11 implementation.
It doesn't allow pointer alpha mask with both 'xor' color and 'and' mask, e.g.: the 'edit' pointer in windows text box.
1. Move shadow_client_convert_alpha_pointer_data to x11 implementation as it is specific for x11.
2. Update message definition to be more generic: to accept 'xor/and' mask directly.
Implementation of subsystem can implement its own way to convert pointer mask data.
3. Fixed fault handling to free the resource allocated.
1. Export fps related API so that subsystem implementation no longer need to know about details in encoder structure.
2. Discard frameList dictionary.
The 'value' in this dictionary is never used and not properly free'ed when client is disconnected.
The dictionary was used to calculate 'inflight' frame count. Once an ACK is received from client, an item in the dictionary is removed.
We then calculate 'inflight' frame by the count of the items in the dictionary.
However, some rdp clients (win7 mstsc) skips frame ACK if it is inactive, ACK of some frame would actually never arrive.
We actually don't need the dictionary. We only need to record the latest acknowledged frame id, and the difference between last sent frame id is the inflight frame count.
3. Minor fix in default fps calculation. encoder->frameAck is wrongly used as integer while it's actually bool flag.
This patch contains:
* checks for malloc return value + treat callers;
* modified malloc() + ZeroMemory() to calloc();
* misc fixes of micro errors seen during the code audit:
** some invalid checks in gcc.c, also there were some possible
integer overflow. This is interesting because at the end the data are parsed
and freed directly, so it's a vulnerability in some kind of dead code (at least
useless);
** fixed usage of GetComputerNameExA with just one call, when 2 were used
in misc places. According to MSDN GetComputerNameA() is supposed to return
an error when called with NULL;
** there were a bug in the command line parsing of shadow;
** in freerdp_dynamic_channel_collection_add() the size of array was multiplied
by 4 instead of 2 on resize
1. Introduce message queue in shadow client. No longer use subsytem->MsgPipe->out to deliver message to clients.
We used to use subsytem->MsgPipe->out for messages which need to be sent to client. But it's not correct. Only one client would get the message if multiple client exists
This problem make the fix in PR #2643 incomplete.
Introduced reference count based solution to release resource taken by the message.
Also added APIs for client message delivery.
Also fixed msg pipe in subsystem to clean resource when destroyed.
2. Discard unused StopEvent in client. We actually use quit message instead.
3. Enhance disposal of channels.
Free context for remdesk and encomsp channels. The original fix only stop the threads, but doesn't release resource.
Dispose channels earlier. The channels are built on client->vcm. Disposing channels after client->vcm is closed cause unknown behavior.
Original fix is #2644
4. Start to add audio support.
When we share a sub-rectangle of our desktop, allow it to span over
multiple monitors. Previously it was possible to export an area larger
than one display, however the contents were always cropped to
the boundaries of the selected monitor and the rest was visible for
the client only as a black area .
Ensure all client threads are disconnected before we stop the server
thread and thus make it available for deletion. We do this because
shadow_client_context_free() accesses rdpShadowServer structure, which
we have to keep alive as long as it is needed.
Calling shadow_client_context_free() after shadow_server_stop() and
shadow_server_free() were called may have caused an application crash.
1)
Added missing checks for CreateEvent which also required the
following related changes:
- changed freerdp_context_new API to BOOL
- changed freerdp_peer_context_new API to BOOL
- changed pRdpClientNew callback to BOOL
- changed pContextNew callback to BOOL
- changed psPeerAccepted callback to BOOL
- changed psPeerContextNew callback to BOOL
2)
Fixed lots of missing alloc and error checks in the
changed code's neighbourhood.
3)
Check freerdp_client_codecs_prepare result to avoid segfaults
caused by using non-initialized codecs.
4)
Fixed deadlocks in x11 caused by missing xf_unlock_x11() calls
in some error handlers
5)
Some fixes in thread pool:
- DEFAULT_POOL assignment did not match TP_POOL definition
- don't free the pool pointer if it points to the static DEFAULT_POOL
- added error handling and cleanup in InitializeThreadpool
- removed some unneeded null checks for free()
- fixed a memory leak in shadow_client
- removed rfx_compose_message_header from API
Changed the following functions to BOOL, check the result
where they are called and handle failures:
- rfx_compose_message
- rfx_compose_message_header
- rfx_write_tile
- rfx_write_message_tileset
- rfx_write_message_frame_begin
- rfx_write_message_region
- rfx_write_message_frame_end
- rfx_write_message
rfx_process_message:
- check memory allocation failures
- verify protocol-conform order of data messages to prevents memory
leaks caused by repeated allocations
- verify that header messages were parsed/received before the
data messages
- treat unknown rlgr mode as error
- fixed/added error handling
- fixed all callers to check/handle result
rfx_encode_message:
- fixed incorrect usage of realloc
- missing malloc check
- missing check of CreateThreadpoolWork
- correct cleanup on failure (threadpool, memory)
- check rfx_encode_message result
rfx_encode_messages:
- check rfx_split_message result
- correct cleanup on failure
- prevent memory leak on failure
rfx_write_message_context:
- fixed invalid channelId value (must be 0xFF for WBT_CONTEXT)
rfx_process_message_codec_versions:
- fixed invalid read size of codec_version (it is 16bit)
rfx_process_message_channels:
- verify protocol conform channelId value
rfx_process_message_region:
- replaced invalid reallocs with malloc
- read and verify regionType and numTileSets from stream
rfx_process_message_tileset:
- check allocation results
- fixed incorrect usages of realloc
setupWorkers:
- fixed incorrect usages of realloc
rfx_split_message:
- removed dead code
- missing malloc check
rfx_compose_message:
- fixed a memory leak
- check/handle rfx_encode_message result
Now using nCount as in and out argument.
When called, set nCount to the number of available handles.
This value is checked and an error returned, if not enough
handles are available.
* fix problem with REMOVE_DUPLICATES on undefined lists
* since 3.1 file(GLOB FILEPATHS RELATIVE .. returns single / instead of // as
previously - necessary adoptions for regex and matches done. Should
work with all cmake versions.
Tested with 3.1.0-rc3
[MS-RDPBCGR] Section 5.3 describes the encryption level and method values for
standard RDP security.
Looking at the current usage of these values in the FreeRDP code gives me
reason to believe that there is a certain lack of understanding of how these
values should be handled.
The encryption level is only configured on the server side in the "Encryption
Level" setting found in the Remote Desktop Session Host Configuration RDP-Tcp
properties dialog and this value is never transferred from the client to the
server over the wire.
The possible options are "None", "Low", "Client Compatible", "High" and
"FIPS Compliant". The client receices this value in the Server Security Data
block (TS_UD_SC_SEC1), probably only for informational purposes and maybe to
give the client the possibility to verify if the server's decision for the
encryption method confirms to the server's encryption level.
The possible encryption methods are "NONE", "40BIT", "56BIT", "128BIT" and
"FIPS" and the RDP client advertises the ones it supports to the server in the
Client Security Data block (TS_UD_CS_SEC).
The server's configured encryption level value restricts the possible final
encryption method.
Something that I was not able to find in the documentation is the priority
level of the individual encryption methods based on which the server makes its
final method decision if there are several options.
My analysis with Windows Servers reveiled that the order is 128, 56, 40, FIPS.
The server only chooses FIPS if the level is "FIPS Comliant" or if it is the
only method advertised by the client.
Bottom line:
* FreeRDP's client side does not need to set settings->EncryptionLevel
(which was done quite frequently).
* FreeRDP's server side does not have to set the supported encryption methods
list in settings->EncryptionMethods
Changes in this commit:
Removed unnecessary/confusing changes of EncryptionLevel/Methods settings
Refactor settings->DisableEncryption
* This value actually means "Advanced RDP Encryption (NLA/TLS) is NOT used"
* The old name caused lots of confusion among developers
* Renamed it to "UseRdpSecurityLayer" (the compare logic stays untouched)
Any client's setting of settings->EncryptionMethods were annihilated
* All clients "want" to set all supported methods
* Some clients forgot 56bit because 56bit was not supported at the time the
code was written
* settings->EncryptionMethods was overwritten anyways in nego_connect()
* Removed all client side settings of settings->EncryptionMethods
The default is "None" (0)
* Changed nego_connect() to advertise all supported methods if
settings->EncryptionMethods is 0 (None)
* Added a commandline option /encryption-methods:comma separated list of the
values "40", "56", "128", "FIPS". E.g. /encryption-methods:56,128
* Print warning if server chooses non-advertised method
Verify received level and method in client's gcc_read_server_security_data
* Only accept valid/known encryption methods
* Verify encryption level/method combinations according to MS-RDPBCGR 5.3.2
Server implementations can now set settings->EncryptionLevel
* The default for settings->EncryptionLevel is 0 (None)
* nego_send_negotiation_response() changes it to ClientCompatible in that case
* default to ClientCompatible if the server implementation set an invalid level
Fix server's gcc_write_server_security_data
* Verify server encryption level value set by server implementations
* Choose rdp encryption method based on level and supported client methods
* Moved FIPS to the lowest priority (only used if other methods are possible)
Updated sample server
* Support RDP Security (RdpKeyFile was not set)
* Added commented sample code for setting the security level
FREERDP_CHANNELS_SERVER_SRCS need to be added to server/common that the
symbols get added and exported with libfreerdp-server.
Also remove duplicated version information.
"libfreerdp" consisted of multiple (small) single libraries. If the cmake
option MONOLITHIC was used only one library was build combining all of
the libfreerdp-* libraries.
The only exceptions to this are libfreerdp-server and libfreerdp-client these
are build as separate libraries.
This commit obsoltes non-monolithic builds and makes monolithic builds
the default. The cmake option MONOLITHIC is also removed.
