)]}'
{
  "log": [
    {
      "commit": "d67b569f5f620c0fb95d5212642746b7ba9d29e4",
      "tree": "c7ef10c906dd83911e10988c6cea6d7d5644e072",
      "parents": [
        "1322ad41513f8f9196801f53cc0851df056f3478"
      ],
      "author": {
        "name": "Jeff Dike",
        "email": "jdike@addtoit.com",
        "time": "Thu Jul 07 17:56:49 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Thu Jul 07 18:23:44 2005 -0700"
      },
      "message": "[PATCH] uml: skas0 - separate kernel address space on stock hosts\n\nUML has had two modes of operation - an insecure, slow mode (tt mode) in\nwhich the kernel is mapped into every process address space which requires\nno host kernel modifications, and a secure, faster mode (skas mode) in\nwhich the UML kernel is in a separate host address space, which requires a\npatch to the host kernel.\n\nThis patch implements something very close to skas mode for hosts which\ndon\u0027t support skas - I\u0027m calling this skas0.  It provides the security of\nthe skas host patch, and some of the performance gains.\n\nThe two main things that are provided by the skas patch, /proc/mm and\nPTRACE_FAULTINFO, are implemented in a way that require no host patch.\n\nFor the remote address space changing stuff (mmap, munmap, and mprotect),\nwe set aside two pages in the process above its stack, one of which\ncontains a little bit of code which can call mmap et al.\n\nTo update the address space, the system call information (system call\nnumber and arguments) are written to the stub page above the code.  The\n%esp is set to the beginning of the data, the %eip is set the the start of\nthe stub, and it repeatedly pops the information into its registers and\nmakes the system call until it sees a system call number of zero.  This is\nto amortize the cost of the context switch across multiple address space\nupdates.\n\nWhen the updates are done, it SIGSTOPs itself, and the kernel process\ncontinues what it was doing.\n\nFor a PTRACE_FAULTINFO replacement, we set up a SIGSEGV handler in the\nchild, and let it handle segfaults rather than nullifying them.  The\nhandler is in the same page as the mmap stub.  The second page is used as\nthe stack.  The handler reads cr2 and err from the sigcontext, sticks them\nat the base of the stack in a faultinfo struct, and SIGSTOPs itself.  The\nkernel then reads the faultinfo and handles the fault.\n\nA complication on x86_64 is that this involves resetting the registers to\nthe segfault values when the process is inside the kill system call.  This\nbreaks on x86_64 because %rcx will contain %rip because you tell SYSRET\nwhere to return to by putting the value in %rcx.  So, this corrupts $rcx on\nreturn from the segfault.  To work around this, I added an\narch_finish_segv, which on x86 does nothing, but which on x86_64 ptraces\nthe child back through the sigreturn.  This causes %rcx to be restored by\nsigreturn and avoids the corruption.  Ultimately, I think I will replace\nthis with the trick of having it send itself a blocked signal which will be\nunblocked by the sigreturn.  This will allow it to be stopped just after\nthe sigreturn, and PTRACE_SYSCALLed without all the back-and-forth of\nPTRACE_SYSCALLing it through sigreturn.\n\nThis runs on a stock host, so theoretically (and hopefully), tt mode isn\u0027t\nneeded any more.  We need to make sure that this is better in every way\nthan tt mode, though.  I\u0027m concerned about the speed of address space\nupdates and page fault handling, since they involve extra round-trips to\nthe child.  We can amortize the round-trip cost for large address space\nupdates by writing all of the operations to the data page and having the\nchild execute them all at the same time.  This will help fork and exec, but\nnot page faults, since they involve only one page.\n\nI can\u0027t think of any way to help page faults, except to add something like\nPTRACE_FAULTINFO to the host.  There is PTRACE_SIGINFO, but UML doesn\u0027t use\nsiginfo for SIGSEGV (or anything else) because there isn\u0027t enough\ninformation in the siginfo struct to handle page faults (the faulting\noperation type is missing).  Adding that would make PTRACE_SIGINFO a usable\nequivalent to PTRACE_FAULTINFO.\n\nAs for the code itself:\n\n- The system call stub is in arch/um/kernel/sys-$(SUBARCH)/stub.S.  It is\n  put in its own section of the binary along with stub_segv_handler in\n  arch/um/kernel/skas/process.c.  This is manipulated with run_syscall_stub\n  in arch/um/kernel/skas/mem_user.c.  syscall_stub will execute any system\n  call at all, but it\u0027s only used for mmap, munmap, and mprotect.\n\n- The x86_64 stub calls sigreturn by hand rather than allowing the normal\n  sigreturn to happen, because the normal sigreturn is a SA_RESTORER in\n  UML\u0027s address space provided by libc.  Needless to say, this is not\n  available in the child\u0027s address space.  Also, it does a couple of odd\n  pops before that which restore the stack to the state it was in at the\n  time the signal handler was called.\n\n- There is a new field in the arch mmu_context, which is now a union.\n  This is the pid to be manipulated rather than the /proc/mm file\n  descriptor.  Code which deals with this now checks proc_mm to see whether\n  it should use the usual skas code or the new code.\n\n- userspace_tramp is now used to create a new host process for every UML\n  process, rather than one per UML processor.  It checks proc_mm and\n  ptrace_faultinfo to decide whether to map in the pages above its stack.\n\n- start_userspace now makes CLONE_VM conditional on proc_mm since we need\n  separate address spaces now.\n\n- switch_mm_skas now just sets userspace_pid[0] to the new pid rather\n  than PTRACE_SWITCH_MM.  There is an addition to userspace which updates\n  its idea of the pid being manipulated each time around the loop.  This is\n  important on exec, when the pid will change underneath userspace().\n\n- The stub page has a pte, but it can\u0027t be mapped in using tlb_flush\n  because it is part of tlb_flush.  This is why it\u0027s required for it to be\n  mapped in by userspace_tramp.\n\nOther random things:\n\n- The stub section in uml.lds.S is page aligned.  This page is written\n  out to the backing vm file in setup_physmem because it is mapped from\n  there into user processes.\n\n- There\u0027s some confusion with TASK_SIZE now that there are a couple of\n  extra pages that the process can\u0027t use.  TASK_SIZE is considered by the\n  elf code to be the usable process memory, which is reasonable, so it is\n  decreased by two pages.  This confuses the definition of\n  USER_PGDS_IN_LAST_PML4, making it too small because of the rounding down\n  of the uneven division.  So we round it to the nearest PGDIR_SIZE rather\n  than the lower one.\n\n- I added a missing PT_SYSCALL_ARG6_OFFSET macro.\n\n- um_mmu.h was made into a userspace-usable file.\n\n- proc_mm and ptrace_faultinfo are globals which say whether the host\n  supports these features.\n\n- There is a bad interaction between the mm.nr_ptes check at the end of\n  exit_mmap, stack randomization, and skas0.  exit_mmap will stop freeing\n  pages at the PGDIR_SIZE boundary after the last vma.  If the stack isn\u0027t\n  on the last page table page, the last pte page won\u0027t be freed, as it\n  should be since the stub ptes are there, and exit_mmap will BUG because\n  there is an unfreed page.  To get around this, TASK_SIZE is set to the\n  next lowest PGDIR_SIZE boundary and mm-\u003enr_ptes is decremented after the\n  calls to init_stub_pte.  This ensures that we know the process stack (and\n  all other process mappings) will be below the top page table page, and\n  thus we know that mm-\u003enr_ptes will be one too many, and can be\n  decremented.\n\nThings that need fixing:\n\n- We may need better assurrences that the stub code is PIC.\n\n- The stub pte is set up in init_new_context_skas.\n\n- alloc_pgdir is probably the right place.\n\nSigned-off-by: Jeff Dike \u003cjdike@addtoit.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "c45166be3cc666ce88fe623ad79276c943e74eff",
      "tree": "db59fdfb6834c112c99a5ab8692fe8372d7961ba",
      "parents": [
        "b05d85a87d9711f5f5f2eb05c79038d5d5ff1f44"
      ],
      "author": {
        "name": "Paolo \u0027Blaisorblade\u0027 Giarrusso",
        "email": "blaisorblade@yahoo.it",
        "time": "Sun May 01 08:58:54 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sun May 01 08:58:54 2005 -0700"
      },
      "message": "[PATCH] uml: support AES i586 crypto driver\n\nWe want to make possible, for the user, to enable the i586 AES implementation.\nThis requires a restructure.\n\n- Add a CONFIG_UML_X86 to notify that we are building a UML for i386.\n\n- Rename CONFIG_64_BIT to CONFIG_64BIT as is used for all other archs\n\n- Tell crypto/Kconfig that UML_X86 is as good as X86\n\n- Tell it that it must exclude not X86_64 but 64BIT, which will give the\n  same results.\n\n- Tell kbuild to descend down into arch/i386/crypto/ to build what\u0027s needed.\n\nSigned-off-by: Paolo \u0027Blaisorblade\u0027 Giarrusso \u003cblaisorblade@yahoo.it\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
      "tree": "0bba044c4ce775e45a88a51686b5d9f90697ea9d",
      "parents": [],
      "author": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sat Apr 16 15:20:36 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sat Apr 16 15:20:36 2005 -0700"
      },
      "message": "Linux-2.6.12-rc2\n\nInitial git repository build. I\u0027m not bothering with the full history,\neven though we have it. We can create a separate \"historical\" git\narchive of that later if we want to, and in the meantime it\u0027s about\n3.2GB when imported into git - space that would just make the early\ngit days unnecessarily complicated, when we don\u0027t have a lot of good\ninfrastructure for it.\n\nLet it rip!\n"
    }
  ]
}