I've been doing something different. As well as looking at disassembly, I've been putting together some material to support the Solaris Studio 12.4 beta programme. The first of this material is an interview with Raj Prakash.
Raj is the project lead for the Code Analyzer - our suite for checking code correctness. The Code Analyzer does static and dynamic checking of applications for common coding errors. You can find out more from the video:
Here's a brief to-camera from me about the Solaris Studio 12.4 Beta programme.
We've just released the Solaris Studio 12.4 Beta. This is an opportunity for anyone to try out the new compiler and tools suite, and give us feedback. This release is pretty exciting, there's support for C++11 as well as massive changes to Performance Analyzer tool. I will be writing some more detailed content about the changes later - so watch this space.
This was a complete surprise to me. A box arrived on my doorstep, and inside were copies of Multicore Application Programming in Chinese. They look good, and have a glossy cover rather than the matte cover of the English version.
Feels like it's been a long while since I wrote up an article for OTN, so I'm pleased that I've finally got around to fixing that.
I've written about RAW hazards in the past. But I recently went through a patch of discovering them in a number of places, so I've written up a full article on them.
What is "nice" about RAW hazards is that once you recognise them for what they are (and that's the tricky bit), they are typically easy to avoid. So if you see 10 seconds of time attributable to RAW hazards in the profile, then you can often get the entire 10 seconds back by tweaking the code.
Sometimes you need to include directives in macros. The classic example would be putting OpenMP directives into macros. The "obvious" way of doing this is:
#define BARRIER \
#pragma omp barrier
void foo()
{
BARRIER
}
Which produces the following error:
"test.c", line 6: invalid source character: '#' "test.c", line 6: undefined symbol: pragma "test.c", line 6: syntax error before or at: omp
Fortunately C99 introduced the _Pragma mechanism to solve this problem. So the functioning code looks like:
#define BARRIER \
_Pragma("omp barrier")
void foo()
{
BARRIER
}
Before I start, this is not about security, it's probably the antithesis of security. So I'd recommend starting by reading about how using privileges can break the security of your system.
There are three tools that I regularly use that require escalated privileges: dtrace, cpustat, and busstat. You can read up on the way that Solaris manages privileges. But if you know what you want to do, the process to figure out how to get the necessary privileges is reasonable straightforward.
To find out what privileges you have you can use the ppriv -v $$ command. This will report all the privileges for the current shell.
To find out what privileges are stopping you from running a command, you should run it under ppriv -eD command. For example:
ppriv -eD cpustat -c instruction_counts 1 1 cpustat[13222]: missing privilege "sys_resource" (euid = 84945, syscall = 128) needed at rctl_rlimit_set+0x98 cpustat[13222]: missing privilege "cpc_cpu" (euid = 84945, syscall = 5) needed at kcpc_open+0x4 ...
It is also possible to list all the privileges on the system using ppriv -l. This is helpful if the privilege is has a name that maps onto what you want to do. The privileges for dtrace are good examples of this:
$ ppriv -l|grep dtrace dtrace_kernel dtrace_proc dtrace_user
You can then use usermod -K ... to assign the necessary privileges to a user. For example:
$ usermod -K defaultpriv=basic,sys_resource,cpc_cpu username
Information about privileges for users is recorded in /etc/user_attr, so it is possible to directly edit that file to add or remove privileges.
Using this approach you can determine that busstat needs sys_config, cpustat needs sys_resource and cpc_cpu, and dtrace needs dtrace_kernel, dtrace_proc, and dtrace_user.
Posts
All Comments
