[<prev] [next>] [day] [month] [year] [list]
Message-ID: <201808310034.DEhufz3F%fengguang.wu@intel.com>
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