config(8) elf handling

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

config(8) elf handling

Jonathan Gray-11
config(8) creates ioconf.c containing

#ifndef MAXEXTRALOC
#define MAXEXTRALOC 32
#endif
long extraloc[MAXEXTRALOC] = { -1 };
int nextraloc = MAXEXTRALOC;
int uextraloc = 0;

When uextraloc gets stored in .bss where filesz < memsz the simplistic
way config(8) reads an entire elf file into memory without parsing
the program headers leads to various crashes or
"Not enough space to change device." if the offset for I_UEXTRALOC
returned by adjust() is within the address space.

Forcing uextraloc into .data via
int uextraloc __attribute__ ((section(".data"))) = 0;
avoids the crashes.

(gdb) run -ef /tmp/bsd.rd
Starting program: /usr/obj/usr.sbin/config/config -ef /tmp/bsd.rd
OpenBSD 6.2-beta (RAMDISK_CD) #88: Mon Sep 11 11:01:29 MDT 2017
    [hidden email]:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
Enter 'help' for information
ukc> change pciide*
 80 pciide* at pci* dev -1 function -1 flags 0x0
change [n] y

Program received signal SIGSEGV, Segmentation fault.
memmove () at /usr/src/lib/libc/arch/amd64/string/memmove.S:62
62              rep
(gdb) bt
#0  memmove () at /usr/src/lib/libc/arch/amd64/string/memmove.S:62
#1  0x00001a0a5b911d21 in change (devno=80) at /usr/src/usr.sbin/config/ukcutil.c:428
#2  0x00001a0a5b913127 in common_dev (dev=0x7f7ffffec9c2 "pciide*", len=6, unit=0, state=2,
    routine=99 'c') at /usr/src/usr.sbin/config/ukcutil.c:889
#3  0x00001a0a5b914faa in Xchange (cmd=0x7f7ffffec9b0) at /usr/src/usr.sbin/config/cmd.c:124
#4  0x00001a0a5b914667 in config () at /usr/src/usr.sbin/config/ukcutil.c:1330
#5  0x00001a0a5b910624 in ukc (file=0x7f7ffffee0f4 "/tmp/bsd.rd", outfile=0x0, uflag=0,
    force=1) at /usr/src/usr.sbin/config/ukc.c:156
#6  0x00001a0a5b903e6f in main (argc=1, argv=0x7f7ffffedfa8)
    at /usr/src/usr.sbin/config/main.c:172

With the patch below to error out

$ ./obj/config -ef /tmp/bsd.rd  
OpenBSD 6.2-beta (RAMDISK_CD) #88: Mon Sep 11 11:01:29 MDT 2017
    [hidden email]:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
Enter 'help' for information
ukc> change pciide*
 80 pciide* at pci* dev -1 function -1 flags 0x0
change [n] y
config: symbol 0xffffffff8189ea48 in section 5 ph 3 ELF filesz < memsz not handled
$ nm /tmp/bsd.rd | fgrep ffffffff8189ea48                                                
ffffffff8189ea48 B uextraloc

$ readelf -Wa /tmp/bsd.rd | head -48
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0xffffffff81000158
  Start of program headers:          64 (bytes into file)
  Start of section headers:          9080584 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         5
  Size of section headers:           64 (bytes)
  Number of section headers:         10
  Section header string table index: 7

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        ffffffff81000158 000158 335e98 00  AX  0   0 4096
  [ 2] .rodata           PROGBITS        ffffffff81336000 336000 161f90 00  WA  0   0 16
  [ 3] .openbsd.randomda PROGBITS        ffffffff81498000 498000 002400 00  WA  0   0 16
  [ 4] .data             PROGBITS        ffffffff8149b000 49b000 3b2ad8 00  WA  0   0 4096
  [ 5] .bss              NOBITS          ffffffff8184e000 84dad8 092000 00  WA  0   0 4096
  [ 6] .SUNW_ctf         PROGBITS        0000000000000000 84dad8 05b3da 00      0   0  1
  [ 7] .shstrtab         STRTAB          0000000000000000 8a8eb2 000052 00      0   0  1
  [ 8] .symtab           SYMTAB          0000000000000000 8a9188 068460 18      9 1754  8
  [ 9] .strtab           STRTAB          0000000000000000 9115e8 044d98 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  LOAD           0x000000 0xffffffff81000000 0x0000000001000000 0x335ff0 0x335ff0 R E 0x100000
  LOAD           0x336000 0xffffffff81336000 0x0000000001336000 0x164400 0x164400 RW  0x100000
  LOAD           0x49b000 0xffffffff8149b000 0x000000000149b000 0x3b2ad8 0x3b2ad8 RW  0x100000
  LOAD           0x74e000 0xffffffff8184e000 0x000000000184e000 0x000000 0x092000 RW  0x100000
  OPENBSD_RANDOM 0x498000 0xffffffff81498000 0x0000000001498000 0x002400 0x002400 RW  0x10

Index: exec_elf.c
===================================================================
RCS file: /cvs/src/usr.sbin/config/exec_elf.c,v
retrieving revision 1.15
diff -u -p -r1.15 exec_elf.c
--- exec_elf.c 3 Jun 2017 23:31:37 -0000 1.15
+++ exec_elf.c 13 Sep 2017 03:56:46 -0000
@@ -51,7 +51,7 @@ off_t elf_size;
 caddr_t
 adjust(caddr_t x)
 {
- int i;
+ int i, j;
  Elf_Shdr *s;
  unsigned long y = 0;
 
@@ -62,6 +62,14 @@ adjust(caddr_t x)
  continue;
  if (((unsigned long)x >= s[i].sh_addr) &&
     ((unsigned long)x < (s[i].sh_addr+s[i].sh_size))) {
+ for (j = 0; j < elf_ex.e_phnum; j++) {
+ if ((elf_phdr[j].p_vaddr == s[i].sh_addr) &&
+    (elf_phdr[j].p_memsz == s[i].sh_size) &&
+    (elf_phdr[j].p_filesz < elf_phdr[j].p_memsz))
+ errx(1, "symbol %p in section %d ph %d"
+    " ELF filesz < memsz not handled",
+    x, i, j);
+ }
  y = (unsigned long)&elf_total[(unsigned long)x -
     s[i].sh_addr + s[i].sh_offset];
  break;

Index: mkioconf.c
===================================================================
RCS file: /cvs/src/usr.sbin/config/mkioconf.c,v
retrieving revision 1.36
diff -u -p -r1.36 mkioconf.c
--- mkioconf.c 27 Oct 2016 14:33:30 -0000 1.36
+++ mkioconf.c 13 Sep 2017 04:33:47 -0000
@@ -183,7 +183,7 @@ static long loc[%d] = {", locators.used)
 #endif\n\
 long extraloc[MAXEXTRALOC] = { -1 };\n\
 int nextraloc = MAXEXTRALOC;\n\
-int uextraloc = 0;\n") < 0);
+int uextraloc __attribute__ ((section(\".data\"))) = 0;\n") < 0);
 }
 
 static int nlocnames, maxlocnames = 8;

Reply | Threaded
Open this post in threaded view
|

Re: config(8) elf handling

Miod Vallat

> Forcing uextraloc into .data via
> int uextraloc __attribute__ ((section(".data"))) = 0;
> avoids the crashes.

Regardless of this bug, the in-tree gcc was modified to default to put
explicitly zero initialized data in .data rather than .bss, i.e. default
to -fno-zero-initialized-in-bss.

It might be wise to make the default configuration of clang follow this
behaviour as well.

Reply | Threaded
Open this post in threaded view
|

Re: config(8) elf handling

Jonathan Gray-11
On Wed, Sep 13, 2017 at 08:44:24AM +0000, Miod Vallat wrote:

>
> > Forcing uextraloc into .data via
> > int uextraloc __attribute__ ((section(".data"))) = 0;
> > avoids the crashes.
>
> Regardless of this bug, the in-tree gcc was modified to default to put
> explicitly zero initialized data in .data rather than .bss, i.e. default
> to -fno-zero-initialized-in-bss.
>
> It might be wise to make the default configuration of clang follow this
> behaviour as well.
>

Yes, that seems reasonable.

Index: gnu/llvm/tools/clang/lib/Driver/Tools.cpp
===================================================================
RCS file: /cvs/src/gnu/llvm/tools/clang/lib/Driver/Tools.cpp,v
retrieving revision 1.14
diff -u -p -r1.14 Tools.cpp
--- gnu/llvm/tools/clang/lib/Driver/Tools.cpp 28 Jul 2017 15:31:54 -0000 1.14
+++ gnu/llvm/tools/clang/lib/Driver/Tools.cpp 13 Sep 2017 09:51:50 -0000
@@ -4463,8 +4463,13 @@ void Clang::ConstructJob(Compilation &C,
 
   if (shouldUseFramePointer(Args, getToolChain().getTriple()))
     CmdArgs.push_back("-mdisable-fp-elim");
+
+  bool ZeroInitializedInBSSDefault = true;
+  if (getToolChain().getTriple().isOSOpenBSD())
+    ZeroInitializedInBSSDefault = false;
   if (!Args.hasFlag(options::OPT_fzero_initialized_in_bss,
-                    options::OPT_fno_zero_initialized_in_bss))
+                    options::OPT_fno_zero_initialized_in_bss,
+                    ZeroInitializedInBSSDefault))
     CmdArgs.push_back("-mno-zero-initialized-in-bss");
 
   bool OFastEnabled = isOptimizationLevelFast(Args);
Index: share/man/man1/clang-local.1
===================================================================
RCS file: /cvs/src/share/man/man1/clang-local.1,v
retrieving revision 1.9
diff -u -p -r1.9 clang-local.1
--- share/man/man1/clang-local.1 29 Jul 2017 21:01:13 -0000 1.9
+++ share/man/man1/clang-local.1 13 Sep 2017 09:57:14 -0000
@@ -95,6 +95,14 @@ and
 .Xr free 3
 builtins are disabled to prevent undesriable optimizations of calls to
 these functions.
+.It
+.Nm clang
+will not move variables initialized with the value zero from the data section
+to the bss section.
+The default behaviour of
+.Nm clang
+on other systems is to perform this action, which can be restored with
+.Fl fzero-initialized-in-bss .
 .El
 .Sh SEE ALSO
 .Xr clang 1

Reply | Threaded
Open this post in threaded view
|

Re: config(8) elf handling

Philip Guenther
In reply to this post by Miod Vallat
On Wed, 13 Sep 2017, Miod Vallat wrote:

>
> > Forcing uextraloc into .data via
> > int uextraloc __attribute__ ((section(".data"))) = 0;
> > avoids the crashes.
>
> Regardless of this bug, the in-tree gcc was modified to default to put
> explicitly zero initialized data in .data rather than .bss, i.e. default
> to -fno-zero-initialized-in-bss.
>
> It might be wise to make the default configuration of clang follow this
> behaviour as well.

Anyone recall the issues that it was originally changed to fix?

If it was the kernel config stuff, maybe we should just pass the option
explicitly in the kernel Makefiles and not push it on all of userland.


Philip Guenther

Reply | Threaded
Open this post in threaded view
|

Re: config(8) elf handling

Theo de Raadt-2
> On Wed, 13 Sep 2017, Miod Vallat wrote:
> >
> > > Forcing uextraloc into .data via
> > > int uextraloc __attribute__ ((section(".data"))) = 0;
> > > avoids the crashes.
> >
> > Regardless of this bug, the in-tree gcc was modified to default to put
> > explicitly zero initialized data in .data rather than .bss, i.e. default
> > to -fno-zero-initialized-in-bss.
> >
> > It might be wise to make the default configuration of clang follow this
> > behaviour as well.
>
> Anyone recall the issues that it was originally changed to fix?
>
> If it was the kernel config stuff, maybe we should just pass the option
> explicitly in the kernel Makefiles and not push it on all of userland.

I also don't like it much, because it changes the underlying ABI in such
a subtle way.

How about initializing the variable to some 'illegal' value,
recognizing that value when using it, and resetting it to 0 before
use.  Then it doesn't need to rely some crazy ABI tweak.

Reply | Threaded
Open this post in threaded view
|

Re: config(8) elf handling

Miod Vallat
In reply to this post by Philip Guenther
> Anyone recall the issues that it was originally changed to fix?

It broke the passing of information between the boot blocks and the
kernel on x86, because locore would zero bss after the boot blocks
information variables had been written to.

Reply | Threaded
Open this post in threaded view
|

Re: config(8) elf handling

Theo de Raadt-2
> > Anyone recall the issues that it was originally changed to fix?
>
> It broke the passing of information between the boot blocks and the
> kernel on x86, because locore would zero bss after the boot blocks
> information variables had been written to.

Yeah.. but that can be blamed on a terrible argument passing method.

Reply | Threaded
Open this post in threaded view
|

Re: config(8) elf handling

Jonathan Gray-11
In reply to this post by Theo de Raadt-2
On Wed, Sep 13, 2017 at 10:23:46AM -0600, Theo de Raadt wrote:

> > On Wed, 13 Sep 2017, Miod Vallat wrote:
> > >
> > > > Forcing uextraloc into .data via
> > > > int uextraloc __attribute__ ((section(".data"))) = 0;
> > > > avoids the crashes.
> > >
> > > Regardless of this bug, the in-tree gcc was modified to default to put
> > > explicitly zero initialized data in .data rather than .bss, i.e. default
> > > to -fno-zero-initialized-in-bss.
> > >
> > > It might be wise to make the default configuration of clang follow this
> > > behaviour as well.
> >
> > Anyone recall the issues that it was originally changed to fix?
> >
> > If it was the kernel config stuff, maybe we should just pass the option
> > explicitly in the kernel Makefiles and not push it on all of userland.
>
> I also don't like it much, because it changes the underlying ABI in such
> a subtle way.
>
> How about initializing the variable to some 'illegal' value,
> recognizing that value when using it, and resetting it to 0 before
> use.  Then it doesn't need to rely some crazy ABI tweak.
>

If the attribute to force it into .data isn't wanted the alternative
gets messy as config has a bunch of bogus types and casts and treats the
int values as longs.

Index: mkioconf.c
===================================================================
RCS file: /cvs/src/usr.sbin/config/mkioconf.c,v
retrieving revision 1.36
diff -u -p -r1.36 mkioconf.c
--- mkioconf.c 27 Oct 2016 14:33:30 -0000 1.36
+++ mkioconf.c 14 Sep 2017 02:11:17 -0000
@@ -183,7 +183,7 @@ static long loc[%d] = {", locators.used)
 #endif\n\
 long extraloc[MAXEXTRALOC] = { -1 };\n\
 int nextraloc = MAXEXTRALOC;\n\
-int uextraloc = 0;\n") < 0);
+int uextraloc = -1;\n") < 0);
 }
 
 static int nlocnames, maxlocnames = 8;
Index: ukcutil.c
===================================================================
RCS file: /cvs/src/usr.sbin/config/ukcutil.c,v
retrieving revision 1.22
diff -u -p -r1.22 ukcutil.c
--- ukcutil.c 27 Oct 2016 14:32:10 -0000 1.22
+++ ukcutil.c 14 Sep 2017 02:22:33 -0000
@@ -419,6 +419,14 @@ change(int devno)
 
  j = (long *)adjust((caddr_t)nl[I_NEXTRALOC].n_value);
  k = (long *)adjust((caddr_t)nl[I_UEXTRALOC].n_value);
+
+ /*
+ * uextraloc is initialised to -1 not 0 so it will be
+ * put in .data instead of .bss so config can modify it
+ */
+ if (*(int *)k == -1)
+ *k = 0;
+
  if ((i + *k) > *j) {
  printf("Not enough space to change device.\n");
  return;
@@ -521,6 +529,14 @@ change_history(int devno, char *str)
 
  j = (long *)adjust((caddr_t)nl[I_NEXTRALOC].n_value);
  k = (long *)adjust((caddr_t)nl[I_UEXTRALOC].n_value);
+
+ /*
+ * uextraloc is initialised to -1 not 0 so it will be
+ * put in .data instead of .bss so config can modify it
+ */
+ if (*(int *)k == -1)
+ *k = 0;
+
  if ((i + *k) > *j) {
  printf("Not enough space to change device.\n");
  return;

Reply | Threaded
Open this post in threaded view
|

Re: config(8) elf handling

Theo de Raadt-2
> If the attribute to force it into .data isn't wanted the alternative
> gets messy as config has a bunch of bogus types and casts and treats the
> int values as longs.

Well, I believe that messiness is a result of trying to avoid the
consequences of the ABI.  I feel the ABI shouldn't be exposed here
and changing the compilers is wrong...

The -1 handling could be pushed to the very top.  At the very first
moment anything in ukc runs, set it to 0.  No conditional logic later on.


> Index: mkioconf.c
> ===================================================================
> RCS file: /cvs/src/usr.sbin/config/mkioconf.c,v
> retrieving revision 1.36
> diff -u -p -r1.36 mkioconf.c
> --- mkioconf.c 27 Oct 2016 14:33:30 -0000 1.36
> +++ mkioconf.c 14 Sep 2017 02:11:17 -0000
> @@ -183,7 +183,7 @@ static long loc[%d] = {", locators.used)
>  #endif\n\
>  long extraloc[MAXEXTRALOC] = { -1 };\n\
>  int nextraloc = MAXEXTRALOC;\n\
> -int uextraloc = 0;\n") < 0);
> +int uextraloc = -1;\n") < 0);
>  }
>  
>  static int nlocnames, maxlocnames = 8;
> Index: ukcutil.c
> ===================================================================
> RCS file: /cvs/src/usr.sbin/config/ukcutil.c,v
> retrieving revision 1.22
> diff -u -p -r1.22 ukcutil.c
> --- ukcutil.c 27 Oct 2016 14:32:10 -0000 1.22
> +++ ukcutil.c 14 Sep 2017 02:22:33 -0000
> @@ -419,6 +419,14 @@ change(int devno)
>  
>   j = (long *)adjust((caddr_t)nl[I_NEXTRALOC].n_value);
>   k = (long *)adjust((caddr_t)nl[I_UEXTRALOC].n_value);
> +
> + /*
> + * uextraloc is initialised to -1 not 0 so it will be
> + * put in .data instead of .bss so config can modify it
> + */
> + if (*(int *)k == -1)
> + *k = 0;
> +
>   if ((i + *k) > *j) {
>   printf("Not enough space to change device.\n");
>   return;
> @@ -521,6 +529,14 @@ change_history(int devno, char *str)
>  
>   j = (long *)adjust((caddr_t)nl[I_NEXTRALOC].n_value);
>   k = (long *)adjust((caddr_t)nl[I_UEXTRALOC].n_value);
> +
> + /*
> + * uextraloc is initialised to -1 not 0 so it will be
> + * put in .data instead of .bss so config can modify it
> + */
> + if (*(int *)k == -1)
> + *k = 0;
> +
>   if ((i + *k) > *j) {
>   printf("Not enough space to change device.\n");
>   return;

Reply | Threaded
Open this post in threaded view
|

Re: config(8) elf handling

Ted Unangst-6
In reply to this post by Philip Guenther
Philip Guenther wrote:

> On Wed, 13 Sep 2017, Miod Vallat wrote:
> >
> > > Forcing uextraloc into .data via
> > > int uextraloc __attribute__ ((section(".data"))) = 0;
> > > avoids the crashes.
> >
> > Regardless of this bug, the in-tree gcc was modified to default to put
> > explicitly zero initialized data in .data rather than .bss, i.e. default
> > to -fno-zero-initialized-in-bss.
> >
> > It might be wise to make the default configuration of clang follow this
> > behaviour as well.
>
> Anyone recall the issues that it was originally changed to fix?
>
> If it was the kernel config stuff, maybe we should just pass the option
> explicitly in the kernel Makefiles and not push it on all of userland.

oh, hi, that was me! yes, it was for kernel config specifically, and binary
hacking in general. the old ABI, from vaxen of yore, would leave things in
data, so that's where we wanted them to remain. but time moves on i guess.

Reply | Threaded
Open this post in threaded view
|

Re: config(8) elf handling

Jonathan Gray-11
In reply to this post by Theo de Raadt-2
On Wed, Sep 13, 2017 at 08:34:56PM -0600, Theo de Raadt wrote:

> > If the attribute to force it into .data isn't wanted the alternative
> > gets messy as config has a bunch of bogus types and casts and treats the
> > int values as longs.
>
> Well, I believe that messiness is a result of trying to avoid the
> consequences of the ABI.  I feel the ABI shouldn't be exposed here
> and changing the compilers is wrong...
>
> The -1 handling could be pushed to the very top.  At the very first
> moment anything in ukc runs, set it to 0.  No conditional logic later on.

Index: mkioconf.c
===================================================================
RCS file: /cvs/src/usr.sbin/config/mkioconf.c,v
retrieving revision 1.36
diff -u -p -U4 -r1.36 mkioconf.c
--- mkioconf.c 27 Oct 2016 14:33:30 -0000 1.36
+++ mkioconf.c 14 Sep 2017 02:11:17 -0000
@@ -182,9 +182,9 @@ static long loc[%d] = {", locators.used)
 #define MAXEXTRALOC 32\n\
 #endif\n\
 long extraloc[MAXEXTRALOC] = { -1 };\n\
 int nextraloc = MAXEXTRALOC;\n\
-int uextraloc = 0;\n") < 0);
+int uextraloc = -1;\n") < 0);
 }
 
 static int nlocnames, maxlocnames = 8;
 static char **locnames;
Index: ukc.c
===================================================================
RCS file: /cvs/src/usr.sbin/config/ukc.c,v
retrieving revision 1.22
diff -u -p -U4 -r1.22 ukc.c
--- ukc.c 19 Oct 2016 16:39:02 -0000 1.22
+++ ukc.c 14 Sep 2017 03:14:43 -0000
@@ -61,8 +61,9 @@ ukc(char *file, char *outfile, int uflag
  kvm_t *kd;
  char errbuf[_POSIX2_LINE_MAX];
  int histlen = 0, ok = 1;
  char history[1024], kversion[1024];
+ int *uextraloc;
 
  if (file == NULL) {
  warnx("no file specified");
  usage();
@@ -71,8 +72,18 @@ ukc(char *file, char *outfile, int uflag
  loadkernel(file);
 
  if (nlist(file, nl) == -1)
  errx(1, "nlist: %s", file);
+
+ /*
+ * uextraloc is initialised to -1 not 0 so it will be put in .data
+ * instead of .bss so config can modify it
+ */
+ if (nl[I_UEXTRALOC].n_type != 0) {
+ uextraloc = (int *)adjust((caddr_t)nl[I_UEXTRALOC].n_value);
+ if (*uextraloc == -1)
+ *uextraloc = 0;
+ }
 
  if (uflag) {
  if ((kd = kvm_openfiles(NULL,NULL,NULL,O_RDONLY, errbuf)) == 0)
  errx(1, "kvm_openfiles: %s", errbuf);

Reply | Threaded
Open this post in threaded view
|

Re: config(8) elf handling

YASUOKA Masahiko-3
In reply to this post by Jonathan Gray-11
Hi,

On Wed, 13 Sep 2017 14:52:59 +1000
Jonathan Gray <[hidden email]> wrote:
> config(8) creates ioconf.c containing

"timezone" command of config(8) is also broken.

 % config -e bsd.mp
 WARNING no output file specified
 WARNING this kernel doesn't contain all information needed!
 WARNING the commands add and change might not work.
 OpenBSD 6.2 (GENERIC.MP) #128: Mon Oct  2 23:18:13 MDT 2017
     [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 Enter 'help' for information
 ukc> t
 timezone = 95510072, dst = 48017180
 ukc>

timezone and dst must be 0.  On my test, kernel panics when timezone
is altered by the config command.

The diff following fixes the problem.

Index: sys/conf/param.c
===================================================================
RCS file: /cvs/src/sys/conf/param.c,v
retrieving revision 1.37
diff -u -p -r1.37 param.c
--- sys/conf/param.c 6 May 2016 19:45:35 -0000 1.37
+++ sys/conf/param.c 3 Oct 2017 09:01:26 -0000
@@ -81,7 +81,7 @@
 int hz = HZ;
 int tick = 1000000 / HZ;
 int tickadj = 240000 / (60 * HZ); /* can adjust 240ms in 60s */
-struct timezone tz = { TIMEZONE, DST };
+struct timezone tz  __attribute__ ((section(".data"))) = { TIMEZONE, DST };
 #define NPROCESS (30 + 16 * MAXUSERS)
 #define NTEXT (80 + NPROCESS / 8) /* actually the object cache */
 #define NVNODE (NPROCESS * 2 + NTEXT + 100)