linux-kernel - Re: [PATCH 06/11] x86-64: Fix %cs value in convert_from

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-prev] [day] [month] [year] [list]

Date:	Mon, 30 Aug 2010 07:38:51 -0400
From:	Brian Gerst <brgerst@...il.com>
To:	Pekka Enberg <penberg@...nel.org>
Cc:	hpa@...or.com, x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 06/11] x86-64: Fix %cs value in convert_from_fxsr()

On Mon, Aug 30, 2010 at 2:44 AM, Pekka Enberg <penberg@...nel.org> wrote:
> On Sat, Aug 28, 2010 at 7:04 PM, Brian Gerst <brgerst@...il.com> wrote:
>>>> While %ds still contains the userspace selector, %cs is KERNEL_CS
>>>> at this point.  Always get %cs from pt_regs.
>>>>
>>>> It actually is possible to get the correct segments for compat tasks,
>>>> but that involves using the [f]xsave instruction without a REX.W prefix.
>>>>
>>>> Signed-off-by: Brian Gerst <brgerst@...il.com>
>
> On Sun, Aug 29, 2010 at 2:41 PM, Pekka Enberg <penberg@...nel.org> wrote:
>>> It might be just me but the above description doesn't explain
>>> anything. What's the problem here? What is this fixing?
>
> On Mon, Aug 30, 2010 at 3:25 AM, Brian Gerst <brgerst@...il.com> wrote:
>> The %cs segment being reported to a compat task is flat out wrong.  It
>> is getting KERNEL_CS when it should be some userspace segment.  The
>> code segment may still be wrong, because the %cs in pt_regs may not
>> have been the segment where the instruction that flagged the exception
>> executed from.  That could be fixed by using fxsave without a REX.W
>> prefix when saving the state of compat tasks, which would save the
>> segment and 32-bit offset instead of the 64-bit offset for the code
>> and data pointers.  This is such a corner case that it probably isn't
>> worth putting much effort into fixing unless someone demonstrates a
>> real need for it.
>
> I sort of was able to deduce most of that from the original
> description. However, I still don't quite understand what the problem
> causes. Just a wrong cs reported to a signal handler or something
> else?
>

The wrong cs value is reported to userspace.  I don't know of any apps
that actually cares about it, except for possibly wine or dosemu.  In
any app that doesn't use alternate segments, the above fix will be
give the correct cs every time (since it never changes).

--
Brian Gerst
--
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/