Status crypto cards HOWTO: prob­lems with the card read­er (sup­port could be bet­ter)

After hours (spread over weeks) I come to the con­clu­sion that there is a lot of po­ten­tial to im­prove the doc­u­ment­a­tion of card read­ers (but I doubt the card read­er vendors will do it) and of the pc­sc doc­u­ment­a­tion. It is not easy to ar­rive at a point where you un­der­stand everything. The com­pat­ib­il­ity list does not help much, as the card read­ers are partly past their end of life and the mod­els which re­place them are not lis­ted. Re­spect­ively the one I bought does not sup­port all the fea­tures I need. I even por­ted the driver to FreeBSD (not com­mit­ted, I wanted to test everything first) and a lot of stuff works, but one crit­ic­al part is that I can not store a cer­ti­fic­ate on the crypto card as the card read­er or the driver  does not sup­port ex­ten­ded AP­DUs (needed to trans­fer more than 255 bytes to the card read­er).

Well, the status so far:

  • I have a HOWTO what to in­stall to use crypto cards in FreeBSD
  • I have a HOWOT what to in­stall /​ con­fig­ure in Win­dows
  • I have a HOWTO re­gard­ing cre­at­ing keys on a open­p­gp v2 card and how to use this key with ssh on FreeBSD (or any oth­er unix-​like OS which can run pc­sc)
  • I have a card read­er which does not sup­port ex­ten­ded AP­DUs
  • I want to make sure what I write in the HOW­TOs is also suit­able for the use with Win­dows /​ PuTTY
  • it seems Win­dows needs a cer­ti­fic­ate and not only a key when us­ing the Win­dows CAPI (us­ing the vendor sup­plied card read­er driver) in PuTTY-​CSC (works at work with a USB token)
  • the pc­sc pkcs11 Win­dows DLL is not suit­able yet for use on Win­dows 8 64bit
  • I con­tac­ted the card read­er vendor if the card read­er or the driver is the prob­lem re­gard­ing the ex­ten­ded AP­DUs
  • I found prob­lems in gpg4win /​ pc­sc on Win­dows 8
  • I have send some money to the de­velopers of gpg4win to sup­port their work (if you use gnupg on Win­dows, try to send a few units of money to them, the work stag­nated as they need to spend their time for paid work)

So either I need a new card read­er, or have to wait for an up­date of the linux driver of the vendor… which prob­ably means it may be a lot faster to buy a new card read­er. When look­ing for one with at least a PIN pad, I either do not find any­thing which is lis­ted as sup­por­ted by pc­sc on the vendor pages (it is in­cred­ible how hard it is to nav­ig­ate the web­sites of some com­pan­ies… a lot of buzzwords but no way to get to the real products), or they only list up­dated mod­els where I do not know if they will work.

When I have some­thing which works with FreeBSD and Win­dows, I will pub­lish all the HOW­TOs here at once.

More drivers avail­able in the FreeBSD-​kernel doxy­gen docs

Yes­ter­day I com­mit­ted some more con­figs to gen­er­ate doxy­gen doc­u­ment­a­tion of FreeBSD-​kernel drivers. I mech­an­ic­ally gen­er­ated miss­ing con­figs for sub­dir­ect­or­ies of src/​sys/​dev/​. This means there is no de­pend­ency in­form­a­tion in­cluded in the con­figs, and as such you will not get links e.g. to the PCI doc­u­ment­a­tion, if a driver calls func­tions in the PCI driver (feel free to tell me about such de­pend­en­cies).

If  you want to gen­er­ate the HTML or PDF ver­sion of some sub­sys­tem, just go to src/​tools/​kerneldoc/​subsys/​ an run “make” to get a list of tar­gets to build. As an ex­ample, “make dev_​sound” will gen­er­ate the HTML ver­sion for the sound sys­tem, “make pdf-​dev_​sound” gen­er­ates the PDF ver­sion. The sound sys­tem is prob­ably the most “nice” ex­ample, as it in­cludes a page with TODO items, and has even some real API docs in­stead of just the call-​graphs and such auto­mat­ic­ally gen­er­ated in­form­a­tion.

Some drivers already have (some) doxy­gen markup (I did just a quick grep for „/​*[*!]“ to de­tect doxy­gen markup in­dic­at­ors, no idea about the cov­er­age or qual­ity), namely:

There is more doc­u­ment­a­tion than only for those drivers, I just lis­ted those as there are at least parts of doxy­gen doc­u­ment­a­tion in­side.

VDR ports docs

After a quick dis­cus­sion with nox@ I made a copy&paste of his “VDR is com­mit­ted now”-mail in­to the FreeBSD wiki. I also re-​styled some small parts of it to fit bet­ter in­to the wiki. It is not per­fect, but already us­able. Now in­ter­ested people can go and im­prove the docs there.

Thanks to Juer­gen for all his work in this area!

Doxy­gen stuff up­dated in 9-​current

I com­mit­ted my patch for tools/​kerneldoc/​subsys. Ex­cept for not gen­er­at­ing the PDF part, this is now the same con­fig which I use to gen­er­ate the on­line ver­sion. While writ­ing the com­mit log I no­ticed that I did more changes than I thought…

So any­one who wants to gen­er­ate the Doxy­gen docs of some FreeBSD ker­nel sub­sys­tems on his own, can do it now. Adding more sub­sys­tems is easy, just make a copy of one the the ex­ist­ing Doxyfile-* files – keep the same nam­ing scheme – and change the con­tents. Everything else is handled auto­mat­ic­ally.

I also ad­ded a link to the FreeBSD wiki. It is not at a prom­in­ent place (near the end of the main page), but at least someone can find the link to the my FreeBSD-doxy­gen page there.

HOWTO: “Blind” re­mote in­stall of FreeBSD via tiny disk im­age

In this post I write how to in­stall FreeBSD on a re­mote linux sys­tem by cre­at­ing a root im­age pre­pared for mir­ror­ing on a loc­al sys­tem. There is no (free) ac­cess to the re­mote con­sole, only ac­cess via ssh.

In this post I write how to in­stall FreeBSD on a re­mote linux sys­tem by cre­at­ing a root im­age pre­pared for mir­ror­ing on a loc­al sys­tem. There is no (free) ac­cess to the re­mote con­sole, only ac­cess via ssh.

Back­ground story

While I was at the uni­ver­sity, I worked re­motely for an ISP (ad­min­is­tra­tion of sev­er­al FreeBSD sys­tems). Dur­ing this time I star­ted to use my own do­main, and I was al­lowed to host it dir­ectly at the ISP for free. I tried to not use too much space on the hard­disk (at the end about 400 MB) and to not provide some­thing which at­trac­ted too much people to keep the band­with on a sane level. After the uni­ver­sity I was still avail­able to an­swer ques­tions, and I was still al­lowed to host my web­site there for free. As the num­ber of ques­tions can be coun­ted with IIRC one hand since then, I de­cided at some point (re­cently, to be ex­act – bet­ter late than nev­er) to move my web­site to a dif­fer­ent place (I am still avail­able if they have some ques­tions – for free – but I do not ex­pect to get much ques­tions from them).

At the same time my broth­er de­cided to move to a new serv­er hoster, as his old one de­cided to in­crease the amount of money cus­tom­ers have to pay for the ser­vice. So we searched to­geth­er a new ISP where he either could host his serv­er, or get a root­serv­er for a good price (the idea was to have my do­main in a jail on a serv­er of the com­pany of my broth­er, and we share the costs for it). We found Man­itu (the own­er has even a blog about his busi­ness), which is even not far away from my place.

Un­for­tu­nately they do not provide FreeBSD pre­in­stalled on their root­serv­ers, but they of­fer a re­mote res­cue sys­tem (read: boot­ing a linux im­age… I as­sume via PXE or sim­il­ar) and we knew someone who has some serv­ers there, so I was able to get a rough idea what kind of hard­ware is used there (the hard facts like PCI IDs and such). The idea was to build a very small disk im­age, put it on the hard­disk over the net­work via the re­mote res­cue sys­tem, and then to con­fig­ure the re­mainder of the harddisk(s) to use it. And here is how I did it (my broth­er thought “who is bet­ter suited to in­stall a FreeBSD sys­tem re­motely without ac­cess to the con­sole of the ma­chine (the ISP of­fers to hook up a KVM switch, but only dur­ing busi­ness hours and you have to pay for it) than one of the de­velopers of FreeBSD…”).


In the title of this post I wrote “via a tiny disk im­age”. This is true for a suit­able defin­i­tion of tiny.

What we have in the root­serv­er are two 160 GB hard­disks. They shall be used in a soft­ware mir­ror (via gmir­ror). The root-​FS shall have about 5 GB. This is more than needed, but as this is only 3% of one hard­disk, I prefer to keep it a little bit big­ger than too small after an re­mote up­date or two. The ma­chine has 2 GB of RAM. We do not ex­pect much ker­nel pan­ics (= crash dumps) there, so we do not really need >2 GB of swap (for­get the rule of hav­ing twice as much swap than RAM, with the cur­rent amount of RAM in a ma­chine you are in “trouble” when you need even the same amount of swap than RAM). I de­cided to go with 1 GB of swap (mirrored too, to pre­vent a hard­disk fail­ure to take down the ma­chine), this is more than enough. The rest of the hard­disk will be used for jails, the distfiles/​packages for/​of the ports, and as WRKDIRPREFIX when build­ing ports.

Now, pushing/​pulling a 160 GB im­age over the net­work to in­stall a sys­tem is not really some­thing I want to do. I would prefer to trans­fer less than 500 MB (that is 0.3% of the en­tire disk) to get this job done, and this is feas­ible. Due to an er­ror or two I had to trans­fer the im­age sev­er­al times un­til everything was work­ing, so it was more in the area of maybe 2 GB (~1% of the en­tire disk).

First let us define some vari­ables in the shell, this way you just need to change the val­ues in one place and the rest is copy&paste:


Then change your cur­rent dir­ect­ory to a place where you have enough space for the im­age. There we will cre­ate a con­tain­er for the im­age, and make it ready for par­ti­tion­ing:

trun­cate -s ${ROOTFS_​SIZE} ${FILENAME}
md­con­fig -a -t vnode -f ${FILENAME}

Cre­ate the root­fs:

# cre­ate one act­ive FreeBSD slice with $ROOTFS_​SIZE GB
fdisk -e /​dev/​mdX
gmir­ror la­bel ${ROOTFS_​NAME} /​dev/​mdXsY
bsdla­bel -w /​dev/​mirror/​${ROOTFS_​NAME}
# cre­ate an “a”-partition for everything
bsdla­bel -e /​dev/​mirror/​${ROOTFS_​NAME}
new­fs -U /dev/mirror/${ROOTFS_NAME}a

Mount the new root­fs to /​mnt and in­stall FreeBSD:

mount /dev/mirror/${ROOTFS_NAME}a /​mnt
cd /​usr/​src
make build­world >&! buildworld.log
make buildker­nel >&! build_generic.log
make in­stall­world DESTDIR=/mnt
make dis­tri­bu­tion DESTDIR=/mnt
make in­stallker­nel DESTDIR=/mnt

Now you need to cre­ate /mnt/etc/rc.conf (set the de­faultrouter, the IP ad­dress via ifconfig_​IF (and do not for­get to use the right IF for it), the host­name, set sshd_​enable to yes, add an user (I used “vipw -d /​mnt/​etc”) which is in the wheel group so you can lo­gin re­motely, and maybe oth­er things you are in­ter­ested in), /mnt/etc/resolv.conf, /​mnt/​etc/​hosts. Fi­nally, do not for­get to load the gmir­ror mod­ule, it will safe a lot of head-​scratching (yes, an echo would be short­er, but WP con­verts the single-​quotes to double-​quotes), and add the root­fs to the fstab:

cat > /mnt/boot/loader.conf «EOT
echo “/​dev/​mirror/​root0a /​ ufs rw,noatime 1 1” >/​mnt/​etc/​fstab

Now we are ready to in­stall, the im­age can be un­moun­ted:

umount /​mnt

The fi­nal steps are to lo­gin in­to the res­cue con­sole (the­or­et­ic­ally you should be able to over­write even a run­ning sys­tem, but then you need to make sure there is a way to power-​cycle the sys­tem re­motely to force a re­boot) of the new sys­tem and to in­stall via a com­pressed ssh con­nec­tion (my re­mote res­cue sys­tem is a linux sys­tem, so linux-​syntax has to be used). The lo­gin to the res­cue con­sole is not shown here, but the in­stall from the re­mote sys­tem is simple (this as­sumes the im­age resides on a sys­tem which is ac­cess­ible from the new sys­tem):

ssh -C -o CompressionLevel=9 user@myhost cat /path/to/${FILENAME} | dd of=/dev/hda bs=1m

Al­tern­at­ively you can com­press it with bzip2 on your sys­tem and add an bunzip2 in­to the pipe above. This way you could even use an HTTP serv­er to fetch the file from, but then the com­mand to fetch the file needs to have a way to out­put the file it down­loads on stdout. Both ways of trans­fer­ring the im­age de­pend upon the sta­bil­ity of the trans­fer. If the con­nec­tion is cut, the sys­tem can not boot any­more. So if you do not have a res­cue con­sole which is in­de­pend­ent from the con­tent of the hard­disk, you bet­ter have a plan B.

If I did not make an er­ror here (I did this some months ago, I hope I did not for­get to write down some im­port­ant step and also cor­rec­ted all steps which where not writ­ten down cor­rectly), you did everything cor­rectly too, and the re­mote sys­tem does not need oth­er ker­nel mod­ules loaded, you can now re­boot the new sys­tem, cross your fin­gers for some mo­ments, and then lo­gin to the new sys­tem.

Post in­stall TODO

Now you should have a ba­sic sys­tem up and run­ning, and you can start to con­fig­ure it.

I ad­ded two more FreeBSD par­ti­tions, 1 GB for swap, and the rest of the hard­disk (I took care to not have the last par­ti­tion cov­er also the last sec­tor of the hard­disk, else gmir­ror will think it has to mir­ror the en­tire hard­disk and not only the last par­ti­tion) as one big par­ti­tion. For the second hard­disk I made the same par­ti­tion­ing as for the first hard­disk.

Then I cre­ated two more gmir­rors, one mir­ror for the swap, and one for the rest of the space. The mir­ror for the swap I cre­ated with the op­tion “-F”, to not syn­chron­ize the par­ti­tion after a power fail­ure (not ne­ces­sary for swap). All two I also cre­ated with the “-n” op­tion, to not sync the con­tents (there is noth­ing yet, so it does not mat­ter what is writ­ten there).

Now just a quick “bsdla­bel” on the two mir­rors to cre­ate a “b”-partition for the swap and a “d”-partition for the large par­ti­tion. To add the swap it is just an “echo /​dev/​mirror/​swap0b none swap sw 0 0 >/​etc/​fstab”. Do not for­get to add the big par­ti­tion to the fstab (after do­ing a “new­fs” off course).

To be sure it will sur­vive a re­boot, do a quick test of manu­ally mount­ing the big par­ti­tion (use the easy manu­al way via “mount /​place/​where/​it/​is/​mounted” after adding it to the fstab, not the com­plete manu­al way, this is meant to test the fstab entry too), and a “swa­pon -a” to test the swap. I also made a re­boot test, just to be sure everything is ok.

The fi­nal step was to add the par­ti­tion on the second hard­disk to the root­fs (“gmir­ror in­sert ${ROOTFS_​NAME} /​dev/​…”).

Daily doxy­gen gen­er­ated docs of the FreeBSD ker­nel (head)

I man­aged to get some time to setup an auto­mated gen­er­a­tion of the doxy­gen docs for ker­nel sub­sys­tems of FreeBSD on my web­serv­er.

Every night/​morning (Ger­man timezone) the sources will be up­dated, and the docs get re­gen­er­ated (this takes some time). Cur­rently this de­pends upon some patches to the make­file and doxy­gen con­fig files in tools/​kerneldoc/​subsys. Everything is gen­er­ated dir­ectly in the place where the web­serv­er will look for to de­liv­er the pages, so if you browse this in the middle of the gen­er­a­tion, the con­tent may not be con­sist­ent (yet).

Please be nice to the web­serv­er and do not mir­ror this. You can gen­er­ate this your­self very easy. As­sum­ing you have the FreeBSD source on a loc­al hard disk, you just need to down­load the patch from http://​www​.Leidinger​.net/​F​r​e​e​B​S​D​/​c​u​r​r​e​n​t​-​p​a​t​c​h​es/ (if you do not find dox.diff, up­date your FreeBSD sources and everything will be OK), ap­ply the patch, cd in­to tools/​kerneldoc/​subsys and run “make all” (or “make vm” or whatever you are in­ter­ested in). You need doxy­gen in­stalled, off course.

If you want to setup some­thing like this your­self, just down­load the script which is do­ing all the work, change some vari­ables in the be­gin­ning, and cre­ate your own loc­al ver­sion of the com­plete docs.

In case this is us­ing sig­ni­fic­ant traffic, I will ask core/​ad­mins if there is the pos­sib­il­ity to host it on re­sources.

A little bit of cleanup

I com­mit­ted a little bit of cleanup /​ some XXX com­ments to the sound­sys­tem, ex­ten­ded the linux(4) man page a little bit and re­moved some al­pha spe­cif­ic sec­tion 4 man pages which where over­looked at the time al­pha was re­moved from cur­rent.

I think I will en­joy the sun in the back­yard a little bit now… 😎