|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 03/16] x86/traps: Factor out exception_fixup() and make printing consistent
On 02.05.2020 00:58, Andrew Cooper wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -774,10 +774,27 @@ static void do_reserved_trap(struct cpu_user_regs *regs)
> trapnr, vec_name(trapnr), regs->error_code);
> }
>
> +static bool exception_fixup(struct cpu_user_regs *regs, bool print)
> +{
> + unsigned long fixup = search_exception_table(regs);
> +
> + if ( unlikely(fixup == 0) )
> + return false;
> +
> + /* Can currently be triggered by guests. Make sure we ratelimit. */
> + if ( IS_ENABLED(CONFIG_DEBUG) && print )
I didn't think we consider dprintk()-s a possible security issue.
Why would we consider so a printk() hidden behind
IS_ENABLED(CONFIG_DEBUG)? IOW I think one of XENLOG_GUEST and
IS_ENABLED(CONFIG_DEBUG) wants dropping.
> @@ -1466,12 +1468,11 @@ void do_page_fault(struct cpu_user_regs *regs)
> if ( pf_type != real_fault )
> return;
>
> - if ( likely((fixup = search_exception_table(regs)) != 0) )
> + if ( likely(exception_fixup(regs, false)) )
> {
> perfc_incr(copy_user_faults);
> if ( unlikely(regs->error_code & PFEC_reserved_bit) )
> reserved_bit_page_fault(addr, regs);
> - regs->rip = fixup;
I'm afraid this modification can't validly be pulled ahead -
show_execution_state(), as called from reserved_bit_page_fault(),
wants to / should print the original RIP, not the fixed up one.
Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |