It doesn’t hit on the breakpoints for some reason. I’m most likely doing something wrong.
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “–host=i486-pc-netbsd –target=i386-linux-gnuaout”…
Setting up the environment for debugging gdb.
Breakpoint 1 at 0x94a4: file panic.c, line 18.
Breakpoint 2 at 0x667b: file init/main.c, line 110.
tcp_open ! localhost:1234
0xfff0 in sys_unlink () at memory.c:430
Program received signal SIGINT, Interrupt.
panic (s=0x1dd6c “”) at panic.c:23
#0 panic (s=0x1dd6c “”) at panic.c:23
#1 0xd9b3 in mount_root () at memory.c:430
#2 0x12f39 in sys_setup (BIOS=0x1ab38) at hd.c:157
#3 0x7477 in system_call () at sched.c:412
#4 0x1000000 in ?? ()
But after a LOT of struggling it certainly looks about right.
I then went ahead and built GDB 8.0.1, and it’s incredibly slow, and I guess not too compatible with Qemu 0.9 (I had issues with newer builds though) but it does break.
(top-gdb)target remote localhost:1234
Remote debugging using localhost:1234
0x0000fff0 in sys_unlink () at memory.c:83
Num Type Disp Enb Address What
1 breakpoint keep y 0x000094a4 in panic at panic.c:18
2 breakpoint keep y 0x000094a4 in panic at panic.c:18
Breakpoint 1, panic (s=0xd8cf <sys_mount+227>) at panic.c:18
18 printk(“Kernel panic: %s\n\r”,s);
Reply contains invalid hex digit 79
Reply contains invalid hex digit 79
#0 0x0000d9b3 in mount_root () at memory.c:83
#1 0x0001ab60 in hd_info ()
#2 0x00000000 in ?? ()
eax 0x0 0
ecx 0x51 81
edx 0x1fb4c 129868
ebx 0x0 0
esp 0xffff94 0xffff94
ebp 0xffffa8 0xffffa8
esi 0x1ab60 109408
edi 0x0 0
eip 0xd9b3 0xd9b3 <mount_root+139>
eflags 0x246 [ PF ZF IF ]
cs 0x8 8
ss 0x10 16
ds 0x10 16
es 0x10 16
fs 0x17 23
gs 0x17 23
And while it more or less runs there is some issues using the GDB stub from Qemu 0.9.0, although I had a world of pain with newer versions. And I’ve never done the kernel debug thing before so this is all new to me.
And I guess it goes as no surprise that with GDB 8, they have a.out Linux tagged as obsolete and to be removed. I guess I need to try a GDB that was current to Qemu 0.90 so it may not have so many packet overruns and unexpected results…
So it’s always a fun time for me to push my old project Ancient Linux on Windows. And what makes this so special? Well it’s a cross compiler for the ancient Linux kernels, along with source to the kernels so you can easily edit, compile and run early Linux from Windows!
As always the kernels I have built and done super basic testing on are:
All of these are a.out kernels, like things were back in the old days. You can edit stuff in notepad if you so wish, or any other editor. A MSYS environment is included, so you can just type in ‘make’ and a kernel can be built, and it also can be tested in the included Qemu. I’ve updated a few things, first with better environment variables, and only tested on Windows 10. Although building a standalone linux EXE still requires a bit of work, it isn’t my goal here as this whole thing is instead geared around building kernels from source. I included bison in this build, so more of GCC is generated on the host. Not that I think it matters too much, although it ended up being an issue doing DooM on GCC 1.39.
So for people who want to relive the good old bad days of Linux, and want to do so from the comfort of Windows, this is your chance!
The line that says “Running inside a VM; adjusting spinout timeout to 180 seconds” would suggest that KVM implements enough of our backdoor interface to make it look like we’re running under a VMware hypervisor. When we’re running in this environment, we use the backdoor to get the host TSC frequency. I suspect that KVM doesn’t implement the “GETMHZ” backdoor call, so we are confused about the TSC frequency. The 30ms delay turns into … 30 hours? 30 years?
So they had a source code change for QEMU 1.7.0, however it obviously doesn’t work in 2.x. It was rolled up stream, and then made into a switch to disable with a simple flag to add into the command line.
So with VIRL in hand, the next thing I wanted to do was play with some LACP, and VMWare ESX. Of course the best way to do this is under KVM as you can use UDP to bounce packets around between virtual machines, like the VIRL L2 switch. I went ahead and fired up 5.5 and got this nice purple screen of death.
So naturally I need to force the processor type. Also after reading a few sites, I needed to turn on a nested & ignore_msrs settings:
So it’s basically the same, just no mounted CD-ROM image. Now this is all fun, but what about networking? As I had mentioned before, I bought a VIRL license, which includes a l2 Catalyst image, so why not use that, instad of a ‘traditional’ Linux bridge? Sure! In this example I’m going to connect the 4 ethernet ports from the ESXi into the first 4 ports on the cisco switch, with the last port connecting to a Linux bridge, that I then route to, as I wanted all my lab crap on a seperate network. To start the switch I use this script:
Now as you can see the udp sockets are inverse of eachother, meaning that the ESX listens on 10000 and sends to 127.0.0.1 on port 20000, while the switch listesns on 20000, and sends packets to 10000 for the first ethernet interface pair.
By default VMware only assigns the first NIC into the first virtual switch, so after enabling CDP, we can see we have basic connecitivity:
AMD-kvm#sho run int gig0/1
Current configuration : 99 bytes
no negotiation auto
AMD-kvm#show cdp neigh
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
S – Switch, H – Host, I – IGMP, r – Repeater, P – Phone,
D – Remote, C – CVTA, M – Two-port Mac Relay
Device ID Local Intrfce Holdtme Capability Platform Port ID
KVMESX-1 Gig 0/0 155 S VMware ES vmnic0
Total cdp entries displayed : 1
And of course the networking actually does work… I created a quick VM, and yep, It’s online!
AMD-kvm#show mac address-table
Mac Address Table
Vlan Mac Address Type Ports
—- ———– ——– —–
1 000c.2962.09e5 DYNAMIC Gi0/0
1 002e.3c92.2600 DYNAMIC Gi0/0
1 76b0.3336.34b3 DYNAMIC Gi2/3
Total Mac Addresses for this criterion: 3
And of course some obliguttory pictures:
With ip forwarding turned on my Ubuntu server, and an ip address assigned to my bridge interface, I can then access the NT 4.0 VM from my laptop directly.
Nex’t time to make the L2 more complicated, and add in some L3 insanity…
Ugh. nothing like ancient crypto, major security vulnerabilities, and ancient crap. So first I’m going to use Juniper’s SDK (get it while you can, if you care). Note that the product is long since EOL’d, and all support is GONE. I’m using Debian 7 to perform this query, although I probably should be using something like 4 or 5. Anyways first off is that the python examples require “Ft.Xml.Domlette” which doesn’t seem to have a 4Suite-XML package. SO let’s build it the old fashioned way:
apt-get install build-essential python-dev
tar -xvvf 4Suite-XML-1.0.2.tar.bz2
Well (for now) and in my case I could reconfigure tomcat to be slightly more secure. Otherwise running the examples gives this fun filled error:
ssl.SSLError: [Errno 1] _ssl.c:504: error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small
Naturally as time goes on this will not work anymore, and I’ll need a stale machine to query this stale service. Using ssl shopper’s Tomcat guide, I made changes to the server.xml file on the vGW SD VM. (Don’t forget to enable SSH in the settings WebUI, and then login as admin/<whatever password you gave> then do a ‘sudo bash’ to run as root, screw being nice!
And you get the idea. Certainly on the one hand it’s nice to get some data out of the vGW without using screen captures or anything else equally useless, and it sure beats trying to read stuff like this:
What on earth was Altor/Juniper thinking? Who thought making the screen damned near impossible to read was a “good thing”™
Naturally someone here is going to say, upgrade to the last version it’ll fix these errors, and sure it may, but are you going to bet a production environment that is already running obsolete software on changing versions? Or migrate to a new platform? Sure, the first step I’d want of course is a machine formatted rule export of the existing rules. And here we are.
Of course the real fun comes from trying to find the devices. Having to dig around I found that the device major is 98 for the UBD’s and that they incrament by 16, so that the first 3 devices are as follows:
mknod /dev/ubda b 98 0
mknod /dev/ubdb b 98 16
mknod /dev/ubdc b 98 32
Adding to that, you can partition them, and then they break out like this:
mknod /dev/ubda1 b 98 1
mknod /dev/ubda2 b 98 2
mknod /dev/ubda3 b 98 3
mknod /dev/ubdb1 b 98 17
mknod /dev/ubdb2 b 98 18
You get the idea.
With the disk added you can partition the ubd like a normal disk
node1:~# fdisk /dev/ubdb
Command (m for help): p
Disk /dev/ubdb: 1073 MB, 1073741824 bytes
128 heads, 32 sectors/track, 512 cylinders
Units = cylinders of 4096 * 512 = 2097152 bytes
Device Boot Start End Blocks Id System
/dev/ubdb1 1 245 501744 83 Linux
/dev/ubdb2 246 512 546816 82 Linux swap / Solaris
etc etc. And yes, you can then format, mount and all that.
First let’s setup the swap:
Now let’s format the additional /tmp partition
node1:~# mke2fs /dev/ubdb1
mke2fs 1.40-WIP (14-Nov-2006)
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
125488 inodes, 501744 blocks
25087 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67633152
62 block groups
8192 blocks per group, 8192 fragments per group
2024 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 24 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
Now adding the following to the /etc/fstab so it’ll automatically mount the /tmp directory and add the swap:
I’m using Slackware 4.0 as a starting point, so it’s Binutils 2.9.1 and GCC 188.8.131.52 .. I verified that I can build a static hello world executable, and it runs! …
However Linux 2.0.40 has the same issue, it starts to decompress, and triggers a reboot in both Qemu and PCem. Going in circles I guess. I suppose the next step is to use the exact version they have in Slackware to see if Qemu can actually run that pre-built kernel, and if I can create one via cross compiling.
I should add that on Debian 7.1 I got GCC 184.108.40.206 running, and it too produces the exact same thing.
After getting Linux 0.98 to compile, I thought I’d take a stab at Linux 1.0. I vaugely recall when it was released, and I just remember a much larger push to 1.1. So I guess it really comes as no surprise that in the Linux kernel archives, there is simply the 1.0 tar, and 9 patch files.
I went ahead, and patched up the release, and then tried to build with GCC 2.3.3. This however proved not to be up to the task, as 2.3.3 has issues with some of the assembly macros, so delving into the readme shows that you need to use GCC 2.4.5 or higher. Since I wanted to keep at least the tools on par, I went ahead and build 2.4.5, and once more again used the gcc driver from 2.6.3. I further ended up relying on headers, and checking tool versions from Debian 0.91, which also revealed that they were still using GAS 1.38 back then.
One interesting note while building piggback, which takes the compressed system object, and wraps it in an object file, is that it directly uses the magic “0x00640107”, which is for a later “Linux/i386 impure executable (OMAGIC)” filetype. But because my binutils is so ancient, I needed to change it to “0x00000107” so that the linker would recognize it as a “386 executable not stripped” file. As always when having no idea what I was doing, it was easier to have it make an empty object file, set the type for 12345678 and look for where it occurs in the data stream, and just match it with a known object file. As you can see, it worked.
I don’t know if it is of any interest, but the kernel source, along with a binary is available to download linux-220.127.116.11z, and the same goes for GCC gcc-18.104.22.168z.
And of course, you’ll want the latest download, which includes the pre-built tools, qemu, and build environment to get you started.