linux-kernel - Re: + espfix-code-cleanup.patch added to -mm tree

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <200608021515_MC3-1-C6D7-2B90@compuserve.com>
Date:	Wed, 2 Aug 2006 15:14:08 -0400
From:	Chuck Ebbert <76306.1226@...puserve.com>
To:	Stas Sergeev <stsp@...et.ru>
Cc:	Zachary Amsden <zach@...are.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: + espfix-code-cleanup.patch added to -mm tree

In-Reply-To: <44D0DCF5.8050906@...et.ru>

On Wed, 02 Aug 2006 21:12:21 +0400, Stas Sergeev wrote:
> 
> > iret faults, but doesn't pop the user return frame.
> But does it push the kernel frame after it or not?
> If not - I don't understand how we go to a fixup.
> If yes - I don't understand how the user's frame gets
> accessed later, as it is above the kernel's frame.

Just before trying to return to userspace, we have a stack:

        user_regs [ebx ... es]
        orig_eax
        user_iret_frame [eip ... oldss]

After RESTORE_ALL and discarding orig_eax, we have this just
before doing iret (user's regs are in the CPU regs now):

        user_iret_frame [eip ... oldss]

iret faults and we get:

        kernel_iret_frame [eip(of iret) ... flags]
        user_iret_frame [eip ... oldss]

error_code then saves regs and we have:

        user_regs [ebx ... es]
        orig_eax [== -1]
        kernel_iret_frame [eip(iret) ... flags]
        user_iret_frame [eip ... oldss]

error_code then calls e.g. do_segment_not_present, which finds a fixup
and does:

        regs->eip = fixup_address;

now we have:

        user_regs [ebx ... es]
        orig_eax [== -1]
        kernel_iret_frame [eip(fixup) ... flags]
        user_iret_frame [eip ... oldss]

standard return sequence gives us (again user's regs are back in CPU):

        kernel_iret_frame [eip(fixup) ... flags]
        user_iret_frame [eip ... oldss]

iret returns to the fixup code which jumps to error_code and then we have:

        user_regs [ebx ... es]
        orig_eax [== -1]
        user_iret_frame [eip ... oldss]

So now there is a stack frame that looks like it came from userspace
and we call the iret fault handler with that.

Only problem I have with this is we lose the original fault info from
the iret.  So we have no real way of knowing whether it was #GP, #NP, #SF
or whatever, and no record of the offending iret's address.

-- 
Chuck

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/