Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1576399
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [kernel-hardening] Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION |
| Date | 2017-02-08 10:50 +0100 |
| Message-ID | <t8x2X-74c-31@gated-at.bofh.it> (permalink) |
| References | (5 earlier) <t8fz4-4vL-17@gated-at.bofh.it> <t8gv8-56A-1@gated-at.bofh.it> <t8hUd-5Qz-9@gated-at.bofh.it> <t8idA-5XI-25@gated-at.bofh.it> <t8wzT-6Sa-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Wed, Feb 08, 2017 at 10:12:50AM +0100, Peter Zijlstra wrote:
> Something like:
>
> #define EX_REG_HANDLER(_reg) \
> bool ex_handler_value_##_reg(const struct exception_table_entry *fixup, \
> struct pt_regs *regs, int trapnr) \
> { \
> void (*handler)(unsigned long) = \
> (void *)((unsigned long)&fixup->to + fixup->to); \
> \
> if (trapnr != X86_TRAP_UD) \
> return false; \
> \
> regs->ip += 2; /* size of UD2 instruction */ \
> handler(regs->_reg); \
> return true; \
> }
>
> EX_REG_HANDLER(bx);
> EX_REG_HANDLER(cx);
> ...
> EX_REG_HANDLER(ss);
>
>
> asm (
> " .macro reg_to_handler r\n"
> " .irp rs,bx,cx,...,ss\n"
> " .ifc \\r, %\\rs\n"
> " ex_handler_value_\\rs\n"
> " .endif\n"
" .ifc \\r, %e\\rs\n"
" ex_handler_value_\\rs\n"
" .endif\n"
" .ifc \\r, %r\\rs\n"
" ex_handler_value_\\rs\n"
" .endif\n"
> " .endr\n"
> " .endm\n"
> );
to match the 16, 32 and 64 bit names of the same registers. The byte
registers will need additional magic :/
> #define EXCEPTION_VALUE(val, handler) \
> asm volatile ("1: ud2" \
> _ASM_EXTABLE_HANDLE(1b, handler, \
> reg_to_handler %0) \
> : : "r" (val))
>
>
> Where the generic version can simply be:
>
> #define EXCEPTION_VALUE(val, handler) handler((unsigned long)val)
>
>
> Makes sense?
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 0/4] refcount_t followups... Kees Cook <keescook@chromium.org> - 2017-02-04 00:30 +0100
[PATCH 2/4] lkdtm: convert to refcount_t testing Kees Cook <keescook@chromium.org> - 2017-02-04 00:30 +0100
[tip:locking/core] lkdtm: Convert to refcount_t testing tip-bot for Kees Cook <tipbot@zytor.com> - 2017-02-10 09:50 +0100
[PATCH 3/4] bug: Switch data corruption check to __must_check Kees Cook <keescook@chromium.org> - 2017-02-04 00:30 +0100
[PATCH 1/4] refcount_t: fix Kconfig help Kees Cook <keescook@chromium.org> - 2017-02-04 00:30 +0100
[PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Kees Cook <keescook@chromium.org> - 2017-02-04 00:30 +0100
Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Peter Zijlstra <peterz@infradead.org> - 2017-02-05 16:50 +0100
Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Kees Cook <keescook@chromium.org> - 2017-02-06 00:40 +0100
Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Peter Zijlstra <peterz@infradead.org> - 2017-02-06 10:00 +0100
Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Kees Cook <keescook@chromium.org> - 2017-02-06 18:00 +0100
Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Peter Zijlstra <peterz@infradead.org> - 2017-02-07 09:40 +0100
Re: [kernel-hardening] Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Mark Rutland <mark.rutland@arm.com> - 2017-02-07 12:20 +0100
Re: [kernel-hardening] Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Peter Zijlstra <peterz@infradead.org> - 2017-02-07 13:40 +0100
Re: [kernel-hardening] Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Mark Rutland <mark.rutland@arm.com> - 2017-02-07 15:00 +0100
Re: [kernel-hardening] Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Peter Zijlstra <peterz@infradead.org> - 2017-02-07 16:10 +0100
Re: [kernel-hardening] Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Mark Rutland <mark.rutland@arm.com> - 2017-02-07 17:10 +0100
Re: [kernel-hardening] Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Peter Zijlstra <peterz@infradead.org> - 2017-02-07 18:40 +0100
Re: [kernel-hardening] Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Mark Rutland <mark.rutland@arm.com> - 2017-02-07 19:00 +0100
Re: [kernel-hardening] Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Peter Zijlstra <peterz@infradead.org> - 2017-02-08 10:20 +0100
Re: [kernel-hardening] Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Peter Zijlstra <peterz@infradead.org> - 2017-02-08 10:50 +0100
Re: [kernel-hardening] Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Mark Rutland <mark.rutland@arm.com> - 2017-02-08 16:00 +0100
Re: [kernel-hardening] Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Kees Cook <keescook@chromium.org> - 2017-02-08 22:30 +0100
Re: [kernel-hardening] Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Peter Zijlstra <peterz@infradead.org> - 2017-02-09 11:30 +0100
Re: [kernel-hardening] Re: [PATCH 4/4] refcount: Report failures through CHECK_DATA_CORRUPTION Kees Cook <keescook@chromium.org> - 2017-02-11 00:40 +0100
csiph-web