Resetting the root password on Fedora

Yesterday I made a Fedora 30 VM on my RHEL 7 box, and for some reason I couldn’t log in as root after the installation finished. Well, it’s been a while, so I had to look it up, and following the instructions didn’t work either—I finally managed to get a shell, but the terminal was corrupted. Because it was a VM? Because the instructions were out of date? I’ve no idea. Anyway, here’s what I did, with the stuff that wasn’t in the instructions kind of yellowish:

  1. Reboot and wait for the GRUB menu to appear. You may need to be pressing Shift for this to happen.
  2. In the menu, highlight any entry and press e to edit it.
  3. Find the line beginning with linux. Remove the rhgb and quiet options, then add init=/bin/sh at the end of the line.
  4. Press Ctrl-X to boot with those options. After a while you should get a root shell. The prompt was sh-5.0# on my system, not sh-4.2# like the instructions say, but it doesn’t matter.
  5. Run the commands in the instructions: 
    /usr/sbin/load_policy -i
mount -o remount,rw /
passwd root
mount -o remount,ro /
  6. The instructions say to reboot now, but none of the commands to reboot the system worked at this point. Probably they expected systemd. No problem, I hit “Force Reset” in Virtual Machine Manager. I probably should have run a sync or two beforehand, but I didn’t think to.

Ta-da, working system!

Full-system Infinity preview coming up

I’ve released bits and pieces of Infinity over the past year, but nothing that really brings everything together. Right now I’m working on an initial full-system release of everything to do with Infinity so far. It’s codenamed “First Flight”, and you’ll be able to actually use it, see how everything hangs together, and generally get a better idea of what the point of it all is.

First Flight will be just enough for GDB to attach to a live process or start with a core file. “info threads” should work, “print errno” will not. First Flight will comprise:

  • A new release of the note compiler I8C.
  • A glibc you can git clone and build to get a libpthread.so with Infinity notes for map_lwp2thr, thr_get_info and thr_iter.
  • A new release of the client library libi8x that can execute those notes.
  • A libthread_db.so shim into libi8x.

The libthread_db.so shim won’t be used in future releases—they’ll have support for Infinity built into GDB—but it’ll likely remain as a nice example of how to use libi8x.

I’m targeting June 23 as the release date for First Flight. You can follow how I’m doing on the Infinity Roadmap (thank you Sergio!)

Infinity client library

This past few weeks I’ve been working on an Infinity client library. This is what GDB will use to execute notes it finds. It’s early days, but it executed its first note this morning so I thought I’d put something together so people can see what I’m doing. Here’s how to try it out:

  1. Install elfutils libelf development stuff if you don’t have it already, the tlsdump example program needs it: 
    sudo yum install elfutils-libelf-devel  # Fedora, RHEL, etc...
sudo apt-get install libelf-dev         # Debian, Ubuntu, etc...
  2. Download and build the Infinity client library and example program: 
    git clone -b libi8x-0.0.1 https://github.com/gbenson/libi8x.git libi8x-0.0.1
cd libi8x-0.0.1
./autogen.sh
./configure --enable-logging --enable-debug
make
  3. Check the tlsdump example program built: 
    bash$ ls -l examples/tlsdump
-rwxr-xr-x. 1 gary gary 5540 Apr 20 12:52 examples/tlsdump

    Yeah, there it is! (if it’s not there go back to step 0)

  4. Build a program with notes to run the example program against: 
    gcc -o tests/ifact tests/ifact.S tests/main.c
  5. Run the program you just built: 
    bash$ tests/ifact &
[2] 8301
Hello world I'm 8301
  6. Run the libi8x tlsdump example program with the test program’s PID as it’s argument: 
    $ examples/tlsdump 8301
0! = 1
1! = 1
2! = 2
3! = 6
4! = 24
5! = 120
6! = 720
7! = 5040
8! = 40320
9! = 362880
10! = 3628800
11! = 39916800
12! = 479001600

What just happened? The executable test/ifact you built contains a single Infinity note, test::factorial(i)i, the source for which is in tests/ifact.i8. The tlsdump example located the ifact executable, loaded test::factorial(i)i from it, and ran it a few times printing the result:

  err = i8x_ctx_get_funcref (ctx, "test", "factorial", "i", "i", &fr);
  if (err != I8X_OK)
    error_i8x (ctx, err);

  err = i8x_xctx_new (ctx, 512, &xctx);
  if (err != I8X_OK)
    error_i8x (ctx, err);

  for (int i = 0; i < 13; i++)
    {
      union i8x_value args[1], rets[1];

      args[0].i = i;
      err = i8x_xctx_call (xctx, fr, NULL, args, rets);
      if (err != I8X_OK)
	error_i8x (ctx, err);

      printf ("%d! = %d\n", i, rets[0].i);
    }

To see some debug output try this:

I8X_LOG=debug examples/tlsdump PID

Also try I8X_DEBUG=true in addition to I8X_LOG=debug to trace the bytecode as it executes.

Infinity status

I’m winding down for a month away from Infinity. The current status is that the language and note format changes for 0.0.2 are all done. You can get them with:

git clone https://github.com/gbenson/i8c.git

There’s also the beginnings of an Emacs major mode for i8 in there too. My glibc tree now has notes for td_ta_thr_iter as well as td_ta_map_lwp2thr. That’s two of the three hard ones done. Get them with:

git clone https://github.com/gbenson/glibc.git -b infinity2

FWIW td_thr_get_info is just legwork and td_thr_tls_get_addr is just a wrapper for td_thr_tlsbase; td_thr_tlsbase is the other hard note.

All notes have testcases with 100% bytecode coverage. I may add a flag for I8X to make not having 100% coverage a failure, and make glibc use it so nobody can commit notes with untested code.

The total note size so far is 720 bytes so I may still manage to get all five libpthread notes implemented in less than 1k:

Displaying notes found at file offset 0x00018f54 with length 0x000002d0:
  Owner                 Data size	Description
  GNU                  0x00000063	NT_GNU_INFINITY (inspection function)
    Signature: libpthread::__lookup_th_unique(i)ip
  GNU                  0x00000088	NT_GNU_INFINITY (inspection function)
    Signature: libpthread::map_lwp2thr(i)ip
  GNU                  0x000000cd	NT_GNU_INFINITY (inspection function)
    Signature: libpthread::__iterate_thread_list(Fi(po)oipii)ii
  GNU                  0x000000d2	NT_GNU_INFINITY (inspection function)
    Signature: libpthread::thr_iter(Fi(po)oiipi)i

Infinity updates

In case you hadn’t noticed, I8C 0.0.1 was released last week. As well as the note compiler, this package contains I8X, an interpreter for unit testing compiled notes.

In case you had noticed and you’ve been working with it, please note there’s some compatibility-breaking source language and note format changes in the pipeline.

Infinity has a mailing list, and I want you to subscribe to it. Infinity isn’t just my project–anybody who might either produce or consume Infinity notes has a stake in this:

  • If you’re working on a debugger or other tool that might consume Infinity notes then you have a stake.
  • If you’re working on a library that might expose some API via Infinity notes then you have a stake.

I don’t know every issue that Infinity will have to solve, and you know things I need to know. So don’t sit on the sidelines! Send an empty message to infinity-subscribe@sourceware.org and get involved.

Infinity compiler update

I had hoped to make a first release of i8c today but I still have one open issue so you’ll have to wait until next week. Until then here’s some note source for you to ponder:

define test::factorial returns int
    argument int x
    extern func int (int) factorial

    swap
    dup
    load 1
    bne not_done_yet
    return

not_done_yet:
    dup
    load 1
    sub
    swap
    rot
    swap
    call
    mul

As hints I will a) point you at section 2.5 of the DWARF spec, and b) mention that argument and extern directives instruct the caller and runtime respectively to push entries onto the stack.

Your homework is to see how much of the language and runtime you can infer from this one function.

You may ask questions.

Infinity compiler

When I said I’d never written a compiler, that’s actually a lie: I did some work on the Ceylon compiler a few years back. It wasn’t a very enriching experience but at least I know what ASTs and visitors are.

Anyway, the C-like syntax I talked about Friday might have been a little optimistic. I wanted the source to not be full of stack-shuffling but that’s not going to happen. Partly because I’d been assuming that the problem of compiling to a stack-based instruction set was solved: I was thinking of Java, but of course Java has local variables so it’s not exactly a stack-based instruction set, it’s stack and 65,536 registers–kind of the opposite problem! I didn’t find much online about compiling to stack-based instruction sets other than “it’s hard”.

I could probably manage something, but given that the total output of the compiler for glibc will likely be a hundred or so bytes of instructions, it doesn’t make sense to spend a huge amount of time on it.

The Infinity function compiler is therefore going to be something of a helpful assembler.

Infinity function compiler

Yesterday I reworked the note format to allow functions as first-class objects, and then I had an idea about how to implement the note compiler.

I’d already thought I could have the compiler emit assembly to avoid having to think about endianness, but I couldn’t figure out how to do other platform-specific stuff like 32- vs 64-bit, or choosing which of the three LWP ID to thread descriptor mapping styles to use. My idea was to not only output to the assembler but to input from the C preprocessor as well. That way I can do all the conditional stuff in there, driven by glibc’s include files and CPPFLAGS.

Yeah, I think I can write a compiler that knows nothing about the platform it’s compiling for.

So, I spent all morning messing around with glibc’s build system. I’ve come up with this:

  1. Each machine’s tls.h will have some Infinity definitions following the ones for libthread_db. Here’s the one for x86_64: 
    /* Magic for libthread_db to know how to do THREAD_SELF.  */
#define DB_THREAD_SELF_INCLUDE   /* For the FS constant.  */
#define DB_THREAD_SELF CONST_THREAD_AREA (64, FS)

/* Magic for Infinity to know how to do THREAD_SELF.  */
#define I8_THREAD_SELF I8_TS_CONST_THREAD_AREA
#define I8_TS_CTA_VALUE FS

    I could probably generate the libthread_db ones from the Infinity ones… but… later.

  2. glibc has a script to generate assembler include files, to get constants and offsets from C headers into the assembler. I wrote a tls-infinity.sym file that the build system turns into tls-infinity.h for me.
  3. The source for map_lwp2thr is infinity_map_lwp2thr.i8. That includes tls-infinity.h and, on x86_64, conditionally includes infinity_lookup_th_unique_cta.i8 to perform the mapping in the correct way for that platform.
  4. infinity_map_lwp2thr.i8 gets fed into the C preprocessor which a) does all the conditionality and b) expands all the constants (as a total bonus!)

This leaves me with this lovely file to write a compiler for.

I’ve never written a compiler.