Making ModelSim vsim and Questa vco work on Ubuntu 14.04

In my previous article, http://mattaw.blogspot.com/2014/05/making-modelsim-altera-starter-edition.html, I covered how to install and run the ModelSim-ALTERA starter edition on Ubuntu 14.04.

Subsequently it turns out this fix also applies to Mentor Graphic's ModelSim and Mentor Graphic's Questa (not that surprising as Questa is a superset of ModelSim with far greater capabilities).

The previous instructions for ModelSim ALTERA work for ModelSim.

Here are the detailed instructions to apply the fix to Questa:

Firstly complete installing everything including compiling the new libfreetype libraries and copying them into the questasim directory.

Now we need to edit the vco launch script to ensure the new freetype libraries are used:

sudo vim bin/vco

Search for the following line:

dir=`dirname $arg0`

and underneath add the following new line:

export LD_LIBRARY_PATH=${dir}/lib32

Test by running vco and hopefully you will be greeted by the Questa GUI.

Please email me any fixes or changes you would like so I can update this post and give credit.

Making ModelSim ALTERA STARTER EDITION vsim 10.1d work on Ubuntu 14.04

[WARNING: Some people are reporting that following the steps for them does not fix the problem. I am working on trying to find out what the issue is.]

Trying to get a version of ModelSim running on a very modern version of Linux often presents challenges. Luckily I had lots of helpful information on the internet (major sources linked below) to get it going. This article mostly adapts the work done by the Arch Linux crew.

Problem number one: The free version of ModelSim Altera Edition is 32 bit only while the normal Linux PC will be 64 bit.

On Linux this requires us to install the 32 bit versions of the libraries that it depends on. Luckily this is fully supported on a modern Linux like Ubuntu 14.

sudo dpkg --add-architecture i386
sudo apt-get update

sudo apt-get install build-essential

sudo apt-get install gcc-multilib g++-multilib \
lib32z1 lib32stdc++6 lib32gcc1 \
expat:i386 fontconfig:i386 libfreetype6:i386 libexpat1:i386 libc6:i386 libgtk-3-0:i386 \
libcanberra0:i386 libpng12-0:i386 libice6:i386 libsm6:i386 libncurses5:i386 zlib1g:i386 \
libx11-6:i386 libxau6:i386 libxdmcp6:i386 libxext6:i386 libxft2:i386 libxrender1:i386 \
libxt6:i386 libxtst6:i386

Problem number two: If you have the following error when running vsim:

** Fatal: Read failure in vlm process (0,0)
Segmentation fault (core dumped)

Then you probably need to build a new version of freetype, a font setting library and modify ModelSim to use it. For an unknown reason ModelSim has an issue with modern versions shipping in Arch and Ubuntu 14.04. First download the source code of freetype 2.4.12:

http://download.savannah.gnu.org/releases/freetype/freetype-2.4.12.tar.bz2

Now install the build dependencies needed for libfreetype6, extract the source (using tar) and configure and build libfreetype:

sudo apt-get build-dep -a i386 libfreetype6

tar -xjvf freetype-2.4.12.tar.bz2
cd freetype-2.4.12
./configure --build=i686-pc-linux-gnu "CFLAGS=-m32" "CXXFLAGS=-m32" "LDFLAGS=-m32"
make -j8

The finished libraries are now available inside the "objs/.libs" directory. As they are necessary to run ModelSim we need to copy them into the install directory so they don't get lost and then modify ModelSim's vsim script to use the new libraries instead of the system wide versions. Change directory to the directory where you installed ModelSim, /opt/altera/13.1/modelsim_ase/, on my system. Note you may need to edit the directory paths to match those used on your system.

sudo mkdir lib32
sudo cp ~/Downloads/freetype-2.4.12/objs/.libs/libfreetype.so* ./lib32

Now we need to edit the vsim launch script to ensure the new freetype libraries are used:

sudo vim bin/vsim

Search for the following line:

dir=`dirname $arg0`

and underneath add the following new line:

export LD_LIBRARY_PATH=${dir}/lib32

Test by running vsim and hopefully you will be greeted by the ModelSim GUI.

[Tested on fresh install of Ubuntu 14.04]

Sources:

1. https://wiki.archlinux.org/index.php/Altera_Design_Software
   
2. http://stackoverflow.com/questions/3261909/build-32bit-on-64-bit-linux-using-a-configure-script 
3. https://wiki.debian.org/Multiarch/CrossDependencies

How can I allow users to run a script as root?

I am glad you asked me that question!

In this case I need a user to nuke a process related to themself but executing as 'nx'. So to kill it they would have to be root (or nx). Killing the process and the related cleanup requires a script to automate it so I need to make a script run as root.

I can do that by making the scripting language interpreter (e.g. perl, python, etc) always run as root ("setuid"). This means that all scripts executed by that interpreter run as root.... oops. Ok bad idea as anyone can run any script they write as root. I know, I shall make the kill command always run as root. Anyone can now kill any process .... oops. Ok bad idea, slightly less a security risk though.

The solution to the above class of problems is called a 'shim' after small bits of metal. Go look the reference up if you care. The solution is make a tiny C program that when executed by a user runs as root ("setuid") and then executes the script, sanitising and passing any necessary arguments.

So here is a trivial C program to execute a single script (nxclean.c):

#define PATH "/usr/local/sbin/nxclean"
#define BUF_SIZE 10000

#include <stdio.h>
#include <unistd.h>
#include <sys.h>

int main(void)
{
uid_t user;
char user_str[BUF_SIZE] = {'\0'};

//      printf("My UID is: %d\n", getuid());
//      printf("My EUID is: %d\n", geteuid());
user = getuid();
snprintf(user_str, BUF_SIZE, "%d", user);
//      printf("My UID is: %s\n", user_str);
setuid(geteuid());
//      printf("My UID now is: %d\n", getuid());

execl(PATH, PATH, user_str, (char *) 0);
}

So what is going on here? Firstly a couple of #DEFINE's to save typing. Note that the buffer sizing and the initialisation of the whole buffer to '\0'. Remember this is a program that is going to run as root. It takes no command line arguments, simplifying things, but it is taking things from the underlying OS so be sure to be safe. If you are taking command line arguments then check them every which way, run regex's, size checks, the works. Otherwise kiss your security goodbye.

In this case it stores the UID of the current user as it needs it later, makes itself root via the setuid(geteuid()); line and then executes the script (now as root) passing arguments created from the UID collected earlier.

Note this only works if you have set the little executable this compiles into to run as root. Google "setuid".

The love affair with freenx is over.... time to make the marriage work

It seems that not much survives contact with students!

Basically if the freenx session isn't correctly terminated or established then desktop processes and a nx process are left running to the server which will prevent them logging in again.

However I am not the first person to notice this:

PSI Labs who use the technology have developed a RPM of scripts to manage this properly called nxcleanup. A user session has the standard number of processes for the desktop however there is an associated nx process that the student doesn't own. So the script nxclean would need to be run as root.

How do I enable a student to run a script as root that wipes out processes of an arbitary user?

Simple: Use a setuid "shim"! Write a trivial C program that takes no inputs (or has very, very thorough sanity checking!) which identifies the current user using posix calls and then exec's the script after passing it the current username. Nifty eh? This is a standard way of making scripts run safely as root. I'll post it as soon as I am done.

NX Technology Makes Remote X Possible

I implemented NX technology on our linux CAD servers some time ago.

NX has enabled a whole distance learning class from America using some really poorly coded CAD tools (some are windows GUIs run under emulation).

It made it like using them over the LAN!

If you have remote UNIX application needs then please consider this technology.

I am more than happy to consult on your CAD architectures.