lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Fri, 31 Aug 2018 00:30:45 +0800
From:   kbuild test robot <lkp@...el.com>
To:     Jann Horn <jannh@...gle.com>
Cc:     kbuild-all@...org, linux-kernel@...r.kernel.org,
        tipbuild@...or.com, Thomas Gleixner <tglx@...utronix.de>,
        Kees Cook <keescook@...omium.org>, Borislav Petkov <bp@...e.de>
Subject: [tip:x86/urgent 9/11] arch/x86/kernel/dumpstack.c:107:17: sparse:
 incorrect type in argument 1 (different address spaces)

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent
head:   16f54a362e4083218ac8d67a4879532c6eef2d98
commit: a644cf538b1125410421584c68b2013fdbecbd79 [9/11] x86/dumpstack: Don't dump kernel memory based on usermode RIP
reproduce:
        # apt-get install sparse
        git checkout a644cf538b1125410421584c68b2013fdbecbd79
        make ARCH=x86_64 allmodconfig
        make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> arch/x86/kernel/dumpstack.c:107:17: sparse: incorrect type in argument 1 (different address spaces) @@    expected void const volatile [noderef] <asn:1>*<noident> @@    got olatile [noderef] <asn:1>*<noident> @@
   arch/x86/kernel/dumpstack.c:107:17:    expected void const volatile [noderef] <asn:1>*<noident>
   arch/x86/kernel/dumpstack.c:107:17:    got unsigned char [usertype] *prologue

vim +107 arch/x86/kernel/dumpstack.c

    73	
    74	/*
    75	 * There are a couple of reasons for the 2/3rd prologue, courtesy of Linus:
    76	 *
    77	 * In case where we don't have the exact kernel image (which, if we did, we can
    78	 * simply disassemble and navigate to the RIP), the purpose of the bigger
    79	 * prologue is to have more context and to be able to correlate the code from
    80	 * the different toolchains better.
    81	 *
    82	 * In addition, it helps in recreating the register allocation of the failing
    83	 * kernel and thus make sense of the register dump.
    84	 *
    85	 * What is more, the additional complication of a variable length insn arch like
    86	 * x86 warrants having longer byte sequence before rIP so that the disassembler
    87	 * can "sync" up properly and find instruction boundaries when decoding the
    88	 * opcode bytes.
    89	 *
    90	 * Thus, the 2/3rds prologue and 64 byte OPCODE_BUFSIZE is just a random
    91	 * guesstimate in attempt to achieve all of the above.
    92	 */
    93	void show_opcodes(struct pt_regs *regs, const char *loglvl)
    94	{
    95	#define PROLOGUE_SIZE 42
    96	#define EPILOGUE_SIZE 21
    97	#define OPCODE_BUFSIZE (PROLOGUE_SIZE + 1 + EPILOGUE_SIZE)
    98		u8 opcodes[OPCODE_BUFSIZE];
    99		u8 *prologue = (u8 *)(regs->ip - PROLOGUE_SIZE);
   100		bool bad_ip;
   101	
   102		/*
   103		 * Make sure userspace isn't trying to trick us into dumping kernel
   104		 * memory by pointing the userspace instruction pointer at it.
   105		 */
   106		bad_ip = user_mode(regs) &&
 > 107			__range_not_ok(prologue, OPCODE_BUFSIZE, TASK_SIZE_MAX);
   108	
   109		if (bad_ip || probe_kernel_read(opcodes, prologue, OPCODE_BUFSIZE)) {
   110			printk("%sCode: Bad RIP value.\n", loglvl);
   111		} else {
   112			printk("%sCode: %" __stringify(PROLOGUE_SIZE) "ph <%02x> %"
   113			       __stringify(EPILOGUE_SIZE) "ph\n", loglvl, opcodes,
   114			       opcodes[PROLOGUE_SIZE], opcodes + PROLOGUE_SIZE + 1);
   115		}
   116	}
   117	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

Powered by blists - more mailing lists