Asked by JAMES

Command Line:
Security Context:

When I try to find out about bioset:
:~$ man bioset
No manual entry for bioset

When I try to run bioset:
:~$ bioset
No command 'bioset' found, did you mean:
 Command 'biosed' from package 'emboss' (universe)
bioset: command not found

Is bioset a key logger, virus, or other malware? If it is malware, it is highly successful as nobody has a method of stopping, ending, killing, or even finding the process.

If bioset is a legitimate process, then Canonical should confirm that it is legitimate even if the function of the process is not revealed. My search of the internet has yielded only derogatory speculation.

Question information

English Edit question
Ubuntu Edit question
No assignee Edit question
Last query:
Last reply:
Revision history for this message
actionparsnip (andrew-woodhead666) said :

What is the output of:

sudo updatedb; dpkg -S bioset; lsb_release -s


Revision history for this message
JAMES (james-jadesword) said :

:~$ sudo updatedb; dpkg -S bioset; lsb_release -s
dpkg-query: no path found matching pattern *bioset*
No LSB modules are available.

I hope this helps, but there does not seem to be any useful information.

Revision history for this message
Manfred Hampl (m-hampl) said :

Please provide also the output of the commands

uname -a
lsb_release -crid
locate bioset
ps ax | grep bioset

Those four lines that you've put at the beginning of your question, where did they show up?

Revision history for this message
JAMES (james-jadesword) said :

I apologize as I should have noted the source as from the gnome-system-monitor output. Additionally, when looking for dependencies, bioset showed up under kthreadd.

Please note that I am using the gnome-terminal. The only edit was to shorten the terminal's prompt. Text formatting was lost during the copy and paste.

Please note that the third command [locate bioset] did not have any output.

Please note that the four instances of the word "bioset" were colored red in the output of the fourth command [ps ax | grep bioset]. The output conforms to the three instances of bioset using the gnome-system-monitor.

:~$ uname -a
Linux M68M-S2P 3.13.0-66-generic #108-Ubuntu SMP Wed Oct 7 15:20:27 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
:~$ lsb_release -crid
Distributor ID: Ubuntu
Description: Ubuntu 14.04.3 LTS
Release: 14.04
Codename: trusty
:~$ locate bioset
:~$ ps ax | grep bioset
   67 ? S< 0:00 [bioset]
21645 ? S< 0:00 [bioset]
21649 ? S< 0:00 [bioset]
31323 pts/1 S+ 0:00 grep --color=auto bioset

I hope some of this may be helpful.

Revision history for this message
actionparsnip (andrew-woodhead666) said :

Do you use Truecrypt by any chance


Revision history for this message
Mark Rijckenberg (markrijckenberg) said :

According to the following 2 links, bioset is part of the Linux source code and not malware at all:

I also have the bioset processes running on my Ubuntu PC.

Revision history for this message
JAMES (james-jadesword) said :


Yes, I have TrueCrypt. Running truecrypt will not spawn bioset. Six instances of bioset will be spawned for each truecrypt archive opened.

I have no idea what triggers bioset to spawn, but opening an encrypted archive or opening a program that can access the internet seems to trigger bioset to spawn. That the programs that can access the internet also use encryption may be relevant.

I have also tried to run bioset from the terminal. The error message is, "bioset: command not found".


In the first link; I was unable to determine the function of bioset. There was one reference to "Unable to create bioset \n" and one instance of "could not allocate data integrity bioset \n" in the code. The rest contained the keyword bioset as a part of a label or as part of a comment. There were also references to bioset_create and bioset_create_nobvec. Another, in reference to bio_set, was bioset_free which may not be relevant to bioset. There may be hints as to function, but I am not able to interpret them as I am not a programmer.

In the second link; I see nothing that even hints at the function of bioset. There was one reference to bioset under ps.csv on line 19: name 18, parent 2, CPU 0.0, SIZE 0, COMMAND bioset, RUSER root, S S. Presuming your assumption that it is legitimate because it was listed, what is the function of bioset?

Revision history for this message
Mark Rijckenberg (markrijckenberg) said :

I am not a kernel programmer, but bioset appears to be a kernel process related to block I/O (hence the "bio" in bioset):

I think bioset is part of a high-performance block I/O subsystem in the GNU/Linux kernel:

The bioset process probably needs to remain active in memory to correctly manage writes to block devices.

Revision history for this message
JAMES (james-jadesword) said :


The first link is a supposition I have already seen, not an answer.

The second link does not even mention bioset nor does any search.

The guesses are making me even more worried. Since even Canonical is not replying, they must be having the same problem in trying to identify and explain the bioset process. This is understandable only if the bioset process is not a part of the official source code.

My thought is that if bioset were a legitimate function, there would be documentation confirming its legitimacy even if there were no explanation of its purpose. I have been unable to find anything that looks like the source code, just lists that do not include bioset in the source code repository.

I am not a programmer, so I am sure that if the source code exists, it is not where I looked to find it.

Revision history for this message
Nick S (nmapsy) said :


It's a part of the kernel. No, there's not much written about it, but that's pretty normal for some random kernel thing, in my experience. But there is documentation on the BIO system: No, it doesn't mention the "bioset" process specifically, but it tells us the core of this system is the kernel source file linux/bio.h. And if you look at that file (, there's mentions of "bioset" all over. I'm not familiar enough with the kernel to understand how it works or how it creates a process with that name, but it seems pretty safe to say it's just a normal, benign part of linux.

By the way, this is not a normal process. It's part of the kernel, which means it doesn't compile to an executable file named "bioset" (or "bio"). There isn't actually a command named "bioset", so the system monitor isn't exactly correct there. That's why the output of "ps aux | grep bioset" shows "[bioset]" in the command column, not "bioset".

In general, the most likely explanation for anything that's running on your computer that you don't understand isn't "virus!". It's way more likely to be just some obscure part of the normal software on your computer. There are tons of processes running on my computer that I don't recognize (including bioset). And this stuff is so poorly documented, most of them will have very little description online.

Revision history for this message
Nick S (nmapsy) said :

Oh, and I forgot:
It actually makes total sense that more bioset processes spawn when you mount a Truecrypt archive. It mounts them as block devices, so this supports the idea that bioset is part of the "block I/O subsystem".

Revision history for this message
Ed Redman (e-redman) said :

I also have this 'problem'.
I do not have Truecrypt
The only difference I see from above is in the

sudo updatedb; dpkg -S bioset;lsb_release -s

dpkg-query: no path found matching pattern *bioset*

Also at the present time, I have 37 processes 'bioset' running

any help in how to kill these processes would be helpful

Revision history for this message
h4x0r kitteh (pdwilso) said :

I am - or have been in the past - a kernel hacker / programmer, and I found this thread while trying to find out what this 'bioset' thing was when I booted up this Tails 3.0 distribution on this aged laptop for the first time yesterday.

I have not used a current linux kernel in a couple years, now, but what I was reading at LWN makes perefect sense. The BIO mehodology for block I/O get's away from the 512k "page" limit using this chain of bio_env (??) structures to efficiently move large data.

What that does NOT answer is what /exactly all those "processes" in the prcess listing represent. That is apparently a "kernel block i/o with encryption" answer, since on this system (Tails) pretty much everything is all encryption, all the time.

Also, from what one poster says, above, TrueCrypt uses this same block i/o facility -

I have not yet got as far as searching the source tree for e.g. biosec.s or biosec.c files, but I believe the LWN article did mention a header file that contains constant and macro definitions that are used by device driver writers to work with this (newer) block i/o sub-system. If you're interested I will check back in here when I actually get to that, since it's a pretty sure bet at this point that I will in fact wind up going there. My distrust trust of networked systems at this point seems to know no bounds.


Revision history for this message
h4x0r kitteh (pdwilso) said :

and this \- \- is a really good article, from my PoV - you might want a basic grounding in existing (or former) block i/o functionality going into it though, to get much out of it.

Revision history for this message
h4x0r kitteh (pdwilso) said :

i would also point out to whomever moderates or admins this forum that this issue is:

a) not Ubuntu-specific, and
b) mostly probably a matter of paranoia by sysadmins who aren't in the kernel dev loop.

This should maybe be a FAQ for the newer kernels?

Revision history for this message
h4x0r kitteh (pdwilso) said :

From the Raspberry Pi github:

Issue is considered closed, although still no particulars about the actual processes we're seeing except that it's "kernel i/o" - I personally don't trust kernel i/o any more than any other i/o since NSA had there hands in the kernel code, so I'm still digging.

Revision history for this message
h4x0r kitteh (pdwilso) said :

In Tails 3.0 I have 38 instances of bioset running, according to the process manager.

All of these are 'Very High Priority' (nice = -20), are sleeping, and are consuming "zero" system resources. Process ID values start at 30 and range up into the hundreds.

None of the 38 instances have any files open, nor memory mapped, according to the resource manager.

When I look at the "Dependencies" view of the process listing, all the bioset processes are collected under kthreadd, which, iirc, is the kernel thread service.

So it looks to me like the bioset PROCESS is a sort of block-device pipeline used by encryption services like disc file encryption, display server port encryption, network stream encryption, and so on.

What I don't acually get yet is why there are no file system resrouces associated with these - they appear to be some sort of port/socket mechanism that falls outside the inet, unix, and filesystem naming domains.

Revision history for this message
JAMES (james-jadesword) said :

I sorted by process number and find them grouped in boot-up. I have opted for disk encryption on install and am not currently running any other programs that require kernel support for encryption. I have twenty-three instances of bioset running. I am currently running Linux Mint 18.1 and Cinnamon 3.2.7 64-bit and kernel 4.4.0-83-generic. So far I have not observed any adverse effects, but I am still curious as to what bioset is doing or not doing. I did notice bioset spawning when using truecrypt. That made me think it may have something to do with encrypt or decrypt functions. I guess we will not know unless we can read and understand the source code for the kernel. That is beyond me. I have too many 'irons in the fire' to learn how to read source code.

Can you help with this problem?

Provide an answer of your own, or ask JAMES for more information if necessary.

To post a message you must log in.