Hardening consulting

Author:

More improvements on Accendino, with that 0.5.10alpha1 version which is the stabilization course for 0.5.10.

FFmpeg is one of those softwares that are horrible to automatically build under windows (just behind OpenSSL), and one of the targets for this version was to be able to build FreeRDP with the support of FFmpeg under windows with the Visual Studio toolchain, and do all that automatically. No by hand hacks to make it work, just 

$ accendino --targets=freerdp3 freerdp.accendino

It checks out, compiles and it's ready.


New features in version 0.5.10 alpha 1

Support for Msys2

First step to compile FFmpeg with Visual Studio: you need to execute commands under msys2, and therefore this version brings package installation support to this environment. If you put 'msys2/yasm' in packages dependencies, accendino will install the corresponding packages in the msys2 environment.

Extract from the FFmpeg accendino file:

...

ffmpegPkgs = {
    'Darwin': ['nasm'],
    'Windows': ['choco/nasm|path/nasm', 'msys2/make', 'msys2/yasm', 'msys2/diffutils'],
}

...

This support was not very complex to implement because msys2 uses pacman as package manager, which is already supported in accendino for ArchLinux. We already had everything we needed to list installed packages and run package installations.

A new makeMsys2 builder type has been added for CustomCommandBuildArtifact, which allows to launch make but in the msys2 environment, that's the way to build FFmpeg with MSVC.


Toolchain

This version brings the notion of toolchain, which basically allows to specify which buildchain to use. Under the Unixes, we have the choice between gcc and clang, and under windows we will detect Visual Studio and you can use with MSVC or clang (vs/msvc or vs/clang).

The toolchain support enables to set the right environment variables for gcc or clang builds (which will then be used by meson, cmake or others), but also to call the VsDevCmd.bat script of visual studio (or its powershell equivalent).

All of this was required for FFmpeg, because when you do the build process by hand, you open a Visual Studio development shell that allows you to have the PATH positioned properly, then from there you run a msys2 shell that will inherit of these values, and the build is launched inside this msys2 shell.

The build process under windows has therefore also been redesigned and so now we generate a powershell script containing all commands and this powershell script is then executed. This facilitates management of environment variables, but also debugging, because you can easily restart the script with exactly the same environment (because all this is done in the powershell script itself). With all these additions, we automate the construction of FFmpeg under windows with Visual Studio.

Even if we already had the possibility to make a cross compilation with mingw on Linux and then transfer the files under windows, it is so more convenient to build on windows and use directly VisualStudio if you have to do a debugging session.

With the support of the toolchains, the BuildArtifact gains a new toolchainArtifacts argument that gives the list of artifacts that should be pulled from the toolchain. The default value is to indicate that it is desired to use a C compiler (c), but you can also add c++ for projects coded in this language.


Various other changes

A lot of other improvements have been made in this version:

  • accendino files have been added for Cairo, cJson and qfreerdp_platform, which allows to build these projects very easily and have a more feature complete FreeRDP under windows;
  • now when accendino detects a rebuild for an item, it will also rebuild all the items which that item depends on;
  • with this version we look for the accendino files passed in command line in the current path and then in the pockets: no need to give the complete path when the accessino file is stored in a pocket directory;
  • the include() command has a new include_once parameter (true by default) which allows to specify that a file should only be included once during the execution of accendino;
  • CI tests have been added to validate that everything is working properly after changes, this allows to validate a number of build cases with accendino under linux and even windows;

To conclude

With these changes, you can easily have the latest FreeRDP under windows with every possible features with a simple:

C:\Users\david> accendino --targets=freerdp3 freerdp.accendino

VisualStudio will be detected, any packages installed, etc.

And under Linux:

$ accendino --targets=qfreerdp_platform-qt6 --toolchain=clang qfreerdp_platform.accendino

and you have qfreerdp_platform compiled for Qt6 under clang. There's really no excuse to not have tested these nice projects yet !

This is basically the functional scope that will be in the 0.5.10 release, any feedback or bug reports are welcome.

Author:

I made some updates to my Accendino script, until it became a program of its own with interesting features. This version 0.5.9 adds a lot of nice things compared to the previous version. Over time, I see Accendino more as a program allowing to build a complex software from several software sources, and on several platforms. For now my case study is FreeRDP, I try to have accendino files that allow to build FreeRDP from scratch on as many platforms as possible (linux, mac, windows, mingw, ...)


History

Originally accendino was just a small script to run the Ogon installation instructions. It was a bit more complex because you could specify the git locations to download. For example, to use the Forgiare repositories instead of the official Ogon repositories. With version 0.5.0, I extended its features quite a lot:

  • the ability to include accendino files to reuse existing definitions;
  • the program sources have been greatly extended and no longer necessarily come from git. We can have local sources, or from git. Many git options are now accessible;

    Read more…

Author:

A little tip that I discovered some time ago: the massive tool from valgrind. It can address cases where we have a program that eats up too much memory unnecessarily, but since it does cleanups correctly at the end, we don't see anything with standard leak tools like valgrind or asan.


Massif

This is where the massif tool from valgrind comes in as well as the massif-visualizer visualization tool. This tool will allow you to regularly take snapshots of memory allocations, and to see the callstacks of location in our programs that make these allocations.

Read more…

Author:

In (the future) FreeRDP 3.0, there is support for the smartcard logon, on which I have worked, let's give some details.


Smartcard support

We start by checking that we can access the smartcard, in my case it is a yubikey(TM):

$opensc-tool -l
# Detected readers (pcsc)
Nr. Card Features Name
0 Yes Yubico YubiKey OTP+FIDO+CCID 00 00

Read more…

Author:

Let's take a closer look at the RDPUDP protocol which will transport data over UDP. To begin with, remember that only channel data can be transported on top of UDP, so it doesn't affect older graphics orders (so forget speed up of bitmapUpdates with UDP), however it will work with any egfx transported graphics. The migration from TCP to UDP is done through the dynamic channel, so drdynvc is mandatory. This mechanism also allows static channels to be migrated to UDP by setting the TRANSPORTTYPE_UDP_PREFERRED flag in the gcc packet of multi-transport channel data.

Read more…

Author:

I've recently done some fixes in winPR with timers with completion and I've encoutered a case that you may find interesting.

It's about handling EINTR: when a system call in interrupted by an incoming signal, you'll get a -1 return code and errno set to EINTR. So usually when you want to be protected against that behaviour you'll code something like:

#include <sys/select.h>
#include <errno.h>

void myFunction() {
    struct fd_set rset;
    int status, max_fd;

    ...


    do {
        ret = select(max_fd, &rset, NULL, NULL, NULL);
    } while (ret < 0 && errno == EINTR);
}

Ok, so problem treated, you can apply that scheme for any system call and you're done, isn't it ?

The poll case

Read more…

Author:

Months that I have not posted anything. So let's begin with some wishes for the new year, let's hope the Covid will be more quiet in 2021.

I'm currently working on implementing UDP support in FreeRDP, so let's have a serie of post on that subject. I'm gonna begin with an overview, how it works, implications and I'll certainly go more in the details in the next posts.


Overview of the UDP transport

Documentation and specifications

The UDP transport is described in multiple specifications:

  • MS-RDPBCGR : the core RDP specification, we have some flags in GCC packets, and of course the description of multi-transport;
  • MS-RDPEMT : this document describes multi-transport, that allows to install multiple transports at the same time;
  • MS-RDPEUDP : the UDP transport itself;
  • MS-RDPEUDP2 : the new version of the protocol;
  • MS_RDPEDYC : dynamic channels specification;

Read more…

Author:

Long time no post. I did quite a lot of things around ogon these last months, and for testing purpose, I had to deploy ogon on many hosts. The deployment guide is ok, but it's a long and repetitive operation. And thinking of it, if we can write these instructions in a manual, then for sure we can automate these operations in a script.


Accendino

So I've created that little software accendino (lighter in italian) that will allow you to start a big fire (ogon in russian).

Read more…

Author:

Windows VMs are so slow under KVM. When you're a FreeRDP developper, you always end up with being forced to have windows VMs to test that old features are still working, or to test new shiny features (yes I love unicorns).


Read more…

Author:

When you're working on FreeRDP, it's quite usual to increase the log level and to have to collect a massive amount of logs. And most often it doesn't fit in the terminal backscroll history, or it is so slow (terminal rendering is CPU intensive) that you need a file storage. Another case is when you're on a remote host and you want to retrieve the log over the network.

As each time I want to use the WLog capacities I'm looking at the source code, I had the idea to write that post on the subject, so that next time I will look at this text.

Read more…