Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

03.09.2015 01:25, Andy Lutomirski пишет:

On Wed, Sep 2, 2015 at 3:25 PM, Stas Sergeev  wrote:


How dosemu2 is supposed to do this:
1. sigreturn() (to DOS)
2. siglongjmp() (to 64bit C-coded)

This should work fine on any kernel, right?

1 - not.
2 - maybe.
If, as you say, siglongjmp() restores SS, I need to try it out.
(there is also a problem that most siglongjmp() implementations
are incompatible with sigaltstack(), but this is not what you can fix).


1 - definitely needs kernel changes.  I was referring to #2.

2 - siglongjmp probably varies in its behavior across different libc
implementations.  My point is that siglongjmp isn't a kernel-provided
thing.

So if siglongjmp() restores SS by the side-effect of doing a sigprocmask()
syscall, this admittedly weakens my point.
The unreliability then stays only with the async signals interrupting
the main one.


For backwards compat, we either need the default behavior to be
unchanged, or we need the default behavior to be something that works
with existing dosemu.  For existing dosemu, the only interesting cases
(I think) are signal delivery from *valid* 16-bit context, in which
case we need to preserve SS so that the signal handler can read it out
with mov ..., %ss, and sigreturn to 64-bit mode for the IRET
trampoline.  For sigreturn, IIUC old dosemu will replace the saved CS
with a 64-bit code segment selector and won't touch the saved SS
because it doesn't know about the saved SS.  Those dosemu versions
don't care what SS actually contains after sigreturn, because they're
immediately going to change it again using IRET.  So we just need to
make sure we return without faulting.

New dosemu2 would like to sigreturn directly back to 16-bit mode, so
it needs the kernel to honor the saved ss value and restore it,
possibly changed by dosemu.

We obviously can't require old dosemu to set an SA flag to keep
working.  But, if we can get away with it, I think it's somewhat
preferable not to require new DOSEMU to set an SA flag either.

This has one major benefit at least: if new dosemu loads some random
library that installs some async signal handler (SIGALRM for example),
everything will work with regard to CS and SS.

This case is covered if we do both things together: use
your heuristic when SA_hyz is not set, and don't use it
when its set. In this case dosemu2 will be able to request
the proper SS delivery for its sighandlers, but the 3rd-party
sighandlers will work too.
I think we have never discussed the possibility of doing
both things together, even though I have proposed it many
times.
After discussing this full-blown solution, we can think about
reducing it, either by removing the heuristic or by removing
SA_hyz, but discussing the full one would be nice too.
Your opinion is likely that no one will use this SA_hyz in
presence of the heuristic that "seems to work anyway".
But in the light of extending it for TLS (with a new flag),
I wouldn't be so sure. You can also document it as a
needed flag when user code touches SS, and then it will
be used. dosemu1 code that doesn't use it, will eventually
be forgotten. So IMHO whether it will be used, is fully up
to how will you market it. :)

I'll think about it.  I'll think about FS and GS, too,

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Wed, Sep 2, 2015 at 3:25 PM, Stas Sergeev  wrote:
> 03.09.2015 00:39, Andy Lutomirski пишет:
>
>> On Wed, Sep 2, 2015 at 2:01 PM, Stas Sergeev  wrote:
>>>
>>> 02.09.2015 22:06, Andy Lutomirski пишет:
>>>
 On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev  wrote:
>
> 02.09.2015 21:17, Andy Lutomirski пишет:
>>
>> On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev  wrote:
>>>
>>> 02.09.2015 17:21, Andy Lutomirski пишет:
>>
>> This should work for old DOSEMU.  It's a bit gross, but it has the
>> nice benefit that everyone (even things that aren't DOSEMU) gain
>> the
>> ability to catch signals thrown from bogus SS contexts, which
>> probably
>> improves debugability.  It's also nice to not have the SA flag.
>
> Pros:
> - No new SA flag
> - May improve debugability in some unknown scenario where people
> do not want to just use the new flag to get their things improved
>
> Cons:
> - Does not allow to cleanly use siglongjmp(), as then there is a
> risk
> to jump to 64bit code with bad SS

 What's the issue here?  I don't understand.

 On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so
 it
 won't be affected.  AFAIK all implementations of siglongjmp are
 likely
 to call sigprocmask or similar, and that will clobber SS.  I'm not
 aware of an implementation of siglongjmp that uses sigreturn.
>>>
>>> I am not saying siglongjmp() will be affected.
>>> Quite the opposite: it won't, which is bad. :)
>>> If you have always correct SS, you can use siglongjmp(). If you have
>>> broken SS at times, siglongjmp() will be an asking for troubles, as
>>> it exactly does not restore SS.
>>> dosemu could do a good use of siglongjmp() to get back to 64bit code
>>> from its sighandler.
>>
>> This seems like it would be relying unpleasantly heavily on libc
>> internals.
>
> Could you please clarify?
> If kernel always passes the right SS to the sighandler, then what's
> the problem?

 What's the exact siglongjmp usage you have in mind?  Signal context
 isn't normally involved AFAIK.
>>>
>>> dosemu needs 2 return pathes:
>>> 1. to DOS code
>>> 2. to 64bit code (dosemu is not all in a sighandler, right?)
>>>
>>> How it is currently achieved:
>>> dosemu1:
>>> 1. sigreturn() + iret (to DOS)
>>> 2. modify sigcontext -> sigreturn() (to 64bit asm helper)
>>>
>>> dosemu2:
>>> 1. sigreturn() + iret (to DOS)
>>> 2. modify sigcontext -> sigreturn() -> longjmp() (to 64bit C-coded)
>>
>> So you're modifying sigcontext such that it returns to a C function
>> that calls longjmp?
>
> Yes.
>
>>> How dosemu2 is supposed to do this:
>>> 1. sigreturn() (to DOS)
>>> 2. siglongjmp() (to 64bit C-coded)
>>
>> This should work fine on any kernel, right?
>
> 1 - not.
> 2 - maybe.
> If, as you say, siglongjmp() restores SS, I need to try it out.
> (there is also a problem that most siglongjmp() implementations
> are incompatible with sigaltstack(), but this is not what you can fix).
>

1 - definitely needs kernel changes.  I was referring to #2.

2 - siglongjmp probably varies in its behavior across different libc
implementations.  My point is that siglongjmp isn't a kernel-provided
thing.

>> For backwards compat, we either need the default behavior to be
>> unchanged, or we need the default behavior to be something that works
>> with existing dosemu.  For existing dosemu, the only interesting cases
>> (I think) are signal delivery from *valid* 16-bit context, in which
>> case we need to preserve SS so that the signal handler can read it out
>> with mov ..., %ss, and sigreturn to 64-bit mode for the IRET
>> trampoline.  For sigreturn, IIUC old dosemu will replace the saved CS
>> with a 64-bit code segment selector and won't touch the saved SS
>> because it doesn't know about the saved SS.  Those dosemu versions
>> don't care what SS actually contains after sigreturn, because they're
>> immediately going to change it again using IRET.  So we just need to
>> make sure we return without faulting.
>>
>> New dosemu2 would like to sigreturn directly back to 16-bit mode, so
>> it needs the kernel to honor the saved ss value and restore it,
>> possibly changed by dosemu.
>>
>> We obviously can't require old dosemu to set an SA flag to keep
>> working.  But, if we can get away with it, I think it's somewhat
>> preferable not to require new DOSEMU to set an SA flag either.
>>
>> This has one major benefit at least: if new dosemu loads some random
>> library that installs some async signal handler (SIGALRM for example),
>> everything will work with regard to CS and SS.
>
> This case is covered if we do both things together: use
> your heuristic when SA_hyz is not set, and don't use it
> when its set. In this case dosemu2 will be able to request
> the 

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

03.09.2015 00:39, Andy Lutomirski пишет:

On Wed, Sep 2, 2015 at 2:01 PM, Stas Sergeev  wrote:

02.09.2015 22:06, Andy Lutomirski пишет:


On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev  wrote:

02.09.2015 21:17, Andy Lutomirski пишет:

On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev  wrote:

02.09.2015 17:21, Andy Lutomirski пишет:

This should work for old DOSEMU.  It's a bit gross, but it has the
nice benefit that everyone (even things that aren't DOSEMU) gain the
ability to catch signals thrown from bogus SS contexts, which
probably
improves debugability.  It's also nice to not have the SA flag.

Pros:
- No new SA flag
- May improve debugability in some unknown scenario where people
do not want to just use the new flag to get their things improved

Cons:
- Does not allow to cleanly use siglongjmp(), as then there is a risk
to jump to 64bit code with bad SS

What's the issue here?  I don't understand.

On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
won't be affected.  AFAIK all implementations of siglongjmp are likely
to call sigprocmask or similar, and that will clobber SS.  I'm not
aware of an implementation of siglongjmp that uses sigreturn.

I am not saying siglongjmp() will be affected.
Quite the opposite: it won't, which is bad. :)
If you have always correct SS, you can use siglongjmp(). If you have
broken SS at times, siglongjmp() will be an asking for troubles, as
it exactly does not restore SS.
dosemu could do a good use of siglongjmp() to get back to 64bit code
from its sighandler.

This seems like it would be relying unpleasantly heavily on libc
internals.

Could you please clarify?
If kernel always passes the right SS to the sighandler, then what's
the problem?

What's the exact siglongjmp usage you have in mind?  Signal context
isn't normally involved AFAIK.

dosemu needs 2 return pathes:
1. to DOS code
2. to 64bit code (dosemu is not all in a sighandler, right?)

How it is currently achieved:
dosemu1:
1. sigreturn() + iret (to DOS)
2. modify sigcontext -> sigreturn() (to 64bit asm helper)

dosemu2:
1. sigreturn() + iret (to DOS)
2. modify sigcontext -> sigreturn() -> longjmp() (to 64bit C-coded)

So you're modifying sigcontext such that it returns to a C function
that calls longjmp?

Yes.


How dosemu2 is supposed to do this:
1. sigreturn() (to DOS)
2. siglongjmp() (to 64bit C-coded)

This should work fine on any kernel, right?

1 - not.
2 - maybe.
If, as you say, siglongjmp() restores SS, I need to try it out.
(there is also a problem that most siglongjmp() implementations
are incompatible with sigaltstack(), but this is not what you can fix).


   The main problem will be
that you presumably need to remember the old context so you can go
back to DOS, I assume.  So SS needs to be there somewhere.

Its fine if you always save SS to sigcontext.
This is what you proposed already and I think its fine.
dosemu saves entire sigcontext before going out to 64bit.


Is the new SA flag such a big deal here to even bother?

Not really, but given that the new behavior seems clearly better
behaved than the old, it would be nice to be able to have the good
behavior, or at least most of it, be the default.

Surely, but how about then having the heuristics you suggest,
only if the new SA_hyz is not set? And when it is set, have a
properly defined and predictable behaviour. Then it seems like
we'll get all the possible wishes covered.

That could work.  The result is quite similar to explicitly setting
UC_STRICT_RESTORE_SS.

I am much more bothered with delivering the right SS than with
restoring it on sigreturn().

For 64-bit delivery, ignoring backwards compatibility, delivering
signals with ss = __USER_DS would be the right solution, I think: it's
trivial and it works.  Because of backwards compatibility, we need to

... add the SA_hyz flag.
I don't understand why do you constantly ignore that part as
if it was never spelled. Lets discuss the proposal as a whole, rather
than with the random bits thrown away. The flag is exactly for
backward compatibility, so why do you present it as a problem
without the context of the new flag?

For backwards compat, we either need the default behavior to be
unchanged, or we need the default behavior to be something that works
with existing dosemu.  For existing dosemu, the only interesting cases
(I think) are signal delivery from *valid* 16-bit context, in which
case we need to preserve SS so that the signal handler can read it out
with mov ..., %ss, and sigreturn to 64-bit mode for the IRET
trampoline.  For sigreturn, IIUC old dosemu will replace the saved CS
with a 64-bit code segment selector and won't touch the saved SS
because it doesn't know about the saved SS.  Those dosemu versions
don't care what SS actually contains after sigreturn, because they're
immediately going to change it again using IRET.  So we just need to
make sure we return without faulting.

New dosemu2 would like to sigreturn directly back to 16-bit mode, so
it needs the 

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Wed, Sep 2, 2015 at 2:01 PM, Stas Sergeev  wrote:
> 02.09.2015 22:06, Andy Lutomirski пишет:
>
>> On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev  wrote:
>>>
>>> 02.09.2015 21:17, Andy Lutomirski пишет:

 On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev  wrote:
>
> 02.09.2015 17:21, Andy Lutomirski пишет:

 This should work for old DOSEMU.  It's a bit gross, but it has the
 nice benefit that everyone (even things that aren't DOSEMU) gain the
 ability to catch signals thrown from bogus SS contexts, which
 probably
 improves debugability.  It's also nice to not have the SA flag.
>>>
>>> Pros:
>>> - No new SA flag
>>> - May improve debugability in some unknown scenario where people
>>> do not want to just use the new flag to get their things improved
>>>
>>> Cons:
>>> - Does not allow to cleanly use siglongjmp(), as then there is a risk
>>> to jump to 64bit code with bad SS
>>
>> What's the issue here?  I don't understand.
>>
>> On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
>> won't be affected.  AFAIK all implementations of siglongjmp are likely
>> to call sigprocmask or similar, and that will clobber SS.  I'm not
>> aware of an implementation of siglongjmp that uses sigreturn.
>
> I am not saying siglongjmp() will be affected.
> Quite the opposite: it won't, which is bad. :)
> If you have always correct SS, you can use siglongjmp(). If you have
> broken SS at times, siglongjmp() will be an asking for troubles, as
> it exactly does not restore SS.
> dosemu could do a good use of siglongjmp() to get back to 64bit code
> from its sighandler.

 This seems like it would be relying unpleasantly heavily on libc
 internals.
>>>
>>> Could you please clarify?
>>> If kernel always passes the right SS to the sighandler, then what's
>>> the problem?
>>
>> What's the exact siglongjmp usage you have in mind?  Signal context
>> isn't normally involved AFAIK.
>
> dosemu needs 2 return pathes:
> 1. to DOS code
> 2. to 64bit code (dosemu is not all in a sighandler, right?)
>
> How it is currently achieved:
> dosemu1:
> 1. sigreturn() + iret (to DOS)
> 2. modify sigcontext -> sigreturn() (to 64bit asm helper)
>
> dosemu2:
> 1. sigreturn() + iret (to DOS)
> 2. modify sigcontext -> sigreturn() -> longjmp() (to 64bit C-coded)

So you're modifying sigcontext such that it returns to a C function
that calls longjmp?

>
> How dosemu2 is supposed to do this:
> 1. sigreturn() (to DOS)
> 2. siglongjmp() (to 64bit C-coded)

This should work fine on any kernel, right?  The main problem will be
that you presumably need to remember the old context so you can go
back to DOS, I assume.  So SS needs to be there somewhere.

>
>>> - Async signals can silently "validate" SS behind your back
>>
>> True, and that's unfortunate.  But async signals without SA_SAVE_SS
>> set with the other approach have exactly the same problem.
>
> Yes, and as such, they should be blocked.
> You could improve on that and on siglongjmp().
> And on TLS in the future.

 *I* can't do anything to siglongjmp because that's almost entirely
 outside the kernel. :-/
>>>
>>> Except for passing the SS=__USER_DS to the sighandler, for which we
>>> discussed the new SA_hyz?
>>
>> I'm still not understanding what you're looking for.  If you
>> siglongjmp out of a signal handler, the hardware SS value is
>> irrelevant, at least on 64-bit binaries, because siglongjmp is just
>> going to replace it.
>
> Hmm? IIRC you've just said this:
> ---
> On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it won't
> be affected.
> ---
> So why would siglongjmp() replace it?

Because siglongjmp calls sigprocmask, which uses SYSCALL, which clobbers SS.

>
>>> Is the new SA flag such a big deal here to even bother?
>>
>> Not really, but given that the new behavior seems clearly better
>> behaved than the old, it would be nice to be able to have the good
>> behavior, or at least most of it, be the default.
>
> Surely, but how about then having the heuristics you suggest,
> only if the new SA_hyz is not set? And when it is set, have a
> properly defined and predictable behaviour. Then it seems like
> we'll get all the possible wishes covered.

 That could work.  The result is quite similar to explicitly setting
 UC_STRICT_RESTORE_SS.
>>>
>>> I am much more bothered with delivering the right SS than with
>>> restoring it on sigreturn().
>>
>> For 64-bit delivery, ignoring backwards compatibility, delivering
>> signals with ss = __USER_DS would be the right solution, I think: it's
>> trivial and it works.  Because of backwards compatibility, we need to
>
> ... add the SA_hyz flag.
> I don't understand why do you constantly ignore that part as
> if it was never spelled. Lets discuss the proposal as a 

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

02.09.2015 22:06, Andy Lutomirski пишет:

On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev  wrote:

02.09.2015 21:17, Andy Lutomirski пишет:

On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev  wrote:

02.09.2015 17:21, Andy Lutomirski пишет:

This should work for old DOSEMU.  It's a bit gross, but it has the
nice benefit that everyone (even things that aren't DOSEMU) gain the
ability to catch signals thrown from bogus SS contexts, which probably
improves debugability.  It's also nice to not have the SA flag.

Pros:
- No new SA flag
- May improve debugability in some unknown scenario where people
do not want to just use the new flag to get their things improved

Cons:
- Does not allow to cleanly use siglongjmp(), as then there is a risk
to jump to 64bit code with bad SS

What's the issue here?  I don't understand.

On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
won't be affected.  AFAIK all implementations of siglongjmp are likely
to call sigprocmask or similar, and that will clobber SS.  I'm not
aware of an implementation of siglongjmp that uses sigreturn.

I am not saying siglongjmp() will be affected.
Quite the opposite: it won't, which is bad. :)
If you have always correct SS, you can use siglongjmp(). If you have
broken SS at times, siglongjmp() will be an asking for troubles, as
it exactly does not restore SS.
dosemu could do a good use of siglongjmp() to get back to 64bit code
from its sighandler.

This seems like it would be relying unpleasantly heavily on libc internals.

Could you please clarify?
If kernel always passes the right SS to the sighandler, then what's
the problem?

What's the exact siglongjmp usage you have in mind?  Signal context
isn't normally involved AFAIK.

dosemu needs 2 return pathes:
1. to DOS code
2. to 64bit code (dosemu is not all in a sighandler, right?)

How it is currently achieved:
dosemu1:
1. sigreturn() + iret (to DOS)
2. modify sigcontext -> sigreturn() (to 64bit asm helper)

dosemu2:
1. sigreturn() + iret (to DOS)
2. modify sigcontext -> sigreturn() -> longjmp() (to 64bit C-coded)

How dosemu2 is supposed to do this:
1. sigreturn() (to DOS)
2. siglongjmp() (to 64bit C-coded)


- Async signals can silently "validate" SS behind your back

True, and that's unfortunate.  But async signals without SA_SAVE_SS
set with the other approach have exactly the same problem.

Yes, and as such, they should be blocked.
You could improve on that and on siglongjmp().
And on TLS in the future.

*I* can't do anything to siglongjmp because that's almost entirely
outside the kernel. :-/

Except for passing the SS=__USER_DS to the sighandler, for which we
discussed the new SA_hyz?

I'm still not understanding what you're looking for.  If you
siglongjmp out of a signal handler, the hardware SS value is
irrelevant, at least on 64-bit binaries, because siglongjmp is just
going to replace it.

Hmm? IIRC you've just said this:
---
On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it 
won't be affected.

---
So why would siglongjmp() replace it?


Is the new SA flag such a big deal here to even bother?

Not really, but given that the new behavior seems clearly better
behaved than the old, it would be nice to be able to have the good
behavior, or at least most of it, be the default.

Surely, but how about then having the heuristics you suggest,
only if the new SA_hyz is not set? And when it is set, have a
properly defined and predictable behaviour. Then it seems like
we'll get all the possible wishes covered.

That could work.  The result is quite similar to explicitly setting
UC_STRICT_RESTORE_SS.

I am much more bothered with delivering the right SS than with
restoring it on sigreturn().

For 64-bit delivery, ignoring backwards compatibility, delivering
signals with ss = __USER_DS would be the right solution, I think: it's
trivial and it works.  Because of backwards compatibility, we need to

... add the SA_hyz flag.
I don't understand why do you constantly ignore that part as
if it was never spelled. Lets discuss the proposal as a whole, rather
than with the random bits thrown away. The flag is exactly for
backward compatibility, so why do you present it as a problem
without the context of the new flag?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev  wrote:
> 02.09.2015 21:17, Andy Lutomirski пишет:
>> On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev  wrote:
>>> 02.09.2015 17:21, Andy Lutomirski пишет:
>> This should work for old DOSEMU.  It's a bit gross, but it has the
>> nice benefit that everyone (even things that aren't DOSEMU) gain the
>> ability to catch signals thrown from bogus SS contexts, which probably
>> improves debugability.  It's also nice to not have the SA flag.
>
> Pros:
> - No new SA flag
> - May improve debugability in some unknown scenario where people
> do not want to just use the new flag to get their things improved
>
> Cons:
> - Does not allow to cleanly use siglongjmp(), as then there is a risk
> to jump to 64bit code with bad SS

 What's the issue here?  I don't understand.

 On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
 won't be affected.  AFAIK all implementations of siglongjmp are likely
 to call sigprocmask or similar, and that will clobber SS.  I'm not
 aware of an implementation of siglongjmp that uses sigreturn.
>>> I am not saying siglongjmp() will be affected.
>>> Quite the opposite: it won't, which is bad. :)
>>> If you have always correct SS, you can use siglongjmp(). If you have
>>> broken SS at times, siglongjmp() will be an asking for troubles, as
>>> it exactly does not restore SS.
>>> dosemu could do a good use of siglongjmp() to get back to 64bit code
>>> from its sighandler.
>>
>> This seems like it would be relying unpleasantly heavily on libc internals.
> Could you please clarify?
> If kernel always passes the right SS to the sighandler, then what's
> the problem?

What's the exact siglongjmp usage you have in mind?  Signal context
isn't normally involved AFAIK.

>
> - Async signals can silently "validate" SS behind your back

 True, and that's unfortunate.  But async signals without SA_SAVE_SS
 set with the other approach have exactly the same problem.
>>> Yes, and as such, they should be blocked.
>>> You could improve on that and on siglongjmp().
>>> And on TLS in the future.
>>
>> *I* can't do anything to siglongjmp because that's almost entirely
>> outside the kernel. :-/
> Except for passing the SS=__USER_DS to the sighandler, for which we
> discussed the new SA_hyz?

I'm still not understanding what you're looking for.  If you
siglongjmp out of a signal handler, the hardware SS value is
irrelevant, at least on 64-bit binaries, because siglongjmp is just
going to replace it.

>
> Is the new SA flag such a big deal here to even bother?

 Not really, but given that the new behavior seems clearly better
 behaved than the old, it would be nice to be able to have the good
 behavior, or at least most of it, be the default.
>>> Surely, but how about then having the heuristics you suggest,
>>> only if the new SA_hyz is not set? And when it is set, have a
>>> properly defined and predictable behaviour. Then it seems like
>>> we'll get all the possible wishes covered.
>>
>> That could work.  The result is quite similar to explicitly setting
>> UC_STRICT_RESTORE_SS.
> I am much more bothered with delivering the right SS than with
> restoring it on sigreturn().

For 64-bit delivery, ignoring backwards compatibility, delivering
signals with ss = __USER_DS would be the right solution, I think: it's
trivial and it works.  Because of backwards compatibility, we need to
deliver signals with ss preserved when possible unless the program
opts out.  But I don't see why new programs would care what SS is,
since it has no effect during 64-bit code execution unless you read it
directly or long jmp/long ret to non-64-bit mode.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

02.09.2015 21:17, Andy Lutomirski пишет:
> On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev  wrote:
>> 02.09.2015 17:21, Andy Lutomirski пишет:
> This should work for old DOSEMU.  It's a bit gross, but it has the
> nice benefit that everyone (even things that aren't DOSEMU) gain the
> ability to catch signals thrown from bogus SS contexts, which probably
> improves debugability.  It's also nice to not have the SA flag.

 Pros:
 - No new SA flag
 - May improve debugability in some unknown scenario where people
 do not want to just use the new flag to get their things improved

 Cons:
 - Does not allow to cleanly use siglongjmp(), as then there is a risk
 to jump to 64bit code with bad SS
>>>
>>> What's the issue here?  I don't understand.
>>>
>>> On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
>>> won't be affected.  AFAIK all implementations of siglongjmp are likely
>>> to call sigprocmask or similar, and that will clobber SS.  I'm not
>>> aware of an implementation of siglongjmp that uses sigreturn.
>> I am not saying siglongjmp() will be affected.
>> Quite the opposite: it won't, which is bad. :)
>> If you have always correct SS, you can use siglongjmp(). If you have
>> broken SS at times, siglongjmp() will be an asking for troubles, as
>> it exactly does not restore SS.
>> dosemu could do a good use of siglongjmp() to get back to 64bit code
>> from its sighandler.
> 
> This seems like it would be relying unpleasantly heavily on libc internals.
Could you please clarify?
If kernel always passes the right SS to the sighandler, then what's
the problem?

 - Async signals can silently "validate" SS behind your back
>>>
>>> True, and that's unfortunate.  But async signals without SA_SAVE_SS
>>> set with the other approach have exactly the same problem.
>> Yes, and as such, they should be blocked.
>> You could improve on that and on siglongjmp().
>> And on TLS in the future.
> 
> *I* can't do anything to siglongjmp because that's almost entirely
> outside the kernel. :-/
Except for passing the SS=__USER_DS to the sighandler, for which we
discussed the new SA_hyz?

 Is the new SA flag such a big deal here to even bother?
>>>
>>> Not really, but given that the new behavior seems clearly better
>>> behaved than the old, it would be nice to be able to have the good
>>> behavior, or at least most of it, be the default.
>> Surely, but how about then having the heuristics you suggest,
>> only if the new SA_hyz is not set? And when it is set, have a
>> properly defined and predictable behaviour. Then it seems like
>> we'll get all the possible wishes covered.
> 
> That could work.  The result is quite similar to explicitly setting
> UC_STRICT_RESTORE_SS.
I am much more bothered with delivering the right SS than with
restoring it on sigreturn().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev  wrote:
> 02.09.2015 17:21, Andy Lutomirski пишет:
 This should work for old DOSEMU.  It's a bit gross, but it has the
 nice benefit that everyone (even things that aren't DOSEMU) gain the
 ability to catch signals thrown from bogus SS contexts, which probably
 improves debugability.  It's also nice to not have the SA flag.
>>>
>>> Pros:
>>> - No new SA flag
>>> - May improve debugability in some unknown scenario where people
>>> do not want to just use the new flag to get their things improved
>>>
>>> Cons:
>>> - Does not allow to cleanly use siglongjmp(), as then there is a risk
>>> to jump to 64bit code with bad SS
>>
>> What's the issue here?  I don't understand.
>>
>> On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
>> won't be affected.  AFAIK all implementations of siglongjmp are likely
>> to call sigprocmask or similar, and that will clobber SS.  I'm not
>> aware of an implementation of siglongjmp that uses sigreturn.
> I am not saying siglongjmp() will be affected.
> Quite the opposite: it won't, which is bad. :)
> If you have always correct SS, you can use siglongjmp(). If you have
> broken SS at times, siglongjmp() will be an asking for troubles, as
> it exactly does not restore SS.
> dosemu could do a good use of siglongjmp() to get back to 64bit code
> from its sighandler.

This seems like it would be relying unpleasantly heavily on libc internals.

What *does* work is to raise a signal and stash away the entire signal
context.  Then raise another signal and restore the old context.  Of
course, this needs SS support in sigcontext, and may still need to
handle DS and ES manually.

>
>>> - Async signals can silently "validate" SS behind your back
>>
>> True, and that's unfortunate.  But async signals without SA_SAVE_SS
>> set with the other approach have exactly the same problem.
> Yes, and as such, they should be blocked.
> You could improve on that and on siglongjmp().
> And on TLS in the future.

*I* can't do anything to siglongjmp because that's almost entirely
outside the kernel. :-/

>
>>> Is the new SA flag such a big deal here to even bother?
>>
>> Not really, but given that the new behavior seems clearly better
>> behaved than the old, it would be nice to be able to have the good
>> behavior, or at least most of it, be the default.
> Surely, but how about then having the heuristics you suggest,
> only if the new SA_hyz is not set? And when it is set, have a
> properly defined and predictable behaviour. Then it seems like
> we'll get all the possible wishes covered.

That could work.  The result is quite similar to explicitly setting
UC_STRICT_RESTORE_SS.

I'll draft up an implementation and we can go from there.

--Andy

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

02.09.2015 17:21, Andy Lutomirski пишет:
>>> This should work for old DOSEMU.  It's a bit gross, but it has the
>>> nice benefit that everyone (even things that aren't DOSEMU) gain the
>>> ability to catch signals thrown from bogus SS contexts, which probably
>>> improves debugability.  It's also nice to not have the SA flag.
>>
>> Pros:
>> - No new SA flag
>> - May improve debugability in some unknown scenario where people
>> do not want to just use the new flag to get their things improved
>>
>> Cons:
>> - Does not allow to cleanly use siglongjmp(), as then there is a risk
>> to jump to 64bit code with bad SS
> 
> What's the issue here?  I don't understand.
> 
> On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
> won't be affected.  AFAIK all implementations of siglongjmp are likely
> to call sigprocmask or similar, and that will clobber SS.  I'm not
> aware of an implementation of siglongjmp that uses sigreturn.
I am not saying siglongjmp() will be affected.
Quite the opposite: it won't, which is bad. :)
If you have always correct SS, you can use siglongjmp(). If you have
broken SS at times, siglongjmp() will be an asking for troubles, as
it exactly does not restore SS.
dosemu could do a good use of siglongjmp() to get back to 64bit code
from its sighandler.

>> - Async signals can silently "validate" SS behind your back
> 
> True, and that's unfortunate.  But async signals without SA_SAVE_SS
> set with the other approach have exactly the same problem.
Yes, and as such, they should be blocked.
You could improve on that and on siglongjmp().
And on TLS in the future.

>> Is the new SA flag such a big deal here to even bother?
> 
> Not really, but given that the new behavior seems clearly better
> behaved than the old, it would be nice to be able to have the good
> behavior, or at least most of it, be the default.
Surely, but how about then having the heuristics you suggest,
only if the new SA_hyz is not set? And when it is set, have a
properly defined and predictable behaviour. Then it seems like
we'll get all the possible wishes covered.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Wed, Sep 2, 2015 at 7:21 AM, Andy Lutomirski  wrote:
> On Wed, Sep 2, 2015 at 2:17 AM, Stas Sergeev  wrote:
>> 02.09.2015 08:12, Andy Lutomirski пишет:
>>
>>> On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev  wrote:

 19.08.2015 18:46, Andy Lutomirski пишет:
>
> On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev  wrote:
>>>
>>> Incidentally, I tried implementing the sigaction flag approach.  I
>>> think it's no good.  When we return from a signal, there's no concept
>>> of sigaction -- it's just sigreturn.  Sigreturn can't look up the
>>> sigaction flags -- what if the signal handler calls sigaction itself.
>>
>> How about the SA_hyz flag that does the following:
>> - Saves SS into sigcontext
>> - Forces SS to USER_DS on signal delivery
>> - Sets the uc_flags flag for sigreturn() to take care of the rest.
>> You'll have both the control on every bit of action, and a simple
>> detection logic: if SA_hyz didn't set the uc flag - it didn't work.
>> You can even employ your lar heuristic here for the case when the
>> aforementioned SA_hyz is not set. But please, please not when it is
>> set! In fact, I wonder if you had in mind exactly that: using the
>> lar heuristic only if the SA_hyz is not set. If so - I misunderstood.
>> Just please don't add it when it is set.
>
> Hmm, interesting.  Maybe that would work for everything.  How's this
> to make it concrete?
>
> Add a sigaction flag SA_RESTORE_SS.
>
> On signal delivery, always save SS into sigcontext->ss. if
> SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS
> and set UC_RESTORE_SS.  If SA_RESTORE_SS is clear, then leave HW SS
> alone (i.e. preserve the old behavior).

 Either that, or employ the lar heuristic for the "not set" case
 (I think its not needed).

> On signal return, if UC_RESTORE_SS is set, then restore
> sigcontext->ss.  If not, then set SS to __USER_DS (as old kernels
> did).
>
> This should change nothing at all (except the initial value of
> sigcontext->ss / __pad0) on old kernels.

 Agreed.

>>> Let me throw out one more possibility, just for completeness:
>>>
>>> We don't add any SA_xyz flags.  On signal delivery, we use the LAR
>>> heuristic.  We always fill in sigcontext->ss, and we set a new
>>> UC_SIGCONTEXT_SS flag to indicate that we support the new behavior.
>>>
>>> On sigreturn, we honor the sigcontext's ss, *unless* CS is 64 bit and
>>> SS is invalid.  In the latter case, we replace the saved ss with
>>> __USER_DS.
>>
>> But this is not a new proposal, see here:
>> https://lkml.org/lkml/2015/8/13/436
>> The very last sentence says exactly the same.
>> I thought this is in the past. :)
>>
>
> True, but I still want to make sure I understand the alternatives
> well, and we never really considered this approach.
>
>>> This should work for old DOSEMU.  It's a bit gross, but it has the
>>> nice benefit that everyone (even things that aren't DOSEMU) gain the
>>> ability to catch signals thrown from bogus SS contexts, which probably
>>> improves debugability.  It's also nice to not have the SA flag.
>>
>> Pros:
>> - No new SA flag
>> - May improve debugability in some unknown scenario where people
>> do not want to just use the new flag to get their things improved
>>
>> Cons:
>> - Does not allow to cleanly use siglongjmp(), as then there is a risk
>> to jump to 64bit code with bad SS
>
> What's the issue here?  I don't understand.
>
> On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
> won't be affected.  AFAIK all implementations of siglongjmp are likely
> to call sigprocmask or similar, and that will clobber SS.  I'm not
> aware of an implementation of siglongjmp that uses sigreturn.
>
>> - Async signals can silently "validate" SS behind your back
>
> True, and that's unfortunate.  But async signals without SA_SAVE_SS
> set with the other approach have exactly the same problem.  At least
> with the approach it won't happen in 32-bit or 16-bit code, as we'd
> only do the heuristic SS fix on sigreturn when returning to 64-bit
> code.
>
>> - No way to extend that solution to later fixing the TLS problem
>
> True.
>
>> - Many ugly checks in the code, that are not always even obvious
>> (eg you wanted to try verw instead, and there was a gotcha with
>> NP bit)
>
> Also true.  OTOH, there'll be a unit test.
>
>>
>> Is the new SA flag such a big deal here to even bother?
>
> Not really, but given that the new behavior seems clearly better
> behaved than the old, it would be nice to be able to have the good
> behavior, or at least most of it, be the default.
>

In fact, I think we can do even better.

On signal delivery:
 - Always set UC_SAVED_SS (for feature detection)
 - Always save SS into sigcontext
 - Use the LAR heuristic to fix SS
 - If the old CS was 64-bit, set UC_STRICT_RESTORE_SS

On sigreturn:
 - Ignore UC_SAVED_SS.
 - 

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Wed, Sep 2, 2015 at 2:17 AM, Stas Sergeev  wrote:
> 02.09.2015 08:12, Andy Lutomirski пишет:
>
>> On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev  wrote:
>>>
>>> 19.08.2015 18:46, Andy Lutomirski пишет:

 On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev  wrote:
>>
>> Incidentally, I tried implementing the sigaction flag approach.  I
>> think it's no good.  When we return from a signal, there's no concept
>> of sigaction -- it's just sigreturn.  Sigreturn can't look up the
>> sigaction flags -- what if the signal handler calls sigaction itself.
>
> How about the SA_hyz flag that does the following:
> - Saves SS into sigcontext
> - Forces SS to USER_DS on signal delivery
> - Sets the uc_flags flag for sigreturn() to take care of the rest.
> You'll have both the control on every bit of action, and a simple
> detection logic: if SA_hyz didn't set the uc flag - it didn't work.
> You can even employ your lar heuristic here for the case when the
> aforementioned SA_hyz is not set. But please, please not when it is
> set! In fact, I wonder if you had in mind exactly that: using the
> lar heuristic only if the SA_hyz is not set. If so - I misunderstood.
> Just please don't add it when it is set.

 Hmm, interesting.  Maybe that would work for everything.  How's this
 to make it concrete?

 Add a sigaction flag SA_RESTORE_SS.

 On signal delivery, always save SS into sigcontext->ss. if
 SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS
 and set UC_RESTORE_SS.  If SA_RESTORE_SS is clear, then leave HW SS
 alone (i.e. preserve the old behavior).
>>>
>>> Either that, or employ the lar heuristic for the "not set" case
>>> (I think its not needed).
>>>
 On signal return, if UC_RESTORE_SS is set, then restore
 sigcontext->ss.  If not, then set SS to __USER_DS (as old kernels
 did).

 This should change nothing at all (except the initial value of
 sigcontext->ss / __pad0) on old kernels.
>>>
>>> Agreed.
>>>
>> Let me throw out one more possibility, just for completeness:
>>
>> We don't add any SA_xyz flags.  On signal delivery, we use the LAR
>> heuristic.  We always fill in sigcontext->ss, and we set a new
>> UC_SIGCONTEXT_SS flag to indicate that we support the new behavior.
>>
>> On sigreturn, we honor the sigcontext's ss, *unless* CS is 64 bit and
>> SS is invalid.  In the latter case, we replace the saved ss with
>> __USER_DS.
>
> But this is not a new proposal, see here:
> https://lkml.org/lkml/2015/8/13/436
> The very last sentence says exactly the same.
> I thought this is in the past. :)
>

True, but I still want to make sure I understand the alternatives
well, and we never really considered this approach.

>> This should work for old DOSEMU.  It's a bit gross, but it has the
>> nice benefit that everyone (even things that aren't DOSEMU) gain the
>> ability to catch signals thrown from bogus SS contexts, which probably
>> improves debugability.  It's also nice to not have the SA flag.
>
> Pros:
> - No new SA flag
> - May improve debugability in some unknown scenario where people
> do not want to just use the new flag to get their things improved
>
> Cons:
> - Does not allow to cleanly use siglongjmp(), as then there is a risk
> to jump to 64bit code with bad SS

What's the issue here?  I don't understand.

On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
won't be affected.  AFAIK all implementations of siglongjmp are likely
to call sigprocmask or similar, and that will clobber SS.  I'm not
aware of an implementation of siglongjmp that uses sigreturn.

> - Async signals can silently "validate" SS behind your back

True, and that's unfortunate.  But async signals without SA_SAVE_SS
set with the other approach have exactly the same problem.  At least
with the approach it won't happen in 32-bit or 16-bit code, as we'd
only do the heuristic SS fix on sigreturn when returning to 64-bit
code.

> - No way to extend that solution to later fixing the TLS problem

True.

> - Many ugly checks in the code, that are not always even obvious
> (eg you wanted to try verw instead, and there was a gotcha with
> NP bit)

Also true.  OTOH, there'll be a unit test.

>
> Is the new SA flag such a big deal here to even bother?

Not really, but given that the new behavior seems clearly better
behaved than the old, it would be nice to be able to have the good
behavior, or at least most of it, be the default.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

02.09.2015 08:12, Andy Lutomirski пишет:

On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev  wrote:

19.08.2015 18:46, Andy Lutomirski пишет:

On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev  wrote:

Incidentally, I tried implementing the sigaction flag approach.  I
think it's no good.  When we return from a signal, there's no concept
of sigaction -- it's just sigreturn.  Sigreturn can't look up the
sigaction flags -- what if the signal handler calls sigaction itself.

How about the SA_hyz flag that does the following:
- Saves SS into sigcontext
- Forces SS to USER_DS on signal delivery
- Sets the uc_flags flag for sigreturn() to take care of the rest.
You'll have both the control on every bit of action, and a simple
detection logic: if SA_hyz didn't set the uc flag - it didn't work.
You can even employ your lar heuristic here for the case when the
aforementioned SA_hyz is not set. But please, please not when it is
set! In fact, I wonder if you had in mind exactly that: using the
lar heuristic only if the SA_hyz is not set. If so - I misunderstood.
Just please don't add it when it is set.

Hmm, interesting.  Maybe that would work for everything.  How's this
to make it concrete?

Add a sigaction flag SA_RESTORE_SS.

On signal delivery, always save SS into sigcontext->ss. if
SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS
and set UC_RESTORE_SS.  If SA_RESTORE_SS is clear, then leave HW SS
alone (i.e. preserve the old behavior).

Either that, or employ the lar heuristic for the "not set" case
(I think its not needed).


On signal return, if UC_RESTORE_SS is set, then restore
sigcontext->ss.  If not, then set SS to __USER_DS (as old kernels
did).

This should change nothing at all (except the initial value of
sigcontext->ss / __pad0) on old kernels.

Agreed.


Let me throw out one more possibility, just for completeness:

We don't add any SA_xyz flags.  On signal delivery, we use the LAR
heuristic.  We always fill in sigcontext->ss, and we set a new
UC_SIGCONTEXT_SS flag to indicate that we support the new behavior.

On sigreturn, we honor the sigcontext's ss, *unless* CS is 64 bit and
SS is invalid.  In the latter case, we replace the saved ss with
__USER_DS.

But this is not a new proposal, see here:
https://lkml.org/lkml/2015/8/13/436
The very last sentence says exactly the same.
I thought this is in the past. :)


This should work for old DOSEMU.  It's a bit gross, but it has the
nice benefit that everyone (even things that aren't DOSEMU) gain the
ability to catch signals thrown from bogus SS contexts, which probably
improves debugability.  It's also nice to not have the SA flag.

Pros:
- No new SA flag
- May improve debugability in some unknown scenario where people
do not want to just use the new flag to get their things improved

Cons:
- Does not allow to cleanly use siglongjmp(), as then there is a risk
to jump to 64bit code with bad SS
- Async signals can silently "validate" SS behind your back
- No way to extend that solution to later fixing the TLS problem
- Many ugly checks in the code, that are not always even obvious
(eg you wanted to try verw instead, and there was a gotcha with
NP bit)

Is the new SA flag such a big deal here to even bother?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

02.09.2015 08:12, Andy Lutomirski пишет:

On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev  wrote:

19.08.2015 18:46, Andy Lutomirski пишет:

On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev  wrote:

Incidentally, I tried implementing the sigaction flag approach.  I
think it's no good.  When we return from a signal, there's no concept
of sigaction -- it's just sigreturn.  Sigreturn can't look up the
sigaction flags -- what if the signal handler calls sigaction itself.

How about the SA_hyz flag that does the following:
- Saves SS into sigcontext
- Forces SS to USER_DS on signal delivery
- Sets the uc_flags flag for sigreturn() to take care of the rest.
You'll have both the control on every bit of action, and a simple
detection logic: if SA_hyz didn't set the uc flag - it didn't work.
You can even employ your lar heuristic here for the case when the
aforementioned SA_hyz is not set. But please, please not when it is
set! In fact, I wonder if you had in mind exactly that: using the
lar heuristic only if the SA_hyz is not set. If so - I misunderstood.
Just please don't add it when it is set.

Hmm, interesting.  Maybe that would work for everything.  How's this
to make it concrete?

Add a sigaction flag SA_RESTORE_SS.

On signal delivery, always save SS into sigcontext->ss. if
SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS
and set UC_RESTORE_SS.  If SA_RESTORE_SS is clear, then leave HW SS
alone (i.e. preserve the old behavior).

Either that, or employ the lar heuristic for the "not set" case
(I think its not needed).


On signal return, if UC_RESTORE_SS is set, then restore
sigcontext->ss.  If not, then set SS to __USER_DS (as old kernels
did).

This should change nothing at all (except the initial value of
sigcontext->ss / __pad0) on old kernels.

Agreed.


Let me throw out one more possibility, just for completeness:

We don't add any SA_xyz flags.  On signal delivery, we use the LAR
heuristic.  We always fill in sigcontext->ss, and we set a new
UC_SIGCONTEXT_SS flag to indicate that we support the new behavior.

On sigreturn, we honor the sigcontext's ss, *unless* CS is 64 bit and
SS is invalid.  In the latter case, we replace the saved ss with
__USER_DS.

But this is not a new proposal, see here:
https://lkml.org/lkml/2015/8/13/436
The very last sentence says exactly the same.
I thought this is in the past. :)


This should work for old DOSEMU.  It's a bit gross, but it has the
nice benefit that everyone (even things that aren't DOSEMU) gain the
ability to catch signals thrown from bogus SS contexts, which probably
improves debugability.  It's also nice to not have the SA flag.

Pros:
- No new SA flag
- May improve debugability in some unknown scenario where people
do not want to just use the new flag to get their things improved

Cons:
- Does not allow to cleanly use siglongjmp(), as then there is a risk
to jump to 64bit code with bad SS
- Async signals can silently "validate" SS behind your back
- No way to extend that solution to later fixing the TLS problem
- Many ugly checks in the code, that are not always even obvious
(eg you wanted to try verw instead, and there was a gotcha with
NP bit)

Is the new SA flag such a big deal here to even bother?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

02.09.2015 17:21, Andy Lutomirski пишет:
>>> This should work for old DOSEMU.  It's a bit gross, but it has the
>>> nice benefit that everyone (even things that aren't DOSEMU) gain the
>>> ability to catch signals thrown from bogus SS contexts, which probably
>>> improves debugability.  It's also nice to not have the SA flag.
>>
>> Pros:
>> - No new SA flag
>> - May improve debugability in some unknown scenario where people
>> do not want to just use the new flag to get their things improved
>>
>> Cons:
>> - Does not allow to cleanly use siglongjmp(), as then there is a risk
>> to jump to 64bit code with bad SS
> 
> What's the issue here?  I don't understand.
> 
> On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
> won't be affected.  AFAIK all implementations of siglongjmp are likely
> to call sigprocmask or similar, and that will clobber SS.  I'm not
> aware of an implementation of siglongjmp that uses sigreturn.
I am not saying siglongjmp() will be affected.
Quite the opposite: it won't, which is bad. :)
If you have always correct SS, you can use siglongjmp(). If you have
broken SS at times, siglongjmp() will be an asking for troubles, as
it exactly does not restore SS.
dosemu could do a good use of siglongjmp() to get back to 64bit code
from its sighandler.

>> - Async signals can silently "validate" SS behind your back
> 
> True, and that's unfortunate.  But async signals without SA_SAVE_SS
> set with the other approach have exactly the same problem.
Yes, and as such, they should be blocked.
You could improve on that and on siglongjmp().
And on TLS in the future.

>> Is the new SA flag such a big deal here to even bother?
> 
> Not really, but given that the new behavior seems clearly better
> behaved than the old, it would be nice to be able to have the good
> behavior, or at least most of it, be the default.
Surely, but how about then having the heuristics you suggest,
only if the new SA_hyz is not set? And when it is set, have a
properly defined and predictable behaviour. Then it seems like
we'll get all the possible wishes covered.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

02.09.2015 21:17, Andy Lutomirski пишет:
> On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev  wrote:
>> 02.09.2015 17:21, Andy Lutomirski пишет:
> This should work for old DOSEMU.  It's a bit gross, but it has the
> nice benefit that everyone (even things that aren't DOSEMU) gain the
> ability to catch signals thrown from bogus SS contexts, which probably
> improves debugability.  It's also nice to not have the SA flag.

 Pros:
 - No new SA flag
 - May improve debugability in some unknown scenario where people
 do not want to just use the new flag to get their things improved

 Cons:
 - Does not allow to cleanly use siglongjmp(), as then there is a risk
 to jump to 64bit code with bad SS
>>>
>>> What's the issue here?  I don't understand.
>>>
>>> On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
>>> won't be affected.  AFAIK all implementations of siglongjmp are likely
>>> to call sigprocmask or similar, and that will clobber SS.  I'm not
>>> aware of an implementation of siglongjmp that uses sigreturn.
>> I am not saying siglongjmp() will be affected.
>> Quite the opposite: it won't, which is bad. :)
>> If you have always correct SS, you can use siglongjmp(). If you have
>> broken SS at times, siglongjmp() will be an asking for troubles, as
>> it exactly does not restore SS.
>> dosemu could do a good use of siglongjmp() to get back to 64bit code
>> from its sighandler.
> 
> This seems like it would be relying unpleasantly heavily on libc internals.
Could you please clarify?
If kernel always passes the right SS to the sighandler, then what's
the problem?

 - Async signals can silently "validate" SS behind your back
>>>
>>> True, and that's unfortunate.  But async signals without SA_SAVE_SS
>>> set with the other approach have exactly the same problem.
>> Yes, and as such, they should be blocked.
>> You could improve on that and on siglongjmp().
>> And on TLS in the future.
> 
> *I* can't do anything to siglongjmp because that's almost entirely
> outside the kernel. :-/
Except for passing the SS=__USER_DS to the sighandler, for which we
discussed the new SA_hyz?

 Is the new SA flag such a big deal here to even bother?
>>>
>>> Not really, but given that the new behavior seems clearly better
>>> behaved than the old, it would be nice to be able to have the good
>>> behavior, or at least most of it, be the default.
>> Surely, but how about then having the heuristics you suggest,
>> only if the new SA_hyz is not set? And when it is set, have a
>> properly defined and predictable behaviour. Then it seems like
>> we'll get all the possible wishes covered.
> 
> That could work.  The result is quite similar to explicitly setting
> UC_STRICT_RESTORE_SS.
I am much more bothered with delivering the right SS than with
restoring it on sigreturn().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev  wrote:
> 02.09.2015 17:21, Andy Lutomirski пишет:
 This should work for old DOSEMU.  It's a bit gross, but it has the
 nice benefit that everyone (even things that aren't DOSEMU) gain the
 ability to catch signals thrown from bogus SS contexts, which probably
 improves debugability.  It's also nice to not have the SA flag.
>>>
>>> Pros:
>>> - No new SA flag
>>> - May improve debugability in some unknown scenario where people
>>> do not want to just use the new flag to get their things improved
>>>
>>> Cons:
>>> - Does not allow to cleanly use siglongjmp(), as then there is a risk
>>> to jump to 64bit code with bad SS
>>
>> What's the issue here?  I don't understand.
>>
>> On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
>> won't be affected.  AFAIK all implementations of siglongjmp are likely
>> to call sigprocmask or similar, and that will clobber SS.  I'm not
>> aware of an implementation of siglongjmp that uses sigreturn.
> I am not saying siglongjmp() will be affected.
> Quite the opposite: it won't, which is bad. :)
> If you have always correct SS, you can use siglongjmp(). If you have
> broken SS at times, siglongjmp() will be an asking for troubles, as
> it exactly does not restore SS.
> dosemu could do a good use of siglongjmp() to get back to 64bit code
> from its sighandler.

This seems like it would be relying unpleasantly heavily on libc internals.

What *does* work is to raise a signal and stash away the entire signal
context.  Then raise another signal and restore the old context.  Of
course, this needs SS support in sigcontext, and may still need to
handle DS and ES manually.

>
>>> - Async signals can silently "validate" SS behind your back
>>
>> True, and that's unfortunate.  But async signals without SA_SAVE_SS
>> set with the other approach have exactly the same problem.
> Yes, and as such, they should be blocked.
> You could improve on that and on siglongjmp().
> And on TLS in the future.

*I* can't do anything to siglongjmp because that's almost entirely
outside the kernel. :-/

>
>>> Is the new SA flag such a big deal here to even bother?
>>
>> Not really, but given that the new behavior seems clearly better
>> behaved than the old, it would be nice to be able to have the good
>> behavior, or at least most of it, be the default.
> Surely, but how about then having the heuristics you suggest,
> only if the new SA_hyz is not set? And when it is set, have a
> properly defined and predictable behaviour. Then it seems like
> we'll get all the possible wishes covered.

That could work.  The result is quite similar to explicitly setting
UC_STRICT_RESTORE_SS.

I'll draft up an implementation and we can go from there.

--Andy

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev  wrote:
> 02.09.2015 21:17, Andy Lutomirski пишет:
>> On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev  wrote:
>>> 02.09.2015 17:21, Andy Lutomirski пишет:
>> This should work for old DOSEMU.  It's a bit gross, but it has the
>> nice benefit that everyone (even things that aren't DOSEMU) gain the
>> ability to catch signals thrown from bogus SS contexts, which probably
>> improves debugability.  It's also nice to not have the SA flag.
>
> Pros:
> - No new SA flag
> - May improve debugability in some unknown scenario where people
> do not want to just use the new flag to get their things improved
>
> Cons:
> - Does not allow to cleanly use siglongjmp(), as then there is a risk
> to jump to 64bit code with bad SS

 What's the issue here?  I don't understand.

 On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
 won't be affected.  AFAIK all implementations of siglongjmp are likely
 to call sigprocmask or similar, and that will clobber SS.  I'm not
 aware of an implementation of siglongjmp that uses sigreturn.
>>> I am not saying siglongjmp() will be affected.
>>> Quite the opposite: it won't, which is bad. :)
>>> If you have always correct SS, you can use siglongjmp(). If you have
>>> broken SS at times, siglongjmp() will be an asking for troubles, as
>>> it exactly does not restore SS.
>>> dosemu could do a good use of siglongjmp() to get back to 64bit code
>>> from its sighandler.
>>
>> This seems like it would be relying unpleasantly heavily on libc internals.
> Could you please clarify?
> If kernel always passes the right SS to the sighandler, then what's
> the problem?

What's the exact siglongjmp usage you have in mind?  Signal context
isn't normally involved AFAIK.

>
> - Async signals can silently "validate" SS behind your back

 True, and that's unfortunate.  But async signals without SA_SAVE_SS
 set with the other approach have exactly the same problem.
>>> Yes, and as such, they should be blocked.
>>> You could improve on that and on siglongjmp().
>>> And on TLS in the future.
>>
>> *I* can't do anything to siglongjmp because that's almost entirely
>> outside the kernel. :-/
> Except for passing the SS=__USER_DS to the sighandler, for which we
> discussed the new SA_hyz?

I'm still not understanding what you're looking for.  If you
siglongjmp out of a signal handler, the hardware SS value is
irrelevant, at least on 64-bit binaries, because siglongjmp is just
going to replace it.

>
> Is the new SA flag such a big deal here to even bother?

 Not really, but given that the new behavior seems clearly better
 behaved than the old, it would be nice to be able to have the good
 behavior, or at least most of it, be the default.
>>> Surely, but how about then having the heuristics you suggest,
>>> only if the new SA_hyz is not set? And when it is set, have a
>>> properly defined and predictable behaviour. Then it seems like
>>> we'll get all the possible wishes covered.
>>
>> That could work.  The result is quite similar to explicitly setting
>> UC_STRICT_RESTORE_SS.
> I am much more bothered with delivering the right SS than with
> restoring it on sigreturn().

For 64-bit delivery, ignoring backwards compatibility, delivering
signals with ss = __USER_DS would be the right solution, I think: it's
trivial and it works.  Because of backwards compatibility, we need to
deliver signals with ss preserved when possible unless the program
opts out.  But I don't see why new programs would care what SS is,
since it has no effect during 64-bit code execution unless you read it
directly or long jmp/long ret to non-64-bit mode.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

02.09.2015 22:06, Andy Lutomirski пишет:

On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev  wrote:

02.09.2015 21:17, Andy Lutomirski пишет:

On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev  wrote:

02.09.2015 17:21, Andy Lutomirski пишет:

This should work for old DOSEMU.  It's a bit gross, but it has the
nice benefit that everyone (even things that aren't DOSEMU) gain the
ability to catch signals thrown from bogus SS contexts, which probably
improves debugability.  It's also nice to not have the SA flag.

Pros:
- No new SA flag
- May improve debugability in some unknown scenario where people
do not want to just use the new flag to get their things improved

Cons:
- Does not allow to cleanly use siglongjmp(), as then there is a risk
to jump to 64bit code with bad SS

What's the issue here?  I don't understand.

On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
won't be affected.  AFAIK all implementations of siglongjmp are likely
to call sigprocmask or similar, and that will clobber SS.  I'm not
aware of an implementation of siglongjmp that uses sigreturn.

I am not saying siglongjmp() will be affected.
Quite the opposite: it won't, which is bad. :)
If you have always correct SS, you can use siglongjmp(). If you have
broken SS at times, siglongjmp() will be an asking for troubles, as
it exactly does not restore SS.
dosemu could do a good use of siglongjmp() to get back to 64bit code
from its sighandler.

This seems like it would be relying unpleasantly heavily on libc internals.

Could you please clarify?
If kernel always passes the right SS to the sighandler, then what's
the problem?

What's the exact siglongjmp usage you have in mind?  Signal context
isn't normally involved AFAIK.

dosemu needs 2 return pathes:
1. to DOS code
2. to 64bit code (dosemu is not all in a sighandler, right?)

How it is currently achieved:
dosemu1:
1. sigreturn() + iret (to DOS)
2. modify sigcontext -> sigreturn() (to 64bit asm helper)

dosemu2:
1. sigreturn() + iret (to DOS)
2. modify sigcontext -> sigreturn() -> longjmp() (to 64bit C-coded)

How dosemu2 is supposed to do this:
1. sigreturn() (to DOS)
2. siglongjmp() (to 64bit C-coded)


- Async signals can silently "validate" SS behind your back

True, and that's unfortunate.  But async signals without SA_SAVE_SS
set with the other approach have exactly the same problem.

Yes, and as such, they should be blocked.
You could improve on that and on siglongjmp().
And on TLS in the future.

*I* can't do anything to siglongjmp because that's almost entirely
outside the kernel. :-/

Except for passing the SS=__USER_DS to the sighandler, for which we
discussed the new SA_hyz?

I'm still not understanding what you're looking for.  If you
siglongjmp out of a signal handler, the hardware SS value is
irrelevant, at least on 64-bit binaries, because siglongjmp is just
going to replace it.

Hmm? IIRC you've just said this:
---
On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it 
won't be affected.

---
So why would siglongjmp() replace it?


Is the new SA flag such a big deal here to even bother?

Not really, but given that the new behavior seems clearly better
behaved than the old, it would be nice to be able to have the good
behavior, or at least most of it, be the default.

Surely, but how about then having the heuristics you suggest,
only if the new SA_hyz is not set? And when it is set, have a
properly defined and predictable behaviour. Then it seems like
we'll get all the possible wishes covered.

That could work.  The result is quite similar to explicitly setting
UC_STRICT_RESTORE_SS.

I am much more bothered with delivering the right SS than with
restoring it on sigreturn().

For 64-bit delivery, ignoring backwards compatibility, delivering
signals with ss = __USER_DS would be the right solution, I think: it's
trivial and it works.  Because of backwards compatibility, we need to

... add the SA_hyz flag.
I don't understand why do you constantly ignore that part as
if it was never spelled. Lets discuss the proposal as a whole, rather
than with the random bits thrown away. The flag is exactly for
backward compatibility, so why do you present it as a problem
without the context of the new flag?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

03.09.2015 01:25, Andy Lutomirski пишет:

On Wed, Sep 2, 2015 at 3:25 PM, Stas Sergeev  wrote:


How dosemu2 is supposed to do this:
1. sigreturn() (to DOS)
2. siglongjmp() (to 64bit C-coded)

This should work fine on any kernel, right?

1 - not.
2 - maybe.
If, as you say, siglongjmp() restores SS, I need to try it out.
(there is also a problem that most siglongjmp() implementations
are incompatible with sigaltstack(), but this is not what you can fix).


1 - definitely needs kernel changes.  I was referring to #2.

2 - siglongjmp probably varies in its behavior across different libc
implementations.  My point is that siglongjmp isn't a kernel-provided
thing.

So if siglongjmp() restores SS by the side-effect of doing a sigprocmask()
syscall, this admittedly weakens my point.
The unreliability then stays only with the async signals interrupting
the main one.


For backwards compat, we either need the default behavior to be
unchanged, or we need the default behavior to be something that works
with existing dosemu.  For existing dosemu, the only interesting cases
(I think) are signal delivery from *valid* 16-bit context, in which
case we need to preserve SS so that the signal handler can read it out
with mov ..., %ss, and sigreturn to 64-bit mode for the IRET
trampoline.  For sigreturn, IIUC old dosemu will replace the saved CS
with a 64-bit code segment selector and won't touch the saved SS
because it doesn't know about the saved SS.  Those dosemu versions
don't care what SS actually contains after sigreturn, because they're
immediately going to change it again using IRET.  So we just need to
make sure we return without faulting.

New dosemu2 would like to sigreturn directly back to 16-bit mode, so
it needs the kernel to honor the saved ss value and restore it,
possibly changed by dosemu.

We obviously can't require old dosemu to set an SA flag to keep
working.  But, if we can get away with it, I think it's somewhat
preferable not to require new DOSEMU to set an SA flag either.

This has one major benefit at least: if new dosemu loads some random
library that installs some async signal handler (SIGALRM for example),
everything will work with regard to CS and SS.

This case is covered if we do both things together: use
your heuristic when SA_hyz is not set, and don't use it
when its set. In this case dosemu2 will be able to request
the proper SS delivery for its sighandlers, but the 3rd-party
sighandlers will work too.
I think we have never discussed the possibility of doing
both things together, even though I have proposed it many
times.
After discussing this full-blown solution, we can think about
reducing it, either by removing the heuristic or by removing
SA_hyz, but discussing the full one would be nice too.
Your opinion is likely that no one will use this SA_hyz in
presence of the heuristic that "seems to work anyway".
But in the light of extending it for TLS (with a new flag),
I wouldn't be so sure. You can also document it as a
needed flag when user code touches SS, and then it will
be used. dosemu1 code that doesn't use it, will eventually
be forgotten. So IMHO whether it will be used, is fully up
to how will you market it. :)

I'll think about it.  I'll think about FS and GS, too,

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Wed, Sep 2, 2015 at 2:01 PM, Stas Sergeev  wrote:
> 02.09.2015 22:06, Andy Lutomirski пишет:
>
>> On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev  wrote:
>>>
>>> 02.09.2015 21:17, Andy Lutomirski пишет:

 On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev  wrote:
>
> 02.09.2015 17:21, Andy Lutomirski пишет:

 This should work for old DOSEMU.  It's a bit gross, but it has the
 nice benefit that everyone (even things that aren't DOSEMU) gain the
 ability to catch signals thrown from bogus SS contexts, which
 probably
 improves debugability.  It's also nice to not have the SA flag.
>>>
>>> Pros:
>>> - No new SA flag
>>> - May improve debugability in some unknown scenario where people
>>> do not want to just use the new flag to get their things improved
>>>
>>> Cons:
>>> - Does not allow to cleanly use siglongjmp(), as then there is a risk
>>> to jump to 64bit code with bad SS
>>
>> What's the issue here?  I don't understand.
>>
>> On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
>> won't be affected.  AFAIK all implementations of siglongjmp are likely
>> to call sigprocmask or similar, and that will clobber SS.  I'm not
>> aware of an implementation of siglongjmp that uses sigreturn.
>
> I am not saying siglongjmp() will be affected.
> Quite the opposite: it won't, which is bad. :)
> If you have always correct SS, you can use siglongjmp(). If you have
> broken SS at times, siglongjmp() will be an asking for troubles, as
> it exactly does not restore SS.
> dosemu could do a good use of siglongjmp() to get back to 64bit code
> from its sighandler.

 This seems like it would be relying unpleasantly heavily on libc
 internals.
>>>
>>> Could you please clarify?
>>> If kernel always passes the right SS to the sighandler, then what's
>>> the problem?
>>
>> What's the exact siglongjmp usage you have in mind?  Signal context
>> isn't normally involved AFAIK.
>
> dosemu needs 2 return pathes:
> 1. to DOS code
> 2. to 64bit code (dosemu is not all in a sighandler, right?)
>
> How it is currently achieved:
> dosemu1:
> 1. sigreturn() + iret (to DOS)
> 2. modify sigcontext -> sigreturn() (to 64bit asm helper)
>
> dosemu2:
> 1. sigreturn() + iret (to DOS)
> 2. modify sigcontext -> sigreturn() -> longjmp() (to 64bit C-coded)

So you're modifying sigcontext such that it returns to a C function
that calls longjmp?

>
> How dosemu2 is supposed to do this:
> 1. sigreturn() (to DOS)
> 2. siglongjmp() (to 64bit C-coded)

This should work fine on any kernel, right?  The main problem will be
that you presumably need to remember the old context so you can go
back to DOS, I assume.  So SS needs to be there somewhere.

>
>>> - Async signals can silently "validate" SS behind your back
>>
>> True, and that's unfortunate.  But async signals without SA_SAVE_SS
>> set with the other approach have exactly the same problem.
>
> Yes, and as such, they should be blocked.
> You could improve on that and on siglongjmp().
> And on TLS in the future.

 *I* can't do anything to siglongjmp because that's almost entirely
 outside the kernel. :-/
>>>
>>> Except for passing the SS=__USER_DS to the sighandler, for which we
>>> discussed the new SA_hyz?
>>
>> I'm still not understanding what you're looking for.  If you
>> siglongjmp out of a signal handler, the hardware SS value is
>> irrelevant, at least on 64-bit binaries, because siglongjmp is just
>> going to replace it.
>
> Hmm? IIRC you've just said this:
> ---
> On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it won't
> be affected.
> ---
> So why would siglongjmp() replace it?

Because siglongjmp calls sigprocmask, which uses SYSCALL, which clobbers SS.

>
>>> Is the new SA flag such a big deal here to even bother?
>>
>> Not really, but given that the new behavior seems clearly better
>> behaved than the old, it would be nice to be able to have the good
>> behavior, or at least most of it, be the default.
>
> Surely, but how about then having the heuristics you suggest,
> only if the new SA_hyz is not set? And when it is set, have a
> properly defined and predictable behaviour. Then it seems like
> we'll get all the possible wishes covered.

 That could work.  The result is quite similar to explicitly setting
 UC_STRICT_RESTORE_SS.
>>>
>>> I am much more bothered with delivering the right SS than with
>>> restoring it on sigreturn().
>>
>> For 64-bit delivery, ignoring backwards compatibility, delivering
>> signals with ss = __USER_DS would be the right solution, I think: it's
>> trivial and it works.  Because of backwards compatibility, we need to
>
> ... add the SA_hyz flag.
> I don't understand why do you constantly ignore that part as
> if it was never 

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

03.09.2015 00:39, Andy Lutomirski пишет:

On Wed, Sep 2, 2015 at 2:01 PM, Stas Sergeev  wrote:

02.09.2015 22:06, Andy Lutomirski пишет:


On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev  wrote:

02.09.2015 21:17, Andy Lutomirski пишет:

On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev  wrote:

02.09.2015 17:21, Andy Lutomirski пишет:

This should work for old DOSEMU.  It's a bit gross, but it has the
nice benefit that everyone (even things that aren't DOSEMU) gain the
ability to catch signals thrown from bogus SS contexts, which
probably
improves debugability.  It's also nice to not have the SA flag.

Pros:
- No new SA flag
- May improve debugability in some unknown scenario where people
do not want to just use the new flag to get their things improved

Cons:
- Does not allow to cleanly use siglongjmp(), as then there is a risk
to jump to 64bit code with bad SS

What's the issue here?  I don't understand.

On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
won't be affected.  AFAIK all implementations of siglongjmp are likely
to call sigprocmask or similar, and that will clobber SS.  I'm not
aware of an implementation of siglongjmp that uses sigreturn.

I am not saying siglongjmp() will be affected.
Quite the opposite: it won't, which is bad. :)
If you have always correct SS, you can use siglongjmp(). If you have
broken SS at times, siglongjmp() will be an asking for troubles, as
it exactly does not restore SS.
dosemu could do a good use of siglongjmp() to get back to 64bit code
from its sighandler.

This seems like it would be relying unpleasantly heavily on libc
internals.

Could you please clarify?
If kernel always passes the right SS to the sighandler, then what's
the problem?

What's the exact siglongjmp usage you have in mind?  Signal context
isn't normally involved AFAIK.

dosemu needs 2 return pathes:
1. to DOS code
2. to 64bit code (dosemu is not all in a sighandler, right?)

How it is currently achieved:
dosemu1:
1. sigreturn() + iret (to DOS)
2. modify sigcontext -> sigreturn() (to 64bit asm helper)

dosemu2:
1. sigreturn() + iret (to DOS)
2. modify sigcontext -> sigreturn() -> longjmp() (to 64bit C-coded)

So you're modifying sigcontext such that it returns to a C function
that calls longjmp?

Yes.


How dosemu2 is supposed to do this:
1. sigreturn() (to DOS)
2. siglongjmp() (to 64bit C-coded)

This should work fine on any kernel, right?

1 - not.
2 - maybe.
If, as you say, siglongjmp() restores SS, I need to try it out.
(there is also a problem that most siglongjmp() implementations
are incompatible with sigaltstack(), but this is not what you can fix).


   The main problem will be
that you presumably need to remember the old context so you can go
back to DOS, I assume.  So SS needs to be there somewhere.

Its fine if you always save SS to sigcontext.
This is what you proposed already and I think its fine.
dosemu saves entire sigcontext before going out to 64bit.


Is the new SA flag such a big deal here to even bother?

Not really, but given that the new behavior seems clearly better
behaved than the old, it would be nice to be able to have the good
behavior, or at least most of it, be the default.

Surely, but how about then having the heuristics you suggest,
only if the new SA_hyz is not set? And when it is set, have a
properly defined and predictable behaviour. Then it seems like
we'll get all the possible wishes covered.

That could work.  The result is quite similar to explicitly setting
UC_STRICT_RESTORE_SS.

I am much more bothered with delivering the right SS than with
restoring it on sigreturn().

For 64-bit delivery, ignoring backwards compatibility, delivering
signals with ss = __USER_DS would be the right solution, I think: it's
trivial and it works.  Because of backwards compatibility, we need to

... add the SA_hyz flag.
I don't understand why do you constantly ignore that part as
if it was never spelled. Lets discuss the proposal as a whole, rather
than with the random bits thrown away. The flag is exactly for
backward compatibility, so why do you present it as a problem
without the context of the new flag?

For backwards compat, we either need the default behavior to be
unchanged, or we need the default behavior to be something that works
with existing dosemu.  For existing dosemu, the only interesting cases
(I think) are signal delivery from *valid* 16-bit context, in which
case we need to preserve SS so that the signal handler can read it out
with mov ..., %ss, and sigreturn to 64-bit mode for the IRET
trampoline.  For sigreturn, IIUC old dosemu will replace the saved CS
with a 64-bit code segment selector and won't touch the saved SS
because it doesn't know about the saved SS.  Those dosemu versions
don't care what SS actually contains after sigreturn, because they're
immediately going to change it again using IRET.  So we just need to
make sure we return without faulting.

New dosemu2 would like to sigreturn 

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Wed, Sep 2, 2015 at 3:25 PM, Stas Sergeev  wrote:
> 03.09.2015 00:39, Andy Lutomirski пишет:
>
>> On Wed, Sep 2, 2015 at 2:01 PM, Stas Sergeev  wrote:
>>>
>>> 02.09.2015 22:06, Andy Lutomirski пишет:
>>>
 On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev  wrote:
>
> 02.09.2015 21:17, Andy Lutomirski пишет:
>>
>> On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev  wrote:
>>>
>>> 02.09.2015 17:21, Andy Lutomirski пишет:
>>
>> This should work for old DOSEMU.  It's a bit gross, but it has the
>> nice benefit that everyone (even things that aren't DOSEMU) gain
>> the
>> ability to catch signals thrown from bogus SS contexts, which
>> probably
>> improves debugability.  It's also nice to not have the SA flag.
>
> Pros:
> - No new SA flag
> - May improve debugability in some unknown scenario where people
> do not want to just use the new flag to get their things improved
>
> Cons:
> - Does not allow to cleanly use siglongjmp(), as then there is a
> risk
> to jump to 64bit code with bad SS

 What's the issue here?  I don't understand.

 On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so
 it
 won't be affected.  AFAIK all implementations of siglongjmp are
 likely
 to call sigprocmask or similar, and that will clobber SS.  I'm not
 aware of an implementation of siglongjmp that uses sigreturn.
>>>
>>> I am not saying siglongjmp() will be affected.
>>> Quite the opposite: it won't, which is bad. :)
>>> If you have always correct SS, you can use siglongjmp(). If you have
>>> broken SS at times, siglongjmp() will be an asking for troubles, as
>>> it exactly does not restore SS.
>>> dosemu could do a good use of siglongjmp() to get back to 64bit code
>>> from its sighandler.
>>
>> This seems like it would be relying unpleasantly heavily on libc
>> internals.
>
> Could you please clarify?
> If kernel always passes the right SS to the sighandler, then what's
> the problem?

 What's the exact siglongjmp usage you have in mind?  Signal context
 isn't normally involved AFAIK.
>>>
>>> dosemu needs 2 return pathes:
>>> 1. to DOS code
>>> 2. to 64bit code (dosemu is not all in a sighandler, right?)
>>>
>>> How it is currently achieved:
>>> dosemu1:
>>> 1. sigreturn() + iret (to DOS)
>>> 2. modify sigcontext -> sigreturn() (to 64bit asm helper)
>>>
>>> dosemu2:
>>> 1. sigreturn() + iret (to DOS)
>>> 2. modify sigcontext -> sigreturn() -> longjmp() (to 64bit C-coded)
>>
>> So you're modifying sigcontext such that it returns to a C function
>> that calls longjmp?
>
> Yes.
>
>>> How dosemu2 is supposed to do this:
>>> 1. sigreturn() (to DOS)
>>> 2. siglongjmp() (to 64bit C-coded)
>>
>> This should work fine on any kernel, right?
>
> 1 - not.
> 2 - maybe.
> If, as you say, siglongjmp() restores SS, I need to try it out.
> (there is also a problem that most siglongjmp() implementations
> are incompatible with sigaltstack(), but this is not what you can fix).
>

1 - definitely needs kernel changes.  I was referring to #2.

2 - siglongjmp probably varies in its behavior across different libc
implementations.  My point is that siglongjmp isn't a kernel-provided
thing.

>> For backwards compat, we either need the default behavior to be
>> unchanged, or we need the default behavior to be something that works
>> with existing dosemu.  For existing dosemu, the only interesting cases
>> (I think) are signal delivery from *valid* 16-bit context, in which
>> case we need to preserve SS so that the signal handler can read it out
>> with mov ..., %ss, and sigreturn to 64-bit mode for the IRET
>> trampoline.  For sigreturn, IIUC old dosemu will replace the saved CS
>> with a 64-bit code segment selector and won't touch the saved SS
>> because it doesn't know about the saved SS.  Those dosemu versions
>> don't care what SS actually contains after sigreturn, because they're
>> immediately going to change it again using IRET.  So we just need to
>> make sure we return without faulting.
>>
>> New dosemu2 would like to sigreturn directly back to 16-bit mode, so
>> it needs the kernel to honor the saved ss value and restore it,
>> possibly changed by dosemu.
>>
>> We obviously can't require old dosemu to set an SA flag to keep
>> working.  But, if we can get away with it, I think it's somewhat
>> preferable not to require new DOSEMU to set an SA flag either.
>>
>> This has one major benefit at least: if new dosemu loads some random
>> library that installs some async signal handler (SIGALRM for example),
>> everything will work with regard to CS and SS.
>
> This case is covered if we do both things together: use
> your heuristic when SA_hyz is not set, and don't use it
> when its set. 

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Wed, Sep 2, 2015 at 7:21 AM, Andy Lutomirski  wrote:
> On Wed, Sep 2, 2015 at 2:17 AM, Stas Sergeev  wrote:
>> 02.09.2015 08:12, Andy Lutomirski пишет:
>>
>>> On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev  wrote:

 19.08.2015 18:46, Andy Lutomirski пишет:
>
> On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev  wrote:
>>>
>>> Incidentally, I tried implementing the sigaction flag approach.  I
>>> think it's no good.  When we return from a signal, there's no concept
>>> of sigaction -- it's just sigreturn.  Sigreturn can't look up the
>>> sigaction flags -- what if the signal handler calls sigaction itself.
>>
>> How about the SA_hyz flag that does the following:
>> - Saves SS into sigcontext
>> - Forces SS to USER_DS on signal delivery
>> - Sets the uc_flags flag for sigreturn() to take care of the rest.
>> You'll have both the control on every bit of action, and a simple
>> detection logic: if SA_hyz didn't set the uc flag - it didn't work.
>> You can even employ your lar heuristic here for the case when the
>> aforementioned SA_hyz is not set. But please, please not when it is
>> set! In fact, I wonder if you had in mind exactly that: using the
>> lar heuristic only if the SA_hyz is not set. If so - I misunderstood.
>> Just please don't add it when it is set.
>
> Hmm, interesting.  Maybe that would work for everything.  How's this
> to make it concrete?
>
> Add a sigaction flag SA_RESTORE_SS.
>
> On signal delivery, always save SS into sigcontext->ss. if
> SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS
> and set UC_RESTORE_SS.  If SA_RESTORE_SS is clear, then leave HW SS
> alone (i.e. preserve the old behavior).

 Either that, or employ the lar heuristic for the "not set" case
 (I think its not needed).

> On signal return, if UC_RESTORE_SS is set, then restore
> sigcontext->ss.  If not, then set SS to __USER_DS (as old kernels
> did).
>
> This should change nothing at all (except the initial value of
> sigcontext->ss / __pad0) on old kernels.

 Agreed.

>>> Let me throw out one more possibility, just for completeness:
>>>
>>> We don't add any SA_xyz flags.  On signal delivery, we use the LAR
>>> heuristic.  We always fill in sigcontext->ss, and we set a new
>>> UC_SIGCONTEXT_SS flag to indicate that we support the new behavior.
>>>
>>> On sigreturn, we honor the sigcontext's ss, *unless* CS is 64 bit and
>>> SS is invalid.  In the latter case, we replace the saved ss with
>>> __USER_DS.
>>
>> But this is not a new proposal, see here:
>> https://lkml.org/lkml/2015/8/13/436
>> The very last sentence says exactly the same.
>> I thought this is in the past. :)
>>
>
> True, but I still want to make sure I understand the alternatives
> well, and we never really considered this approach.
>
>>> This should work for old DOSEMU.  It's a bit gross, but it has the
>>> nice benefit that everyone (even things that aren't DOSEMU) gain the
>>> ability to catch signals thrown from bogus SS contexts, which probably
>>> improves debugability.  It's also nice to not have the SA flag.
>>
>> Pros:
>> - No new SA flag
>> - May improve debugability in some unknown scenario where people
>> do not want to just use the new flag to get their things improved
>>
>> Cons:
>> - Does not allow to cleanly use siglongjmp(), as then there is a risk
>> to jump to 64bit code with bad SS
>
> What's the issue here?  I don't understand.
>
> On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
> won't be affected.  AFAIK all implementations of siglongjmp are likely
> to call sigprocmask or similar, and that will clobber SS.  I'm not
> aware of an implementation of siglongjmp that uses sigreturn.
>
>> - Async signals can silently "validate" SS behind your back
>
> True, and that's unfortunate.  But async signals without SA_SAVE_SS
> set with the other approach have exactly the same problem.  At least
> with the approach it won't happen in 32-bit or 16-bit code, as we'd
> only do the heuristic SS fix on sigreturn when returning to 64-bit
> code.
>
>> - No way to extend that solution to later fixing the TLS problem
>
> True.
>
>> - Many ugly checks in the code, that are not always even obvious
>> (eg you wanted to try verw instead, and there was a gotcha with
>> NP bit)
>
> Also true.  OTOH, there'll be a unit test.
>
>>
>> Is the new SA flag such a big deal here to even bother?
>
> Not really, but given that the new behavior seems clearly better
> behaved than the old, it would be nice to be able to have the good
> behavior, or at least most of it, be the default.
>

In fact, I think we can do even better.

On signal delivery:
 - Always set UC_SAVED_SS (for feature detection)
 - Always save SS into sigcontext
 - Use the LAR heuristic to fix SS
 - If the old CS was 64-bit, set 

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Wed, Sep 2, 2015 at 2:17 AM, Stas Sergeev  wrote:
> 02.09.2015 08:12, Andy Lutomirski пишет:
>
>> On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev  wrote:
>>>
>>> 19.08.2015 18:46, Andy Lutomirski пишет:

 On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev  wrote:
>>
>> Incidentally, I tried implementing the sigaction flag approach.  I
>> think it's no good.  When we return from a signal, there's no concept
>> of sigaction -- it's just sigreturn.  Sigreturn can't look up the
>> sigaction flags -- what if the signal handler calls sigaction itself.
>
> How about the SA_hyz flag that does the following:
> - Saves SS into sigcontext
> - Forces SS to USER_DS on signal delivery
> - Sets the uc_flags flag for sigreturn() to take care of the rest.
> You'll have both the control on every bit of action, and a simple
> detection logic: if SA_hyz didn't set the uc flag - it didn't work.
> You can even employ your lar heuristic here for the case when the
> aforementioned SA_hyz is not set. But please, please not when it is
> set! In fact, I wonder if you had in mind exactly that: using the
> lar heuristic only if the SA_hyz is not set. If so - I misunderstood.
> Just please don't add it when it is set.

 Hmm, interesting.  Maybe that would work for everything.  How's this
 to make it concrete?

 Add a sigaction flag SA_RESTORE_SS.

 On signal delivery, always save SS into sigcontext->ss. if
 SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS
 and set UC_RESTORE_SS.  If SA_RESTORE_SS is clear, then leave HW SS
 alone (i.e. preserve the old behavior).
>>>
>>> Either that, or employ the lar heuristic for the "not set" case
>>> (I think its not needed).
>>>
 On signal return, if UC_RESTORE_SS is set, then restore
 sigcontext->ss.  If not, then set SS to __USER_DS (as old kernels
 did).

 This should change nothing at all (except the initial value of
 sigcontext->ss / __pad0) on old kernels.
>>>
>>> Agreed.
>>>
>> Let me throw out one more possibility, just for completeness:
>>
>> We don't add any SA_xyz flags.  On signal delivery, we use the LAR
>> heuristic.  We always fill in sigcontext->ss, and we set a new
>> UC_SIGCONTEXT_SS flag to indicate that we support the new behavior.
>>
>> On sigreturn, we honor the sigcontext's ss, *unless* CS is 64 bit and
>> SS is invalid.  In the latter case, we replace the saved ss with
>> __USER_DS.
>
> But this is not a new proposal, see here:
> https://lkml.org/lkml/2015/8/13/436
> The very last sentence says exactly the same.
> I thought this is in the past. :)
>

True, but I still want to make sure I understand the alternatives
well, and we never really considered this approach.

>> This should work for old DOSEMU.  It's a bit gross, but it has the
>> nice benefit that everyone (even things that aren't DOSEMU) gain the
>> ability to catch signals thrown from bogus SS contexts, which probably
>> improves debugability.  It's also nice to not have the SA flag.
>
> Pros:
> - No new SA flag
> - May improve debugability in some unknown scenario where people
> do not want to just use the new flag to get their things improved
>
> Cons:
> - Does not allow to cleanly use siglongjmp(), as then there is a risk
> to jump to 64bit code with bad SS

What's the issue here?  I don't understand.

On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
won't be affected.  AFAIK all implementations of siglongjmp are likely
to call sigprocmask or similar, and that will clobber SS.  I'm not
aware of an implementation of siglongjmp that uses sigreturn.

> - Async signals can silently "validate" SS behind your back

True, and that's unfortunate.  But async signals without SA_SAVE_SS
set with the other approach have exactly the same problem.  At least
with the approach it won't happen in 32-bit or 16-bit code, as we'd
only do the heuristic SS fix on sigreturn when returning to 64-bit
code.

> - No way to extend that solution to later fixing the TLS problem

True.

> - Many ugly checks in the code, that are not always even obvious
> (eg you wanted to try verw instead, and there was a gotcha with
> NP bit)

Also true.  OTOH, there'll be a unit test.

>
> Is the new SA flag such a big deal here to even bother?

Not really, but given that the new behavior seems clearly better
behaved than the old, it would be nice to be able to have the good
behavior, or at least most of it, be the default.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev  wrote:
> 19.08.2015 18:46, Andy Lutomirski пишет:
>> On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev  wrote:
 Incidentally, I tried implementing the sigaction flag approach.  I
 think it's no good.  When we return from a signal, there's no concept
 of sigaction -- it's just sigreturn.  Sigreturn can't look up the
 sigaction flags -- what if the signal handler calls sigaction itself.
>>> How about the SA_hyz flag that does the following:
>>> - Saves SS into sigcontext
>>> - Forces SS to USER_DS on signal delivery
>>> - Sets the uc_flags flag for sigreturn() to take care of the rest.
>>> You'll have both the control on every bit of action, and a simple
>>> detection logic: if SA_hyz didn't set the uc flag - it didn't work.
>>> You can even employ your lar heuristic here for the case when the
>>> aforementioned SA_hyz is not set. But please, please not when it is
>>> set! In fact, I wonder if you had in mind exactly that: using the
>>> lar heuristic only if the SA_hyz is not set. If so - I misunderstood.
>>> Just please don't add it when it is set.
>>
>> Hmm, interesting.  Maybe that would work for everything.  How's this
>> to make it concrete?
>>
>> Add a sigaction flag SA_RESTORE_SS.
>>
>> On signal delivery, always save SS into sigcontext->ss. if
>> SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS
>> and set UC_RESTORE_SS.  If SA_RESTORE_SS is clear, then leave HW SS
>> alone (i.e. preserve the old behavior).
> Either that, or employ the lar heuristic for the "not set" case
> (I think its not needed).
>
>> On signal return, if UC_RESTORE_SS is set, then restore
>> sigcontext->ss.  If not, then set SS to __USER_DS (as old kernels
>> did).
>>
>> This should change nothing at all (except the initial value of
>> sigcontext->ss / __pad0) on old kernels.
> Agreed.
>

Let me throw out one more possibility, just for completeness:

We don't add any SA_xyz flags.  On signal delivery, we use the LAR
heuristic.  We always fill in sigcontext->ss, and we set a new
UC_SIGCONTEXT_SS flag to indicate that we support the new behavior.

On sigreturn, we honor the sigcontext's ss, *unless* CS is 64 bit and
SS is invalid.  In the latter case, we replace the saved ss with
__USER_DS.

This should work for old DOSEMU.  It's a bit gross, but it has the
nice benefit that everyone (even things that aren't DOSEMU) gain the
ability to catch signals thrown from bogus SS contexts, which probably
improves debugability.  It's also nice to not have the SA flag.

This is a big problematic for my sigreturn_64 test, but I can deal
with that.  We could optionally have another UC_RESTORE_EXACT_SS flag
that you can set that means "no, really, restore the saved SS".

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev  wrote:
> 19.08.2015 18:46, Andy Lutomirski пишет:
>> On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev  wrote:
 Incidentally, I tried implementing the sigaction flag approach.  I
 think it's no good.  When we return from a signal, there's no concept
 of sigaction -- it's just sigreturn.  Sigreturn can't look up the
 sigaction flags -- what if the signal handler calls sigaction itself.
>>> How about the SA_hyz flag that does the following:
>>> - Saves SS into sigcontext
>>> - Forces SS to USER_DS on signal delivery
>>> - Sets the uc_flags flag for sigreturn() to take care of the rest.
>>> You'll have both the control on every bit of action, and a simple
>>> detection logic: if SA_hyz didn't set the uc flag - it didn't work.
>>> You can even employ your lar heuristic here for the case when the
>>> aforementioned SA_hyz is not set. But please, please not when it is
>>> set! In fact, I wonder if you had in mind exactly that: using the
>>> lar heuristic only if the SA_hyz is not set. If so - I misunderstood.
>>> Just please don't add it when it is set.
>>
>> Hmm, interesting.  Maybe that would work for everything.  How's this
>> to make it concrete?
>>
>> Add a sigaction flag SA_RESTORE_SS.
>>
>> On signal delivery, always save SS into sigcontext->ss. if
>> SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS
>> and set UC_RESTORE_SS.  If SA_RESTORE_SS is clear, then leave HW SS
>> alone (i.e. preserve the old behavior).
> Either that, or employ the lar heuristic for the "not set" case
> (I think its not needed).
>
>> On signal return, if UC_RESTORE_SS is set, then restore
>> sigcontext->ss.  If not, then set SS to __USER_DS (as old kernels
>> did).
>>
>> This should change nothing at all (except the initial value of
>> sigcontext->ss / __pad0) on old kernels.
> Agreed.
>

Let me throw out one more possibility, just for completeness:

We don't add any SA_xyz flags.  On signal delivery, we use the LAR
heuristic.  We always fill in sigcontext->ss, and we set a new
UC_SIGCONTEXT_SS flag to indicate that we support the new behavior.

On sigreturn, we honor the sigcontext's ss, *unless* CS is 64 bit and
SS is invalid.  In the latter case, we replace the saved ss with
__USER_DS.

This should work for old DOSEMU.  It's a bit gross, but it has the
nice benefit that everyone (even things that aren't DOSEMU) gain the
ability to catch signals thrown from bogus SS contexts, which probably
improves debugability.  It's also nice to not have the SA flag.

This is a big problematic for my sigreturn_64 test, but I can deal
with that.  We could optionally have another UC_RESTORE_EXACT_SS flag
that you can set that means "no, really, restore the saved SS".

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Ingo Molnar]

* Stas Sergeev  wrote:

> Also, the fact that dosemu already have that functionality,
> doesn't mean it will not use the new API - it actually will.

So if dosemu makes use of the new facility then sure, I'm not
against it at all!

Thanks,

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Ingo Molnar]

* Stas Sergeev s...@list.ru wrote:

 Also, the fact that dosemu already have that functionality,
 doesn't mean it will not use the new API - it actually will.

So if dosemu makes use of the new facility then sure, I'm not
against it at all!

Thanks,

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

22.08.2015 15:38, Ingo Molnar пишет:

[...]  We could add yet more heuristics and teach sigreturn to ignore the saved
SS value in sigcontext if the saved CS is 64-bit and the saved SS is unusable.

We could maybe try this - assuming it doesn't break DOSEMU.

Or we could extend the ABI and allow DOSEMU to cleanly use it.

I'm not sure it's worth the complexity, given that the DOSEMU workaround already
exists and will likely exist forever, so that it can support older kernels, 
right?

That assumes dosemu is the only current and future
user of that functionality. That's why I raised the question
whether does Wine want to support a 32/16bit code in its
64bit builds too. So far it doesn't have such functionality,
likely waiting for the kernel to provide it, rather than going
the route of hacks and work-arounds as dosemu did.

Also, the fact that dosemu already have that functionality,
doesn't mean it will not use the new API - it actually will.
With a few run-time checks at first, but when all distros are
upgraded, there is simply no point to support the kernels
that are not in any current distro (after a few years of
deprecation perhaps).

Overall, I think the existance of a few hacks in dosemu is
not the reason for the linux kernel to stop any development
in that area. dosemu did a great work of exploring all the
pitfalls in that area, so now you know what to fix and how.
Please, keep the things going.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Ingo Molnar]

* Andy Lutomirski  wrote:

> > The crash happens when DOS program terminates.
> > At that point dosemu subverts the execution flow by
> > replacing segregs and cs/ip ss/sp in sigcontext with its own.
> > But __pad0 still has DOS SS, which crash because (presumably)
> > the DOS LDT have been just removed.
> 
> That's unfortunate.
> 
> I don't really know what to do about this.  My stupid heuristic for
> signal delivery seems unlikely to cause problems, but I'm not coming
> up with a great heuristic for detecting when a program that *modifies*
> sigcontext hasn't set all the fields.  Even adding a flag won't really
> help here, since DOSEMU won't know to manipulate the flag.
> 
> Ingo, here's the situation, assuming I remember the versions right:
> 
> v4.0 and before: If we try to deliver a signal while SS is bad, we
> fail and the process dies.  If SS is good but nonstandard, we end up
> in the signal handler with whatever SS value was loaded when the
> signal was sent.  We do *not* put SS anywhere in the sigcontext, so
> the only way for a program to figure out what SS was is to look at the
> HW state before making any syscalls.  We also don't even try to
> restore SS, so SS is unconditionally set to __USER_DS, necessitating
> nasty workarounds (and breaking all kinds of test cases).
> 
> v4.1 and current -linus: We always set SS to __USER_DS when delivering
> a signal.  We save the old SS in the sigcontext and restore it, just
> like 32-bit signals.
> 
> My patch: We leave SS alone when delivering a signal, unless it's
> invalid, in which case we replace it with __USER_DS.  We still save
> the old SS in the sigcontext and restore it on return.
> 
> Apparently the remaining regression is that DOSEMU doesn't realize
> that SS is saved so, when it tries to return to full 64-bit mode after
> a signal that hit in 16-bit mode, it fails because it's invalidated
> the old SS descriptor in the mean time.
> 
> 
> So...  what do we do about it?  We could revert the whole mess.

Yes, absolutely - we should restore the ABI behavior to where v4.0 and before 
stood.

> [...] We could tell everyone to fix their DOSEMU, which violates policy and 
> is 
> especially annoying given how much effort we've put into keeping 16-bit mode 
> fully functional lately. [...]

So calling DOSEMU broken annoys me: there's nothing to 'fix' in DOSEMU really.

DOSEMU tried hard to work around a kernel bug. 100% of the blame and the 
responsibility to keep things working is on the kernel side. No ifs and whens.

> [...]  We could add yet more heuristics and teach sigreturn to ignore the 
> saved 
> SS value in sigcontext if the saved CS is 64-bit and the saved SS is unusable.

We could maybe try this - assuming it doesn't break DOSEMU.

Or we could extend the ABI and allow DOSEMU to cleanly use it.

I'm not sure it's worth the complexity, given that the DOSEMU workaround 
already 
exists and will likely exist forever, so that it can support older kernels, 
right?

Thanks,

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Ingo Molnar]

* Andy Lutomirski l...@amacapital.net wrote:

  The crash happens when DOS program terminates.
  At that point dosemu subverts the execution flow by
  replacing segregs and cs/ip ss/sp in sigcontext with its own.
  But __pad0 still has DOS SS, which crash because (presumably)
  the DOS LDT have been just removed.
 
 That's unfortunate.
 
 I don't really know what to do about this.  My stupid heuristic for
 signal delivery seems unlikely to cause problems, but I'm not coming
 up with a great heuristic for detecting when a program that *modifies*
 sigcontext hasn't set all the fields.  Even adding a flag won't really
 help here, since DOSEMU won't know to manipulate the flag.
 
 Ingo, here's the situation, assuming I remember the versions right:
 
 v4.0 and before: If we try to deliver a signal while SS is bad, we
 fail and the process dies.  If SS is good but nonstandard, we end up
 in the signal handler with whatever SS value was loaded when the
 signal was sent.  We do *not* put SS anywhere in the sigcontext, so
 the only way for a program to figure out what SS was is to look at the
 HW state before making any syscalls.  We also don't even try to
 restore SS, so SS is unconditionally set to __USER_DS, necessitating
 nasty workarounds (and breaking all kinds of test cases).
 
 v4.1 and current -linus: We always set SS to __USER_DS when delivering
 a signal.  We save the old SS in the sigcontext and restore it, just
 like 32-bit signals.
 
 My patch: We leave SS alone when delivering a signal, unless it's
 invalid, in which case we replace it with __USER_DS.  We still save
 the old SS in the sigcontext and restore it on return.
 
 Apparently the remaining regression is that DOSEMU doesn't realize
 that SS is saved so, when it tries to return to full 64-bit mode after
 a signal that hit in 16-bit mode, it fails because it's invalidated
 the old SS descriptor in the mean time.
 
 
 So...  what do we do about it?  We could revert the whole mess.

Yes, absolutely - we should restore the ABI behavior to where v4.0 and before 
stood.

 [...] We could tell everyone to fix their DOSEMU, which violates policy and 
 is 
 especially annoying given how much effort we've put into keeping 16-bit mode 
 fully functional lately. [...]

So calling DOSEMU broken annoys me: there's nothing to 'fix' in DOSEMU really.

DOSEMU tried hard to work around a kernel bug. 100% of the blame and the 
responsibility to keep things working is on the kernel side. No ifs and whens.

 [...]  We could add yet more heuristics and teach sigreturn to ignore the 
 saved 
 SS value in sigcontext if the saved CS is 64-bit and the saved SS is unusable.

We could maybe try this - assuming it doesn't break DOSEMU.

Or we could extend the ABI and allow DOSEMU to cleanly use it.

I'm not sure it's worth the complexity, given that the DOSEMU workaround 
already 
exists and will likely exist forever, so that it can support older kernels, 
right?

Thanks,

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

22.08.2015 15:38, Ingo Molnar пишет:

[...]  We could add yet more heuristics and teach sigreturn to ignore the saved
SS value in sigcontext if the saved CS is 64-bit and the saved SS is unusable.

We could maybe try this - assuming it doesn't break DOSEMU.

Or we could extend the ABI and allow DOSEMU to cleanly use it.

I'm not sure it's worth the complexity, given that the DOSEMU workaround already
exists and will likely exist forever, so that it can support older kernels, 
right?

That assumes dosemu is the only current and future
user of that functionality. That's why I raised the question
whether does Wine want to support a 32/16bit code in its
64bit builds too. So far it doesn't have such functionality,
likely waiting for the kernel to provide it, rather than going
the route of hacks and work-arounds as dosemu did.

Also, the fact that dosemu already have that functionality,
doesn't mean it will not use the new API - it actually will.
With a few run-time checks at first, but when all distros are
upgraded, there is simply no point to support the kernels
that are not in any current distro (after a few years of
deprecation perhaps).

Overall, I think the existance of a few hacks in dosemu is
not the reason for the linux kernel to stop any development
in that area. dosemu did a great work of exploring all the
pitfalls in that area, so now you know what to fix and how.
Please, keep the things going.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

19.08.2015 18:46, Andy Lutomirski пишет:
> On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev  wrote:
>>> Incidentally, I tried implementing the sigaction flag approach.  I
>>> think it's no good.  When we return from a signal, there's no concept
>>> of sigaction -- it's just sigreturn.  Sigreturn can't look up the
>>> sigaction flags -- what if the signal handler calls sigaction itself.
>> How about the SA_hyz flag that does the following:
>> - Saves SS into sigcontext
>> - Forces SS to USER_DS on signal delivery
>> - Sets the uc_flags flag for sigreturn() to take care of the rest.
>> You'll have both the control on every bit of action, and a simple
>> detection logic: if SA_hyz didn't set the uc flag - it didn't work.
>> You can even employ your lar heuristic here for the case when the
>> aforementioned SA_hyz is not set. But please, please not when it is
>> set! In fact, I wonder if you had in mind exactly that: using the
>> lar heuristic only if the SA_hyz is not set. If so - I misunderstood.
>> Just please don't add it when it is set.
> 
> Hmm, interesting.  Maybe that would work for everything.  How's this
> to make it concrete?
> 
> Add a sigaction flag SA_RESTORE_SS.
> 
> On signal delivery, always save SS into sigcontext->ss. if
> SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS
> and set UC_RESTORE_SS.  If SA_RESTORE_SS is clear, then leave HW SS
> alone (i.e. preserve the old behavior).
Either that, or employ the lar heuristic for the "not set" case
(I think its not needed).

> On signal return, if UC_RESTORE_SS is set, then restore
> sigcontext->ss.  If not, then set SS to __USER_DS (as old kernels
> did).
> 
> This should change nothing at all (except the initial value of
> sigcontext->ss / __pad0) on old kernels.
Agreed.

>>> So we either need a per-task flag, a per-sighand flag, or a sigcontext
>>> flag indicating what we should do.
>>>
>>> (Yes, I suspect we really might want some way to get FS, GS, and their
>>> bases saved and restored, but I still think we should do that
>>> separately.)
>> In fact, I have already convinced myself that SA_hyz can take
>> care of both cases. :) Maybe you'll just need to extend the struct sigaction
>> to pass the TLS address, but this doesn't look absolutely impossible...
> 
> I think that should be a separate SA_ flag down the road,
Of course separate.
I only wanted to get a "somewhat similar" solution, so if the
TLS case can also be covered by the (different) SA_ flag (plus
perhaps a struct sigaction extension), then its just excellent.
What I was afraid of is to get an SS-specific fix, like your
initial uc_flags+lar_heuristic solution. Such fix can't be
extended to the TLS case, reducing the chances for the TLS case
to be ever re-visited.

> Also, it occurs to me that FS and GS could become more complicated.
> There are some proposals to allow tasks to opt in to having a per-cpu
> GS.  If that happens, then figuring out how it would interact with
> signals could be complicated.
Is this a problem?
At least on 86_64, according to this:
http://wiki.osdev.org/Thread_Local_Storage#x86-64
we only need FS.
In any case, since what you say about GS is optional and should
be explicitly requested by the task, it can just disable the use
of the new SA_TLS flag, making the sigaction() to return error for
example. I think the amount of the supported combinations should
be limited by the practical needs, and I don't think someone will
need per-cpu GS with sighandler re-setting it to something non-per-cpu.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev  wrote:
> 19.08.2015 01:47, Andy Lutomirski пишет:
>> On Mon, Aug 17, 2015 at 11:19 PM, Stas Sergeev  wrote:
>>> 14.08.2015 04:37, Andy Lutomirski пишет:
>>>
 On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev  wrote:
>
> 14.08.2015 04:21, Andy Lutomirski пишет:
>
>> On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev  wrote:
>>>
>>> 14.08.2015 03:27, Linus Torvalds пишет:

 On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev  wrote:
>
> For example because you can as well do:
> prctl(ARCH_SET_SIGNAL_SS, 0)
> which will mean "restore ss in sighandler to its current value",

 I really think a prctl() is the wrong thing to do.

 If you want a signal handler to save/restore segments, I think it
 should be a SA_xyz flag to sigaction() (the way we have SA_RESTART
>>>
>>> Yes, I was proposing the new sigaction() flag in this thread
>>> already too. But at the end, prctl() looks better to me because
>>> it allows to pass the TLS value to use when restoring FS.
>>> The thing is that I am trying to find the similar treatment for
>>> both the SS and FS problems. If you don't think they need a
>>> similar treatment, then perhaps the Andy's patch is enough.
>>>
 etc).  And off by default because of the obvious compatibility issues.
>>>
>>> Of course.
>>>
>>> So, what we have right now (in the latest Andy's patch) is:
>>> 1. lar heuristics
>>> 2. new uc_flags flag
>>>
>>> What it solves: dosemu's regression.
>>>
>>> What prctl() can give:
>>> - fix to dosemu's regression
>>> - fix to the TLS problem in the future
>>> - no hack and heuristics
>>>
>>> With SA_xyz you can only solve the SS problem, so it is
>>> probably not any better than the uc_flags things coded
>>> up by Andy.
>>
>> I'm leaning slightly toward LAR heuristic + SA_SAVE_SS.
>
> Stop right here, doesn't the SA_xyz allow to avoid the
> lar heuristic? Why would you still need the lar heuristic then?
> Just call it SA_RESTORE_SS instead of SA_SAVE_SS, and
> the lar heuristic is gone.

 The LAR heuristic is about five lines of code, and it makes signal
 delivery more reliable.
>>>
>>> Why more reliable? In what case?
>>>
Sure, we could gate the "regs->ss =
 __USER_DS" line on a flag, but why?
>>>
>>> A few things I can think of why:
>>> - nested signals (usual for dosemu)
>>
>> What's the issue with nested signals?
> If nested signal is async and SS is from LDT just freed, then
> the nested signal will silently change the SS value. So if you
> are saving it somewhere, you'll save it by luck.
> Now this is unlikely to happen, as the async signals in dosemu
> are all blocked inside any sighandler. So the siglongjmp() case
> is more expressive: if dosemu jumped via siglongjmp() and as such
> unblocked the async signals, it will likely want to save its
> registers before doing a new switch. Now, since SS is invalid
> and will be therefore changed by a sighandler, what it will save
> depends on a luck.
> Not that dosemu uses siglongjmp() right now, but I am just asking
> to please not implement the unreliable interfaces _if possible_.

Ok, I think I get it.

I'm not proposing the LAR thing as something that anyone should
intentionally use going forward.  It would only be for compatbility
with old code if needed.  We certainly should save SS somewhere.

>> Incidentally, I tried implementing the sigaction flag approach.  I
>> think it's no good.  When we return from a signal, there's no concept
>> of sigaction -- it's just sigreturn.  Sigreturn can't look up the
>> sigaction flags -- what if the signal handler calls sigaction itself.
> How about the SA_hyz flag that does the following:
> - Saves SS into sigcontext
> - Forces SS to USER_DS on signal delivery
> - Sets the uc_flags flag for sigreturn() to take care of the rest.
> You'll have both the control on every bit of action, and a simple
> detection logic: if SA_hyz didn't set the uc flag - it didn't work.
> You can even employ your lar heuristic here for the case when the
> aforementioned SA_hyz is not set. But please, please not when it is
> set! In fact, I wonder if you had in mind exactly that: using the
> lar heuristic only if the SA_hyz is not set. If so - I misunderstood.
> Just please don't add it when it is set.

Hmm, interesting.  Maybe that would work for everything.  How's this
to make it concrete?

Add a sigaction flag SA_RESTORE_SS.

On signal delivery, always save SS into sigcontext->ss. if
SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS
and set UC_RESTORE_SS.  If SA_RESTORE_SS is clear, then leave HW SS
alone (i.e. preserve the old behavior).

On signal return, if UC_RESTORE_SS is set, then restore
sigcontext->ss.  If not, then set SS to __USER_DS (as old kernels
did).

This 

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Wed, Aug 19, 2015 at 3:10 AM, Stas Sergeev  wrote:
> 19.08.2015 01:42, Andy Lutomirski пишет:
>> What do you mean lack of proper 32/16 bit support?
> At least the following:
>
> 1. vm86().
> There was a patch:
> http://v86-64.sourceforge.net/
> Afaik rejected by Andi Kleen (likely for a good reason - too complex).
> There is some kvm-based alternative which IIRC was called by dosemu authors
> as "too slow", and so they started to use a jit-compiler. Wine have started
> to use dosbox for the DOS progs AFAIK. So both projects have a work-arounds
> to this limitation with which they are happy, and so it probably not worth
> the re-visiting.
>

Wow!

Yeah, that's quite a hack.  EFI mixed mode support used to play
similar tricks.  Unfortunately, switching in and out of long mode at
runtime works very poorly and has terrible interactions with perf, so
EFI stopped doing that.

> 2. espfix64.
> Its there since 3.16, but dosemu have lots of work-arounds in its code.
> The iret trampoline, for example, uses the carefully aligned stack page,
> where the high word of ESP is zero.
> Another part of the work-around is in a sighandler to decode the
> instruction to figure out what register caused a fault (corrupted esp
> value usually goes into ebp first, then to other regs) and zero out
> the high word of that, plus the high word of esp. There are also other
> bits of the work-around spread around the dosemu code, and I am surprised
> it actually even works!

Wow, no kidding!  At least this is fixed now.

>
> 3. SS problem. Was fixed in some versions of 4.1; not fixed any more. ;)
> dosemu did a glorious iret work-around.
>
> 4. FS problem.
> Worked around by autoconf checks to ban some gcc options, plus some
> special care when accessing thread-local vars in a sighandler.
> While your suggestion is to write an asm handlers, to the date I don't
> think anyone did that. It is easier to work-around it by other means.
> Maybe if you show an example of such handler, the things will change,
> but it is simpler to just wait for a kernel fix IMHO.
>

Something like:

mov $__NR_arch_prctl, %rax
mov $ARCH_GET_FS, %rdi
mov [wherever you safe fsbase], %rsi
syscall
mov $ARCH_SET_FS, %rdi
mov (wherever you stashed glibc's value), %rsi
syscall
pushq $0
call real_signal_handler
popq %rax
mov $__NR_arch_prctl, %rax
mov $ARCH_SET_FS, %rdi
mov (saved value), %rsi
syscall
ret

Yeah, it's ugly.  It may very well be worth changing this once the
FSBASE stuff happens.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

19.08.2015 01:42, Andy Lutomirski пишет:
> On Mon, Aug 17, 2015 at 11:29 PM, Stas Sergeev  wrote:
>> 13.08.2015 20:00, Brian Gerst пишет:
>>
>>> On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski 
>>> wrote:

 On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds
  wrote:
>
> On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev  wrote:
>>
>> I realize this patch may be good to have in general, but
>> breaking userspace without a single warning is a bit
>> discouraging. Seems like the old "we don't break userspace"
>> rule have gone.
>
> That rule hasn't gone anywhere.
>
> Does a plain revert just fix everything? Because if so, that's the
> right thing to do, and we can just re-visit this later.
>
> I don't understand why Andy and Ingo are even discussing this. What
> the f*ck, guys?
>
 I'm trying to fix it without reverting.  If that doesn't work, then we
 revert.  Yesterday, I thought I had a reasonably clean fix, but it
 turned out that it only solved half of the problem.

 If we revert, I think I need to check what will break due to the
 revert.  I need to check at least Wine, and we'll have to do something
 about all the selftests that will start failing.  I also need to check
 CRIU, and IIRC CRIU has started using the new sigcontext SS in new
 versions.
>>>
>>> I don't think Wine will be a problem, at least how it is currently set
>>> up.  16-bit support is only in the 32-bit build.  The 64-bit build
>>> only supports Win64 apps, and will call the 32-bit version (installed
>>> in parallel) to run 32 and 16-bit apps.
>>
>> Is this also because of the lack of the proper 32/16bit support in
>> a 64bit kernels? If so, dosemu's work-arounds do not look like the
>> too bad thing compared to that. :)
> 
> What do you mean lack of proper 32/16 bit support?
At least the following:

1. vm86().
There was a patch:
http://v86-64.sourceforge.net/
Afaik rejected by Andi Kleen (likely for a good reason - too complex).
There is some kvm-based alternative which IIRC was called by dosemu authors
as "too slow", and so they started to use a jit-compiler. Wine have started
to use dosbox for the DOS progs AFAIK. So both projects have a work-arounds
to this limitation with which they are happy, and so it probably not worth
the re-visiting.

2. espfix64.
Its there since 3.16, but dosemu have lots of work-arounds in its code.
The iret trampoline, for example, uses the carefully aligned stack page,
where the high word of ESP is zero.
Another part of the work-around is in a sighandler to decode the
instruction to figure out what register caused a fault (corrupted esp
value usually goes into ebp first, then to other regs) and zero out
the high word of that, plus the high word of esp. There are also other
bits of the work-around spread around the dosemu code, and I am surprised
it actually even works!

3. SS problem. Was fixed in some versions of 4.1; not fixed any more. ;)
dosemu did a glorious iret work-around.

4. FS problem.
Worked around by autoconf checks to ban some gcc options, plus some
special care when accessing thread-local vars in a sighandler.
While your suggestion is to write an asm handlers, to the date I don't
think anyone did that. It is easier to work-around it by other means.
Maybe if you show an example of such handler, the things will change,
but it is simpler to just wait for a kernel fix IMHO.

This is what I called a 32/16bit support, and in fact, when I installed
dosemu on a 64bit machine, started win31 and it just worked, I
immediately wrote my regards to Bart Oldeman, so much I was impressed -
I thought it is absolutely impossible to make this whole mess working
reliably.
I guess wine authors just were not as brave and decided to wait for
the kernel functionality in place.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

19.08.2015 01:47, Andy Lutomirski пишет:
> On Mon, Aug 17, 2015 at 11:19 PM, Stas Sergeev  wrote:
>> 14.08.2015 04:37, Andy Lutomirski пишет:
>>
>>> On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev  wrote:

 14.08.2015 04:21, Andy Lutomirski пишет:

> On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev  wrote:
>>
>> 14.08.2015 03:27, Linus Torvalds пишет:
>>>
>>> On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev  wrote:

 For example because you can as well do:
 prctl(ARCH_SET_SIGNAL_SS, 0)
 which will mean "restore ss in sighandler to its current value",
>>>
>>> I really think a prctl() is the wrong thing to do.
>>>
>>> If you want a signal handler to save/restore segments, I think it
>>> should be a SA_xyz flag to sigaction() (the way we have SA_RESTART
>>
>> Yes, I was proposing the new sigaction() flag in this thread
>> already too. But at the end, prctl() looks better to me because
>> it allows to pass the TLS value to use when restoring FS.
>> The thing is that I am trying to find the similar treatment for
>> both the SS and FS problems. If you don't think they need a
>> similar treatment, then perhaps the Andy's patch is enough.
>>
>>> etc).  And off by default because of the obvious compatibility issues.
>>
>> Of course.
>>
>> So, what we have right now (in the latest Andy's patch) is:
>> 1. lar heuristics
>> 2. new uc_flags flag
>>
>> What it solves: dosemu's regression.
>>
>> What prctl() can give:
>> - fix to dosemu's regression
>> - fix to the TLS problem in the future
>> - no hack and heuristics
>>
>> With SA_xyz you can only solve the SS problem, so it is
>> probably not any better than the uc_flags things coded
>> up by Andy.
>
> I'm leaning slightly toward LAR heuristic + SA_SAVE_SS.

 Stop right here, doesn't the SA_xyz allow to avoid the
 lar heuristic? Why would you still need the lar heuristic then?
 Just call it SA_RESTORE_SS instead of SA_SAVE_SS, and
 the lar heuristic is gone.
>>>
>>> The LAR heuristic is about five lines of code, and it makes signal
>>> delivery more reliable.
>>
>> Why more reliable? In what case?
>>
>>>Sure, we could gate the "regs->ss =
>>> __USER_DS" line on a flag, but why?
>>
>> A few things I can think of why:
>> - nested signals (usual for dosemu)
> 
> What's the issue with nested signals?
If nested signal is async and SS is from LDT just freed, then
the nested signal will silently change the SS value. So if you
are saving it somewhere, you'll save it by luck.
Now this is unlikely to happen, as the async signals in dosemu
are all blocked inside any sighandler. So the siglongjmp() case
is more expressive: if dosemu jumped via siglongjmp() and as such
unblocked the async signals, it will likely want to save its
registers before doing a new switch. Now, since SS is invalid
and will be therefore changed by a sighandler, what it will save
depends on a luck.
Not that dosemu uses siglongjmp() right now, but I am just asking
to please not implement the unreliable interfaces _if possible_.

>> - using siglongjmp() to return to dosemu (rather than to DOS code)
>> Both cases look very scare when using SS from just freed LDT entry.
>> How would you even justify and changelog the patch that adds a lar
>> heuristic code that no one uses or wants? Since SA_hyz flag allows
>> you to do without, why not to just keep things safe and simple?
> 
> The LAR heuristic is just for compatibility.
> 
> ISTM what DOSEMU should want (on new kernels, anyway) is the ability
> to save and restore SS just like any other register, which is what my
> patch did.  The issue is that it broke old DOSEMU.  I want to find a
> way to keep old DOSEMU working while making things work better for new
> code that's aware of new behavior.  That means we want some way
> (opt-in or magically compatible with old DOSEMU) to get SS saved and
> restored.
> 
> Incidentally, I tried implementing the sigaction flag approach.  I
> think it's no good.  When we return from a signal, there's no concept
> of sigaction -- it's just sigreturn.  Sigreturn can't look up the
> sigaction flags -- what if the signal handler calls sigaction itself.
How about the SA_hyz flag that does the following:
- Saves SS into sigcontext
- Forces SS to USER_DS on signal delivery
- Sets the uc_flags flag for sigreturn() to take care of the rest.
You'll have both the control on every bit of action, and a simple
detection logic: if SA_hyz didn't set the uc flag - it didn't work.
You can even employ your lar heuristic here for the case when the
aforementioned SA_hyz is not set. But please, please not when it is
set! In fact, I wonder if you had in mind exactly that: using the
lar heuristic only if the SA_hyz is not set. If so - I misunderstood.
Just please don't add it when it is set.

> So we either need a per-task flag, a per-sighand 

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Wed, Aug 19, 2015 at 3:10 AM, Stas Sergeev s...@list.ru wrote:
 19.08.2015 01:42, Andy Lutomirski пишет:
 What do you mean lack of proper 32/16 bit support?
 At least the following:

 1. vm86().
 There was a patch:
 http://v86-64.sourceforge.net/
 Afaik rejected by Andi Kleen (likely for a good reason - too complex).
 There is some kvm-based alternative which IIRC was called by dosemu authors
 as too slow, and so they started to use a jit-compiler. Wine have started
 to use dosbox for the DOS progs AFAIK. So both projects have a work-arounds
 to this limitation with which they are happy, and so it probably not worth
 the re-visiting.


Wow!

Yeah, that's quite a hack.  EFI mixed mode support used to play
similar tricks.  Unfortunately, switching in and out of long mode at
runtime works very poorly and has terrible interactions with perf, so
EFI stopped doing that.

 2. espfix64.
 Its there since 3.16, but dosemu have lots of work-arounds in its code.
 The iret trampoline, for example, uses the carefully aligned stack page,
 where the high word of ESP is zero.
 Another part of the work-around is in a sighandler to decode the
 instruction to figure out what register caused a fault (corrupted esp
 value usually goes into ebp first, then to other regs) and zero out
 the high word of that, plus the high word of esp. There are also other
 bits of the work-around spread around the dosemu code, and I am surprised
 it actually even works!

Wow, no kidding!  At least this is fixed now.


 3. SS problem. Was fixed in some versions of 4.1; not fixed any more. ;)
 dosemu did a glorious iret work-around.

 4. FS problem.
 Worked around by autoconf checks to ban some gcc options, plus some
 special care when accessing thread-local vars in a sighandler.
 While your suggestion is to write an asm handlers, to the date I don't
 think anyone did that. It is easier to work-around it by other means.
 Maybe if you show an example of such handler, the things will change,
 but it is simpler to just wait for a kernel fix IMHO.


Something like:

mov $__NR_arch_prctl, %rax
mov $ARCH_GET_FS, %rdi
mov [wherever you safe fsbase], %rsi
syscall
mov $ARCH_SET_FS, %rdi
mov (wherever you stashed glibc's value), %rsi
syscall
pushq $0
call real_signal_handler
popq %rax
mov $__NR_arch_prctl, %rax
mov $ARCH_SET_FS, %rdi
mov (saved value), %rsi
syscall
ret

Yeah, it's ugly.  It may very well be worth changing this once the
FSBASE stuff happens.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev s...@list.ru wrote:
 19.08.2015 01:47, Andy Lutomirski пишет:
 On Mon, Aug 17, 2015 at 11:19 PM, Stas Sergeev s...@list.ru wrote:
 14.08.2015 04:37, Andy Lutomirski пишет:

 On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev s...@list.ru wrote:

 14.08.2015 04:21, Andy Lutomirski пишет:

 On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev s...@list.ru wrote:

 14.08.2015 03:27, Linus Torvalds пишет:

 On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev s...@list.ru wrote:

 For example because you can as well do:
 prctl(ARCH_SET_SIGNAL_SS, 0)
 which will mean restore ss in sighandler to its current value,

 I really think a prctl() is the wrong thing to do.

 If you want a signal handler to save/restore segments, I think it
 should be a SA_xyz flag to sigaction() (the way we have SA_RESTART

 Yes, I was proposing the new sigaction() flag in this thread
 already too. But at the end, prctl() looks better to me because
 it allows to pass the TLS value to use when restoring FS.
 The thing is that I am trying to find the similar treatment for
 both the SS and FS problems. If you don't think they need a
 similar treatment, then perhaps the Andy's patch is enough.

 etc).  And off by default because of the obvious compatibility issues.

 Of course.

 So, what we have right now (in the latest Andy's patch) is:
 1. lar heuristics
 2. new uc_flags flag

 What it solves: dosemu's regression.

 What prctl() can give:
 - fix to dosemu's regression
 - fix to the TLS problem in the future
 - no hack and heuristics

 With SA_xyz you can only solve the SS problem, so it is
 probably not any better than the uc_flags things coded
 up by Andy.

 I'm leaning slightly toward LAR heuristic + SA_SAVE_SS.

 Stop right here, doesn't the SA_xyz allow to avoid the
 lar heuristic? Why would you still need the lar heuristic then?
 Just call it SA_RESTORE_SS instead of SA_SAVE_SS, and
 the lar heuristic is gone.

 The LAR heuristic is about five lines of code, and it makes signal
 delivery more reliable.

 Why more reliable? In what case?

Sure, we could gate the regs-ss =
 __USER_DS line on a flag, but why?

 A few things I can think of why:
 - nested signals (usual for dosemu)

 What's the issue with nested signals?
 If nested signal is async and SS is from LDT just freed, then
 the nested signal will silently change the SS value. So if you
 are saving it somewhere, you'll save it by luck.
 Now this is unlikely to happen, as the async signals in dosemu
 are all blocked inside any sighandler. So the siglongjmp() case
 is more expressive: if dosemu jumped via siglongjmp() and as such
 unblocked the async signals, it will likely want to save its
 registers before doing a new switch. Now, since SS is invalid
 and will be therefore changed by a sighandler, what it will save
 depends on a luck.
 Not that dosemu uses siglongjmp() right now, but I am just asking
 to please not implement the unreliable interfaces _if possible_.

Ok, I think I get it.

I'm not proposing the LAR thing as something that anyone should
intentionally use going forward.  It would only be for compatbility
with old code if needed.  We certainly should save SS somewhere.

 Incidentally, I tried implementing the sigaction flag approach.  I
 think it's no good.  When we return from a signal, there's no concept
 of sigaction -- it's just sigreturn.  Sigreturn can't look up the
 sigaction flags -- what if the signal handler calls sigaction itself.
 How about the SA_hyz flag that does the following:
 - Saves SS into sigcontext
 - Forces SS to USER_DS on signal delivery
 - Sets the uc_flags flag for sigreturn() to take care of the rest.
 You'll have both the control on every bit of action, and a simple
 detection logic: if SA_hyz didn't set the uc flag - it didn't work.
 You can even employ your lar heuristic here for the case when the
 aforementioned SA_hyz is not set. But please, please not when it is
 set! In fact, I wonder if you had in mind exactly that: using the
 lar heuristic only if the SA_hyz is not set. If so - I misunderstood.
 Just please don't add it when it is set.

Hmm, interesting.  Maybe that would work for everything.  How's this
to make it concrete?

Add a sigaction flag SA_RESTORE_SS.

On signal delivery, always save SS into sigcontext-ss. if
SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS
and set UC_RESTORE_SS.  If SA_RESTORE_SS is clear, then leave HW SS
alone (i.e. preserve the old behavior).

On signal return, if UC_RESTORE_SS is set, then restore
sigcontext-ss.  If not, then set SS to __USER_DS (as old kernels
did).

This should change nothing at all (except the initial value of
sigcontext-ss / __pad0) on old kernels.


 So we either need a per-task flag, a per-sighand flag, or a sigcontext
 flag indicating what we should do.

 (Yes, I suspect we really might want some way to get FS, GS, and their
 bases saved and restored, but I still think we should do that
 separately.)
 In fact, I have 

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

19.08.2015 18:46, Andy Lutomirski пишет:
 On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev s...@list.ru wrote:
 Incidentally, I tried implementing the sigaction flag approach.  I
 think it's no good.  When we return from a signal, there's no concept
 of sigaction -- it's just sigreturn.  Sigreturn can't look up the
 sigaction flags -- what if the signal handler calls sigaction itself.
 How about the SA_hyz flag that does the following:
 - Saves SS into sigcontext
 - Forces SS to USER_DS on signal delivery
 - Sets the uc_flags flag for sigreturn() to take care of the rest.
 You'll have both the control on every bit of action, and a simple
 detection logic: if SA_hyz didn't set the uc flag - it didn't work.
 You can even employ your lar heuristic here for the case when the
 aforementioned SA_hyz is not set. But please, please not when it is
 set! In fact, I wonder if you had in mind exactly that: using the
 lar heuristic only if the SA_hyz is not set. If so - I misunderstood.
 Just please don't add it when it is set.
 
 Hmm, interesting.  Maybe that would work for everything.  How's this
 to make it concrete?
 
 Add a sigaction flag SA_RESTORE_SS.
 
 On signal delivery, always save SS into sigcontext-ss. if
 SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS
 and set UC_RESTORE_SS.  If SA_RESTORE_SS is clear, then leave HW SS
 alone (i.e. preserve the old behavior).
Either that, or employ the lar heuristic for the not set case
(I think its not needed).

 On signal return, if UC_RESTORE_SS is set, then restore
 sigcontext-ss.  If not, then set SS to __USER_DS (as old kernels
 did).
 
 This should change nothing at all (except the initial value of
 sigcontext-ss / __pad0) on old kernels.
Agreed.

 So we either need a per-task flag, a per-sighand flag, or a sigcontext
 flag indicating what we should do.

 (Yes, I suspect we really might want some way to get FS, GS, and their
 bases saved and restored, but I still think we should do that
 separately.)
 In fact, I have already convinced myself that SA_hyz can take
 care of both cases. :) Maybe you'll just need to extend the struct sigaction
 to pass the TLS address, but this doesn't look absolutely impossible...
 
 I think that should be a separate SA_ flag down the road,
Of course separate.
I only wanted to get a somewhat similar solution, so if the
TLS case can also be covered by the (different) SA_ flag (plus
perhaps a struct sigaction extension), then its just excellent.
What I was afraid of is to get an SS-specific fix, like your
initial uc_flags+lar_heuristic solution. Such fix can't be
extended to the TLS case, reducing the chances for the TLS case
to be ever re-visited.

 Also, it occurs to me that FS and GS could become more complicated.
 There are some proposals to allow tasks to opt in to having a per-cpu
 GS.  If that happens, then figuring out how it would interact with
 signals could be complicated.
Is this a problem?
At least on 86_64, according to this:
http://wiki.osdev.org/Thread_Local_Storage#x86-64
we only need FS.
In any case, since what you say about GS is optional and should
be explicitly requested by the task, it can just disable the use
of the new SA_TLS flag, making the sigaction() to return error for
example. I think the amount of the supported combinations should
be limited by the practical needs, and I don't think someone will
need per-cpu GS with sighandler re-setting it to something non-per-cpu.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

19.08.2015 01:47, Andy Lutomirski пишет:
 On Mon, Aug 17, 2015 at 11:19 PM, Stas Sergeev s...@list.ru wrote:
 14.08.2015 04:37, Andy Lutomirski пишет:

 On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev s...@list.ru wrote:

 14.08.2015 04:21, Andy Lutomirski пишет:

 On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev s...@list.ru wrote:

 14.08.2015 03:27, Linus Torvalds пишет:

 On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev s...@list.ru wrote:

 For example because you can as well do:
 prctl(ARCH_SET_SIGNAL_SS, 0)
 which will mean restore ss in sighandler to its current value,

 I really think a prctl() is the wrong thing to do.

 If you want a signal handler to save/restore segments, I think it
 should be a SA_xyz flag to sigaction() (the way we have SA_RESTART

 Yes, I was proposing the new sigaction() flag in this thread
 already too. But at the end, prctl() looks better to me because
 it allows to pass the TLS value to use when restoring FS.
 The thing is that I am trying to find the similar treatment for
 both the SS and FS problems. If you don't think they need a
 similar treatment, then perhaps the Andy's patch is enough.

 etc).  And off by default because of the obvious compatibility issues.

 Of course.

 So, what we have right now (in the latest Andy's patch) is:
 1. lar heuristics
 2. new uc_flags flag

 What it solves: dosemu's regression.

 What prctl() can give:
 - fix to dosemu's regression
 - fix to the TLS problem in the future
 - no hack and heuristics

 With SA_xyz you can only solve the SS problem, so it is
 probably not any better than the uc_flags things coded
 up by Andy.

 I'm leaning slightly toward LAR heuristic + SA_SAVE_SS.

 Stop right here, doesn't the SA_xyz allow to avoid the
 lar heuristic? Why would you still need the lar heuristic then?
 Just call it SA_RESTORE_SS instead of SA_SAVE_SS, and
 the lar heuristic is gone.

 The LAR heuristic is about five lines of code, and it makes signal
 delivery more reliable.

 Why more reliable? In what case?

Sure, we could gate the regs-ss =
 __USER_DS line on a flag, but why?

 A few things I can think of why:
 - nested signals (usual for dosemu)
 
 What's the issue with nested signals?
If nested signal is async and SS is from LDT just freed, then
the nested signal will silently change the SS value. So if you
are saving it somewhere, you'll save it by luck.
Now this is unlikely to happen, as the async signals in dosemu
are all blocked inside any sighandler. So the siglongjmp() case
is more expressive: if dosemu jumped via siglongjmp() and as such
unblocked the async signals, it will likely want to save its
registers before doing a new switch. Now, since SS is invalid
and will be therefore changed by a sighandler, what it will save
depends on a luck.
Not that dosemu uses siglongjmp() right now, but I am just asking
to please not implement the unreliable interfaces _if possible_.

 - using siglongjmp() to return to dosemu (rather than to DOS code)
 Both cases look very scare when using SS from just freed LDT entry.
 How would you even justify and changelog the patch that adds a lar
 heuristic code that no one uses or wants? Since SA_hyz flag allows
 you to do without, why not to just keep things safe and simple?
 
 The LAR heuristic is just for compatibility.
 
 ISTM what DOSEMU should want (on new kernels, anyway) is the ability
 to save and restore SS just like any other register, which is what my
 patch did.  The issue is that it broke old DOSEMU.  I want to find a
 way to keep old DOSEMU working while making things work better for new
 code that's aware of new behavior.  That means we want some way
 (opt-in or magically compatible with old DOSEMU) to get SS saved and
 restored.
 
 Incidentally, I tried implementing the sigaction flag approach.  I
 think it's no good.  When we return from a signal, there's no concept
 of sigaction -- it's just sigreturn.  Sigreturn can't look up the
 sigaction flags -- what if the signal handler calls sigaction itself.
How about the SA_hyz flag that does the following:
- Saves SS into sigcontext
- Forces SS to USER_DS on signal delivery
- Sets the uc_flags flag for sigreturn() to take care of the rest.
You'll have both the control on every bit of action, and a simple
detection logic: if SA_hyz didn't set the uc flag - it didn't work.
You can even employ your lar heuristic here for the case when the
aforementioned SA_hyz is not set. But please, please not when it is
set! In fact, I wonder if you had in mind exactly that: using the
lar heuristic only if the SA_hyz is not set. If so - I misunderstood.
Just please don't add it when it is set.

 So we either need a per-task flag, a per-sighand flag, or a sigcontext
 flag indicating what we should do.
 
 (Yes, I suspect we really might want some way to get FS, GS, and their
 bases saved and restored, but I still think we should do that
 separately.)
In fact, I have already convinced myself that SA_hyz can take
care of both cases. :) Maybe you'll just need 

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

19.08.2015 01:42, Andy Lutomirski пишет:
 On Mon, Aug 17, 2015 at 11:29 PM, Stas Sergeev s...@list.ru wrote:
 13.08.2015 20:00, Brian Gerst пишет:

 On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski l...@amacapital.net
 wrote:

 On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds
 torva...@linux-foundation.org wrote:

 On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev s...@list.ru wrote:

 I realize this patch may be good to have in general, but
 breaking userspace without a single warning is a bit
 discouraging. Seems like the old we don't break userspace
 rule have gone.

 That rule hasn't gone anywhere.

 Does a plain revert just fix everything? Because if so, that's the
 right thing to do, and we can just re-visit this later.

 I don't understand why Andy and Ingo are even discussing this. What
 the f*ck, guys?

 I'm trying to fix it without reverting.  If that doesn't work, then we
 revert.  Yesterday, I thought I had a reasonably clean fix, but it
 turned out that it only solved half of the problem.

 If we revert, I think I need to check what will break due to the
 revert.  I need to check at least Wine, and we'll have to do something
 about all the selftests that will start failing.  I also need to check
 CRIU, and IIRC CRIU has started using the new sigcontext SS in new
 versions.

 I don't think Wine will be a problem, at least how it is currently set
 up.  16-bit support is only in the 32-bit build.  The 64-bit build
 only supports Win64 apps, and will call the 32-bit version (installed
 in parallel) to run 32 and 16-bit apps.

 Is this also because of the lack of the proper 32/16bit support in
 a 64bit kernels? If so, dosemu's work-arounds do not look like the
 too bad thing compared to that. :)
 
 What do you mean lack of proper 32/16 bit support?
At least the following:

1. vm86().
There was a patch:
http://v86-64.sourceforge.net/
Afaik rejected by Andi Kleen (likely for a good reason - too complex).
There is some kvm-based alternative which IIRC was called by dosemu authors
as too slow, and so they started to use a jit-compiler. Wine have started
to use dosbox for the DOS progs AFAIK. So both projects have a work-arounds
to this limitation with which they are happy, and so it probably not worth
the re-visiting.

2. espfix64.
Its there since 3.16, but dosemu have lots of work-arounds in its code.
The iret trampoline, for example, uses the carefully aligned stack page,
where the high word of ESP is zero.
Another part of the work-around is in a sighandler to decode the
instruction to figure out what register caused a fault (corrupted esp
value usually goes into ebp first, then to other regs) and zero out
the high word of that, plus the high word of esp. There are also other
bits of the work-around spread around the dosemu code, and I am surprised
it actually even works!

3. SS problem. Was fixed in some versions of 4.1; not fixed any more. ;)
dosemu did a glorious iret work-around.

4. FS problem.
Worked around by autoconf checks to ban some gcc options, plus some
special care when accessing thread-local vars in a sighandler.
While your suggestion is to write an asm handlers, to the date I don't
think anyone did that. It is easier to work-around it by other means.
Maybe if you show an example of such handler, the things will change,
but it is simpler to just wait for a kernel fix IMHO.

This is what I called a 32/16bit support, and in fact, when I installed
dosemu on a 64bit machine, started win31 and it just worked, I
immediately wrote my regards to Bart Oldeman, so much I was impressed -
I thought it is absolutely impossible to make this whole mess working
reliably.
I guess wine authors just were not as brave and decided to wait for
the kernel functionality in place.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Mon, Aug 17, 2015 at 11:19 PM, Stas Sergeev  wrote:
> 14.08.2015 04:37, Andy Lutomirski пишет:
>
>> On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev  wrote:
>>>
>>> 14.08.2015 04:21, Andy Lutomirski пишет:
>>>
 On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev  wrote:
>
> 14.08.2015 03:27, Linus Torvalds пишет:
>>
>> On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev  wrote:
>>>
>>> For example because you can as well do:
>>> prctl(ARCH_SET_SIGNAL_SS, 0)
>>> which will mean "restore ss in sighandler to its current value",
>>
>> I really think a prctl() is the wrong thing to do.
>>
>> If you want a signal handler to save/restore segments, I think it
>> should be a SA_xyz flag to sigaction() (the way we have SA_RESTART
>
> Yes, I was proposing the new sigaction() flag in this thread
> already too. But at the end, prctl() looks better to me because
> it allows to pass the TLS value to use when restoring FS.
> The thing is that I am trying to find the similar treatment for
> both the SS and FS problems. If you don't think they need a
> similar treatment, then perhaps the Andy's patch is enough.
>
>> etc).  And off by default because of the obvious compatibility issues.
>
> Of course.
>
> So, what we have right now (in the latest Andy's patch) is:
> 1. lar heuristics
> 2. new uc_flags flag
>
> What it solves: dosemu's regression.
>
> What prctl() can give:
> - fix to dosemu's regression
> - fix to the TLS problem in the future
> - no hack and heuristics
>
> With SA_xyz you can only solve the SS problem, so it is
> probably not any better than the uc_flags things coded
> up by Andy.

 I'm leaning slightly toward LAR heuristic + SA_SAVE_SS.
>>>
>>> Stop right here, doesn't the SA_xyz allow to avoid the
>>> lar heuristic? Why would you still need the lar heuristic then?
>>> Just call it SA_RESTORE_SS instead of SA_SAVE_SS, and
>>> the lar heuristic is gone.
>>
>> The LAR heuristic is about five lines of code, and it makes signal
>> delivery more reliable.
>
> Why more reliable? In what case?
>
>>Sure, we could gate the "regs->ss =
>> __USER_DS" line on a flag, but why?
>
> A few things I can think of why:
> - nested signals (usual for dosemu)

What's the issue with nested signals?

> - using siglongjmp() to return to dosemu (rather than to DOS code)
> Both cases look very scare when using SS from just freed LDT entry.
> How would you even justify and changelog the patch that adds a lar
> heuristic code that no one uses or wants? Since SA_hyz flag allows
> you to do without, why not to just keep things safe and simple?

The LAR heuristic is just for compatibility.

ISTM what DOSEMU should want (on new kernels, anyway) is the ability
to save and restore SS just like any other register, which is what my
patch did.  The issue is that it broke old DOSEMU.  I want to find a
way to keep old DOSEMU working while making things work better for new
code that's aware of new behavior.  That means we want some way
(opt-in or magically compatible with old DOSEMU) to get SS saved and
restored.

Incidentally, I tried implementing the sigaction flag approach.  I
think it's no good.  When we return from a signal, there's no concept
of sigaction -- it's just sigreturn.  Sigreturn can't look up the
sigaction flags -- what if the signal handler calls sigaction itself.
So we either need a per-task flag, a per-sighand flag, or a sigcontext
flag indicating what we should do.

(Yes, I suspect we really might want some way to get FS, GS, and their
bases saved and restored, but I still think we should do that
separately.)

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Mon, Aug 17, 2015 at 11:29 PM, Stas Sergeev  wrote:
> 13.08.2015 20:00, Brian Gerst пишет:
>
>> On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski 
>> wrote:
>>>
>>> On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds
>>>  wrote:

 On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev  wrote:
>
> I realize this patch may be good to have in general, but
> breaking userspace without a single warning is a bit
> discouraging. Seems like the old "we don't break userspace"
> rule have gone.

 That rule hasn't gone anywhere.

 Does a plain revert just fix everything? Because if so, that's the
 right thing to do, and we can just re-visit this later.

 I don't understand why Andy and Ingo are even discussing this. What
 the f*ck, guys?

>>> I'm trying to fix it without reverting.  If that doesn't work, then we
>>> revert.  Yesterday, I thought I had a reasonably clean fix, but it
>>> turned out that it only solved half of the problem.
>>>
>>> If we revert, I think I need to check what will break due to the
>>> revert.  I need to check at least Wine, and we'll have to do something
>>> about all the selftests that will start failing.  I also need to check
>>> CRIU, and IIRC CRIU has started using the new sigcontext SS in new
>>> versions.
>>
>> I don't think Wine will be a problem, at least how it is currently set
>> up.  16-bit support is only in the 32-bit build.  The 64-bit build
>> only supports Win64 apps, and will call the 32-bit version (installed
>> in parallel) to run 32 and 16-bit apps.
>
> Is this also because of the lack of the proper 32/16bit support in
> a 64bit kernels? If so, dosemu's work-arounds do not look like the
> too bad thing compared to that. :)

What do you mean lack of proper 32/16 bit support?

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

13.08.2015 23:07, Linus Torvalds пишет:

On Thu, Aug 13, 2015 at 12:59 PM, Stas Sergeev  wrote:

It doesn't: fedora provides a "sanitized up" version of sigcontext.h
in /usr/include/bits, which comes from glibc-headers-2.21-7.fc22.x86_64.
So it seems the "sanitized up" headers come from glibc, which
means all other distros would have that too.

Yes. Except the whole point of uapi was that in the long term the
glibc people should just be able to pick up the kernel ones directly.

And while that may involve some further editing, it sure as hell
shouldn't involve "oh, I know, this got renamed, so now I have to
rename it back". That would be crazy.

Of course they shouldn't rename back, but the breakage in
this case will be seen only to the upstream authors and the
distributors who compile the package, but never to the end-user.
They'll just quickly release the update without troubling the user.
This way kernel could force the uapi changes without too
much troubles, and, for example, when it stopped to use
.fs/.fs fields for FS/GS, it could actually reasonably do that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

13.08.2015 20:00, Brian Gerst пишет:

On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski  wrote:

On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds
 wrote:

On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev  wrote:

I realize this patch may be good to have in general, but
breaking userspace without a single warning is a bit
discouraging. Seems like the old "we don't break userspace"
rule have gone.

That rule hasn't gone anywhere.

Does a plain revert just fix everything? Because if so, that's the
right thing to do, and we can just re-visit this later.

I don't understand why Andy and Ingo are even discussing this. What
the f*ck, guys?


I'm trying to fix it without reverting.  If that doesn't work, then we
revert.  Yesterday, I thought I had a reasonably clean fix, but it
turned out that it only solved half of the problem.

If we revert, I think I need to check what will break due to the
revert.  I need to check at least Wine, and we'll have to do something
about all the selftests that will start failing.  I also need to check
CRIU, and IIRC CRIU has started using the new sigcontext SS in new
versions.

I don't think Wine will be a problem, at least how it is currently set
up.  16-bit support is only in the 32-bit build.  The 64-bit build
only supports Win64 apps, and will call the 32-bit version (installed
in parallel) to run 32 and 16-bit apps.

Is this also because of the lack of the proper 32/16bit support in
a 64bit kernels? If so, dosemu's work-arounds do not look like the
too bad thing compared to that. :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

14.08.2015 04:37, Andy Lutomirski пишет:

On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev  wrote:

14.08.2015 04:21, Andy Lutomirski пишет:


On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev  wrote:

14.08.2015 03:27, Linus Torvalds пишет:

On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev  wrote:

For example because you can as well do:
prctl(ARCH_SET_SIGNAL_SS, 0)
which will mean "restore ss in sighandler to its current value",

I really think a prctl() is the wrong thing to do.

If you want a signal handler to save/restore segments, I think it
should be a SA_xyz flag to sigaction() (the way we have SA_RESTART

Yes, I was proposing the new sigaction() flag in this thread
already too. But at the end, prctl() looks better to me because
it allows to pass the TLS value to use when restoring FS.
The thing is that I am trying to find the similar treatment for
both the SS and FS problems. If you don't think they need a
similar treatment, then perhaps the Andy's patch is enough.


etc).  And off by default because of the obvious compatibility issues.

Of course.

So, what we have right now (in the latest Andy's patch) is:
1. lar heuristics
2. new uc_flags flag

What it solves: dosemu's regression.

What prctl() can give:
- fix to dosemu's regression
- fix to the TLS problem in the future
- no hack and heuristics

With SA_xyz you can only solve the SS problem, so it is
probably not any better than the uc_flags things coded
up by Andy.

I'm leaning slightly toward LAR heuristic + SA_SAVE_SS.

Stop right here, doesn't the SA_xyz allow to avoid the
lar heuristic? Why would you still need the lar heuristic then?
Just call it SA_RESTORE_SS instead of SA_SAVE_SS, and
the lar heuristic is gone.

The LAR heuristic is about five lines of code, and it makes signal
delivery more reliable.

Why more reliable? In what case?


   Sure, we could gate the "regs->ss =
__USER_DS" line on a flag, but why?

A few things I can think of why:
- nested signals (usual for dosemu)
- using siglongjmp() to return to dosemu (rather than to DOS code)
Both cases look very scare when using SS from just freed LDT entry.
How would you even justify and changelog the patch that adds a lar
heuristic code that no one uses or wants? Since SA_hyz flag allows
you to do without, why not to just keep things safe and simple?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

13.08.2015 20:00, Brian Gerst пишет:

On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski l...@amacapital.net wrote:

On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds
torva...@linux-foundation.org wrote:

On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev s...@list.ru wrote:

I realize this patch may be good to have in general, but
breaking userspace without a single warning is a bit
discouraging. Seems like the old we don't break userspace
rule have gone.

That rule hasn't gone anywhere.

Does a plain revert just fix everything? Because if so, that's the
right thing to do, and we can just re-visit this later.

I don't understand why Andy and Ingo are even discussing this. What
the f*ck, guys?


I'm trying to fix it without reverting.  If that doesn't work, then we
revert.  Yesterday, I thought I had a reasonably clean fix, but it
turned out that it only solved half of the problem.

If we revert, I think I need to check what will break due to the
revert.  I need to check at least Wine, and we'll have to do something
about all the selftests that will start failing.  I also need to check
CRIU, and IIRC CRIU has started using the new sigcontext SS in new
versions.

I don't think Wine will be a problem, at least how it is currently set
up.  16-bit support is only in the 32-bit build.  The 64-bit build
only supports Win64 apps, and will call the 32-bit version (installed
in parallel) to run 32 and 16-bit apps.

Is this also because of the lack of the proper 32/16bit support in
a 64bit kernels? If so, dosemu's work-arounds do not look like the
too bad thing compared to that. :)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

14.08.2015 04:37, Andy Lutomirski пишет:

On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev s...@list.ru wrote:

14.08.2015 04:21, Andy Lutomirski пишет:


On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev s...@list.ru wrote:

14.08.2015 03:27, Linus Torvalds пишет:

On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev s...@list.ru wrote:

For example because you can as well do:
prctl(ARCH_SET_SIGNAL_SS, 0)
which will mean restore ss in sighandler to its current value,

I really think a prctl() is the wrong thing to do.

If you want a signal handler to save/restore segments, I think it
should be a SA_xyz flag to sigaction() (the way we have SA_RESTART

Yes, I was proposing the new sigaction() flag in this thread
already too. But at the end, prctl() looks better to me because
it allows to pass the TLS value to use when restoring FS.
The thing is that I am trying to find the similar treatment for
both the SS and FS problems. If you don't think they need a
similar treatment, then perhaps the Andy's patch is enough.


etc).  And off by default because of the obvious compatibility issues.

Of course.

So, what we have right now (in the latest Andy's patch) is:
1. lar heuristics
2. new uc_flags flag

What it solves: dosemu's regression.

What prctl() can give:
- fix to dosemu's regression
- fix to the TLS problem in the future
- no hack and heuristics

With SA_xyz you can only solve the SS problem, so it is
probably not any better than the uc_flags things coded
up by Andy.

I'm leaning slightly toward LAR heuristic + SA_SAVE_SS.

Stop right here, doesn't the SA_xyz allow to avoid the
lar heuristic? Why would you still need the lar heuristic then?
Just call it SA_RESTORE_SS instead of SA_SAVE_SS, and
the lar heuristic is gone.

The LAR heuristic is about five lines of code, and it makes signal
delivery more reliable.

Why more reliable? In what case?


   Sure, we could gate the regs-ss =
__USER_DS line on a flag, but why?

A few things I can think of why:
- nested signals (usual for dosemu)
- using siglongjmp() to return to dosemu (rather than to DOS code)
Both cases look very scare when using SS from just freed LDT entry.
How would you even justify and changelog the patch that adds a lar
heuristic code that no one uses or wants? Since SA_hyz flag allows
you to do without, why not to just keep things safe and simple?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

13.08.2015 23:07, Linus Torvalds пишет:

On Thu, Aug 13, 2015 at 12:59 PM, Stas Sergeev s...@list.ru wrote:

It doesn't: fedora provides a sanitized up version of sigcontext.h
in /usr/include/bits, which comes from glibc-headers-2.21-7.fc22.x86_64.
So it seems the sanitized up headers come from glibc, which
means all other distros would have that too.

Yes. Except the whole point of uapi was that in the long term the
glibc people should just be able to pick up the kernel ones directly.

And while that may involve some further editing, it sure as hell
shouldn't involve oh, I know, this got renamed, so now I have to
rename it back. That would be crazy.

Of course they shouldn't rename back, but the breakage in
this case will be seen only to the upstream authors and the
distributors who compile the package, but never to the end-user.
They'll just quickly release the update without troubling the user.
This way kernel could force the uapi changes without too
much troubles, and, for example, when it stopped to use
.fs/.fs fields for FS/GS, it could actually reasonably do that.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Mon, Aug 17, 2015 at 11:19 PM, Stas Sergeev s...@list.ru wrote:
 14.08.2015 04:37, Andy Lutomirski пишет:

 On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev s...@list.ru wrote:

 14.08.2015 04:21, Andy Lutomirski пишет:

 On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev s...@list.ru wrote:

 14.08.2015 03:27, Linus Torvalds пишет:

 On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev s...@list.ru wrote:

 For example because you can as well do:
 prctl(ARCH_SET_SIGNAL_SS, 0)
 which will mean restore ss in sighandler to its current value,

 I really think a prctl() is the wrong thing to do.

 If you want a signal handler to save/restore segments, I think it
 should be a SA_xyz flag to sigaction() (the way we have SA_RESTART

 Yes, I was proposing the new sigaction() flag in this thread
 already too. But at the end, prctl() looks better to me because
 it allows to pass the TLS value to use when restoring FS.
 The thing is that I am trying to find the similar treatment for
 both the SS and FS problems. If you don't think they need a
 similar treatment, then perhaps the Andy's patch is enough.

 etc).  And off by default because of the obvious compatibility issues.

 Of course.

 So, what we have right now (in the latest Andy's patch) is:
 1. lar heuristics
 2. new uc_flags flag

 What it solves: dosemu's regression.

 What prctl() can give:
 - fix to dosemu's regression
 - fix to the TLS problem in the future
 - no hack and heuristics

 With SA_xyz you can only solve the SS problem, so it is
 probably not any better than the uc_flags things coded
 up by Andy.

 I'm leaning slightly toward LAR heuristic + SA_SAVE_SS.

 Stop right here, doesn't the SA_xyz allow to avoid the
 lar heuristic? Why would you still need the lar heuristic then?
 Just call it SA_RESTORE_SS instead of SA_SAVE_SS, and
 the lar heuristic is gone.

 The LAR heuristic is about five lines of code, and it makes signal
 delivery more reliable.

 Why more reliable? In what case?

Sure, we could gate the regs-ss =
 __USER_DS line on a flag, but why?

 A few things I can think of why:
 - nested signals (usual for dosemu)

What's the issue with nested signals?

 - using siglongjmp() to return to dosemu (rather than to DOS code)
 Both cases look very scare when using SS from just freed LDT entry.
 How would you even justify and changelog the patch that adds a lar
 heuristic code that no one uses or wants? Since SA_hyz flag allows
 you to do without, why not to just keep things safe and simple?

The LAR heuristic is just for compatibility.

ISTM what DOSEMU should want (on new kernels, anyway) is the ability
to save and restore SS just like any other register, which is what my
patch did.  The issue is that it broke old DOSEMU.  I want to find a
way to keep old DOSEMU working while making things work better for new
code that's aware of new behavior.  That means we want some way
(opt-in or magically compatible with old DOSEMU) to get SS saved and
restored.

Incidentally, I tried implementing the sigaction flag approach.  I
think it's no good.  When we return from a signal, there's no concept
of sigaction -- it's just sigreturn.  Sigreturn can't look up the
sigaction flags -- what if the signal handler calls sigaction itself.
So we either need a per-task flag, a per-sighand flag, or a sigcontext
flag indicating what we should do.

(Yes, I suspect we really might want some way to get FS, GS, and their
bases saved and restored, but I still think we should do that
separately.)

-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Mon, Aug 17, 2015 at 11:29 PM, Stas Sergeev s...@list.ru wrote:
 13.08.2015 20:00, Brian Gerst пишет:

 On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski l...@amacapital.net
 wrote:

 On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds
 torva...@linux-foundation.org wrote:

 On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev s...@list.ru wrote:

 I realize this patch may be good to have in general, but
 breaking userspace without a single warning is a bit
 discouraging. Seems like the old we don't break userspace
 rule have gone.

 That rule hasn't gone anywhere.

 Does a plain revert just fix everything? Because if so, that's the
 right thing to do, and we can just re-visit this later.

 I don't understand why Andy and Ingo are even discussing this. What
 the f*ck, guys?

 I'm trying to fix it without reverting.  If that doesn't work, then we
 revert.  Yesterday, I thought I had a reasonably clean fix, but it
 turned out that it only solved half of the problem.

 If we revert, I think I need to check what will break due to the
 revert.  I need to check at least Wine, and we'll have to do something
 about all the selftests that will start failing.  I also need to check
 CRIU, and IIRC CRIU has started using the new sigcontext SS in new
 versions.

 I don't think Wine will be a problem, at least how it is currently set
 up.  16-bit support is only in the 32-bit build.  The 64-bit build
 only supports Win64 apps, and will call the 32-bit version (installed
 in parallel) to run 32 and 16-bit apps.

 Is this also because of the lack of the proper 32/16bit support in
 a 64bit kernels? If so, dosemu's work-arounds do not look like the
 too bad thing compared to that. :)

What do you mean lack of proper 32/16 bit support?

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Cyrill Gorcunov]

On Fri, Aug 14, 2015 at 01:02:14PM +0300, Pavel Emelyanov wrote:
...
> > IOW we've been not setting up __pad0 which became ss
> > inside the kernel (in result we've been passing 0 here,
> > which caused the problem).
> > 
> > fwiw, we declare that new criu versions may require new
> > kernels to work but never promised that new criu gonna
> > be compatible with old kernels.
> 
> We did. Kernel 3.11 is still declared as supported (modulo new stuff
> we added after 1.0 might not work, but basic sigframe mgmt is not one
> of those "new" things).

This won't last forever. And I think it's pretty normal to require
a new criu version for new kernel.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Pavel Emelyanov]

On 08/14/2015 10:22 AM, Cyrill Gorcunov wrote:
> On Thu, Aug 13, 2015 at 01:09:47PM -0700, Linus Torvalds wrote:
>> On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov  wrote:
>>>
>>> If only I'm not missin something obvious this should not hurt us.
>>> But I gonna build test kernel and check to be sure tomorrow, ok?
> 
> Managed to test it. And criu works fine with the revert as expected.
> Actually it's because of commit c6f2062935c8 Oleg made us a patch:
> 
>  | commit 07dcf0dbb6ff97c255bc6b06569255a9479bccdd
>  | Author: Oleg Nesterov 
>  | Date:   Thu Mar 19 19:14:00 2015 +0300
>  |
>  | restore/x86: restore_gpregs() needs to initialize ->ss as well
>  |
>  | Before the recent "x86_64,signal: Fix SS handling for signals delivered
>  | to 64-bit programs" kernel patch, sigreturn paths forgot to restore 
> ->ss
>  | after return from the signal handler.
>  |
>  | Now that the kernel was fixed, restore_gpregs() has to initialize ->ss
>  | too, it is no longer ignored.
>  | ...
>  |
>  | +++ b/arch/x86/include/asm/restorer.h
>  | @@ -53,7 +53,7 @@ struct rt_sigcontext {
>  | unsigned short  cs;
>  | unsigned short  gs;
>  | unsigned short  fs;
>  | -   unsigned short  __pad0;
>  | +   unsigned short  ss;
>  | unsigned long   err;
>  | unsigned long   trapno;
>  | unsigned long   oldmask;
> 
> IOW we've been not setting up __pad0 which became ss
> inside the kernel (in result we've been passing 0 here,
> which caused the problem).
> 
> fwiw, we declare that new criu versions may require new
> kernels to work but never promised that new criu gonna
> be compatible with old kernels.

We did. Kernel 3.11 is still declared as supported (modulo new stuff
we added after 1.0 might not work, but basic sigframe mgmt is not one
of those "new" things).

> That said if something
> get changed inside sigcontext structure in future
> we may update criu code as well.
> .
> 

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Cyrill Gorcunov]

On Thu, Aug 13, 2015 at 08:43:24AM -0700, Andy Lutomirski wrote:
...
> >
> > That rule hasn't gone anywhere.
> >
> > Does a plain revert just fix everything? Because if so, that's the
> > right thing to do, and we can just re-visit this later.
> >
> > I don't understand why Andy and Ingo are even discussing this. What
> > the f*ck, guys?
> >
> 
> I'm trying to fix it without reverting.  If that doesn't work, then we
> revert.  Yesterday, I thought I had a reasonably clean fix, but it
> turned out that it only solved half of the problem.
> 
> If we revert, I think I need to check what will break due to the
> revert.  I need to check at least Wine, and we'll have to do something
> about all the selftests that will start failing.  I also need to check
> CRIU, and IIRC CRIU has started using the new sigcontext SS in new
> versions.

Yes, we've tuned up our sigcontext structure and put ss into the place
where previously __pad0 were. After the revert the kernel simply ignores
this field again. But we never did any "weird" gaming over segment registers
for testing purposes, neither we note any application (in containers) which
does some weird things like dosemu.

> 
> And, damnit, those selftests are *useful*.  They've smoked out all
> kinds of problems.  That's part of the reason I'd prefer not to revert
> if there's a better option.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Cyrill Gorcunov]

On Thu, Aug 13, 2015 at 01:09:47PM -0700, Linus Torvalds wrote:
> On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov  wrote:
> >
> > If only I'm not missin something obvious this should not hurt us.
> > But I gonna build test kernel and check to be sure tomorrow, ok?

Managed to test it. And criu works fine with the revert as expected.
Actually it's because of commit c6f2062935c8 Oleg made us a patch:

 | commit 07dcf0dbb6ff97c255bc6b06569255a9479bccdd
 | Author: Oleg Nesterov 
 | Date:   Thu Mar 19 19:14:00 2015 +0300
 |
 | restore/x86: restore_gpregs() needs to initialize ->ss as well
 |
 | Before the recent "x86_64,signal: Fix SS handling for signals delivered
 | to 64-bit programs" kernel patch, sigreturn paths forgot to restore ->ss
 | after return from the signal handler.
 |
 | Now that the kernel was fixed, restore_gpregs() has to initialize ->ss
 | too, it is no longer ignored.
 | ...
 |
 | +++ b/arch/x86/include/asm/restorer.h
 | @@ -53,7 +53,7 @@ struct rt_sigcontext {
 | unsigned short  cs;
 | unsigned short  gs;
 | unsigned short  fs;
 | -   unsigned short  __pad0;
 | +   unsigned short  ss;
 | unsigned long   err;
 | unsigned long   trapno;
 | unsigned long   oldmask;

IOW we've been not setting up __pad0 which became ss
inside the kernel (in result we've been passing 0 here,
which caused the problem).

fwiw, we declare that new criu versions may require new
kernels to work but never promised that new criu gonna
be compatible with old kernels. That said if something
get changed inside sigcontext structure in future
we may update criu code as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Cyrill Gorcunov]

On Thu, Aug 13, 2015 at 01:09:47PM -0700, Linus Torvalds wrote:
 On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
 
  If only I'm not missin something obvious this should not hurt us.
  But I gonna build test kernel and check to be sure tomorrow, ok?

Managed to test it. And criu works fine with the revert as expected.
Actually it's because of commit c6f2062935c8 Oleg made us a patch:

 | commit 07dcf0dbb6ff97c255bc6b06569255a9479bccdd
 | Author: Oleg Nesterov o...@redhat.com
 | Date:   Thu Mar 19 19:14:00 2015 +0300
 |
 | restore/x86: restore_gpregs() needs to initialize -ss as well
 |
 | Before the recent x86_64,signal: Fix SS handling for signals delivered
 | to 64-bit programs kernel patch, sigreturn paths forgot to restore -ss
 | after return from the signal handler.
 |
 | Now that the kernel was fixed, restore_gpregs() has to initialize -ss
 | too, it is no longer ignored.
 | ...
 |
 | +++ b/arch/x86/include/asm/restorer.h
 | @@ -53,7 +53,7 @@ struct rt_sigcontext {
 | unsigned short  cs;
 | unsigned short  gs;
 | unsigned short  fs;
 | -   unsigned short  __pad0;
 | +   unsigned short  ss;
 | unsigned long   err;
 | unsigned long   trapno;
 | unsigned long   oldmask;

IOW we've been not setting up __pad0 which became ss
inside the kernel (in result we've been passing 0 here,
which caused the problem).

fwiw, we declare that new criu versions may require new
kernels to work but never promised that new criu gonna
be compatible with old kernels. That said if something
get changed inside sigcontext structure in future
we may update criu code as well.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Cyrill Gorcunov]

On Thu, Aug 13, 2015 at 08:43:24AM -0700, Andy Lutomirski wrote:
...
 
  That rule hasn't gone anywhere.
 
  Does a plain revert just fix everything? Because if so, that's the
  right thing to do, and we can just re-visit this later.
 
  I don't understand why Andy and Ingo are even discussing this. What
  the f*ck, guys?
 
 
 I'm trying to fix it without reverting.  If that doesn't work, then we
 revert.  Yesterday, I thought I had a reasonably clean fix, but it
 turned out that it only solved half of the problem.
 
 If we revert, I think I need to check what will break due to the
 revert.  I need to check at least Wine, and we'll have to do something
 about all the selftests that will start failing.  I also need to check
 CRIU, and IIRC CRIU has started using the new sigcontext SS in new
 versions.

Yes, we've tuned up our sigcontext structure and put ss into the place
where previously __pad0 were. After the revert the kernel simply ignores
this field again. But we never did any weird gaming over segment registers
for testing purposes, neither we note any application (in containers) which
does some weird things like dosemu.

 
 And, damnit, those selftests are *useful*.  They've smoked out all
 kinds of problems.  That's part of the reason I'd prefer not to revert
 if there's a better option.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Cyrill Gorcunov]

On Fri, Aug 14, 2015 at 01:02:14PM +0300, Pavel Emelyanov wrote:
...
  IOW we've been not setting up __pad0 which became ss
  inside the kernel (in result we've been passing 0 here,
  which caused the problem).
  
  fwiw, we declare that new criu versions may require new
  kernels to work but never promised that new criu gonna
  be compatible with old kernels.
 
 We did. Kernel 3.11 is still declared as supported (modulo new stuff
 we added after 1.0 might not work, but basic sigframe mgmt is not one
 of those new things).

This won't last forever. And I think it's pretty normal to require
a new criu version for new kernel.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Pavel Emelyanov]

On 08/14/2015 10:22 AM, Cyrill Gorcunov wrote:
 On Thu, Aug 13, 2015 at 01:09:47PM -0700, Linus Torvalds wrote:
 On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:

 If only I'm not missin something obvious this should not hurt us.
 But I gonna build test kernel and check to be sure tomorrow, ok?
 
 Managed to test it. And criu works fine with the revert as expected.
 Actually it's because of commit c6f2062935c8 Oleg made us a patch:
 
  | commit 07dcf0dbb6ff97c255bc6b06569255a9479bccdd
  | Author: Oleg Nesterov o...@redhat.com
  | Date:   Thu Mar 19 19:14:00 2015 +0300
  |
  | restore/x86: restore_gpregs() needs to initialize -ss as well
  |
  | Before the recent x86_64,signal: Fix SS handling for signals delivered
  | to 64-bit programs kernel patch, sigreturn paths forgot to restore 
 -ss
  | after return from the signal handler.
  |
  | Now that the kernel was fixed, restore_gpregs() has to initialize -ss
  | too, it is no longer ignored.
  | ...
  |
  | +++ b/arch/x86/include/asm/restorer.h
  | @@ -53,7 +53,7 @@ struct rt_sigcontext {
  | unsigned short  cs;
  | unsigned short  gs;
  | unsigned short  fs;
  | -   unsigned short  __pad0;
  | +   unsigned short  ss;
  | unsigned long   err;
  | unsigned long   trapno;
  | unsigned long   oldmask;
 
 IOW we've been not setting up __pad0 which became ss
 inside the kernel (in result we've been passing 0 here,
 which caused the problem).
 
 fwiw, we declare that new criu versions may require new
 kernels to work but never promised that new criu gonna
 be compatible with old kernels.

We did. Kernel 3.11 is still declared as supported (modulo new stuff
we added after 1.0 might not work, but basic sigframe mgmt is not one
of those new things).

 That said if something
 get changed inside sigcontext structure in future
 we may update criu code as well.
 .
 

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

14.08.2015 04:37, Andy Lutomirski пишет:

On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev  wrote:

14.08.2015 04:21, Andy Lutomirski пишет:


On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev  wrote:

14.08.2015 03:27, Linus Torvalds пишет:

On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev  wrote:

For example because you can as well do:
prctl(ARCH_SET_SIGNAL_SS, 0)
which will mean "restore ss in sighandler to its current value",

I really think a prctl() is the wrong thing to do.

If you want a signal handler to save/restore segments, I think it
should be a SA_xyz flag to sigaction() (the way we have SA_RESTART

Yes, I was proposing the new sigaction() flag in this thread
already too. But at the end, prctl() looks better to me because
it allows to pass the TLS value to use when restoring FS.
The thing is that I am trying to find the similar treatment for
both the SS and FS problems. If you don't think they need a
similar treatment, then perhaps the Andy's patch is enough.


etc).  And off by default because of the obvious compatibility issues.

Of course.

So, what we have right now (in the latest Andy's patch) is:
1. lar heuristics
2. new uc_flags flag

What it solves: dosemu's regression.

What prctl() can give:
- fix to dosemu's regression
- fix to the TLS problem in the future
- no hack and heuristics

With SA_xyz you can only solve the SS problem, so it is
probably not any better than the uc_flags things coded
up by Andy.

I'm leaning slightly toward LAR heuristic + SA_SAVE_SS.

Stop right here, doesn't the SA_xyz allow to avoid the
lar heuristic? Why would you still need the lar heuristic then?
Just call it SA_RESTORE_SS instead of SA_SAVE_SS, and
the lar heuristic is gone.

The LAR heuristic is about five lines of code, and it makes signal
delivery more reliable.  Sure, we could gate the "regs->ss =
__USER_DS" line on a flag, but why?

Speed?
I'll let others decide on that.
My vote is to no heuristic if possible, and keeping the FS
problem in mind if possible (obviously, both are possible).


Unfortunately, I don't think we were clever enough to allow this to be
probed easily -- we silently ignore unrecognized sa_flags bits.

Big deal, check the kversion. :)

Not so good.  For example, if you made your DOSEMU patch to use the
saved SS check the version, then the backported revert would break
you.

I would be scared to imagine the program that probes
for everything, adding more and more probes with years,
instead of just saying "you need kernel version at least x.y.z".
If some functionality is reverted, another kversion check
can be added. This all is not new: dosemu's protected mode
implementation doesn't work on many kernels selectively.
IIRC it didn't work on 3.14 because the 16bit LDTs were
disallowed, and other versions had problems too. It is easier
to ban such kernels by versions instead of adding a run-time
probes, because you don't know beforehand what will break
in the next kernel to add a probe in advance, and when you
react to an existing breakage, it already doesn't matter.
The possibly of reverting a new functionality is similar to
getting a breakage in an existing functionality (or even have
lower probability), so I see no reason to choose different
treatments for these two.
But of course every author has own habits.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev  wrote:
> 14.08.2015 04:21, Andy Lutomirski пишет:
>
>> On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev  wrote:
>>>
>>> 14.08.2015 03:27, Linus Torvalds пишет:

 On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev  wrote:
>
> For example because you can as well do:
> prctl(ARCH_SET_SIGNAL_SS, 0)
> which will mean "restore ss in sighandler to its current value",

 I really think a prctl() is the wrong thing to do.

 If you want a signal handler to save/restore segments, I think it
 should be a SA_xyz flag to sigaction() (the way we have SA_RESTART
>>>
>>> Yes, I was proposing the new sigaction() flag in this thread
>>> already too. But at the end, prctl() looks better to me because
>>> it allows to pass the TLS value to use when restoring FS.
>>> The thing is that I am trying to find the similar treatment for
>>> both the SS and FS problems. If you don't think they need a
>>> similar treatment, then perhaps the Andy's patch is enough.
>>>
 etc).  And off by default because of the obvious compatibility issues.
>>>
>>> Of course.
>>>
>>> So, what we have right now (in the latest Andy's patch) is:
>>> 1. lar heuristics
>>> 2. new uc_flags flag
>>>
>>> What it solves: dosemu's regression.
>>>
>>> What prctl() can give:
>>> - fix to dosemu's regression
>>> - fix to the TLS problem in the future
>>> - no hack and heuristics
>>>
>>> With SA_xyz you can only solve the SS problem, so it is
>>> probably not any better than the uc_flags things coded
>>> up by Andy.
>>
>> I'm leaning slightly toward LAR heuristic + SA_SAVE_SS.
>
> Stop right here, doesn't the SA_xyz allow to avoid the
> lar heuristic? Why would you still need the lar heuristic then?
> Just call it SA_RESTORE_SS instead of SA_SAVE_SS, and
> the lar heuristic is gone.

The LAR heuristic is about five lines of code, and it makes signal
delivery more reliable.  Sure, we could gate the "regs->ss =
__USER_DS" line on a flag, but why?

>
>> Unfortunately, I don't think we were clever enough to allow this to be
>> probed easily -- we silently ignore unrecognized sa_flags bits.
>
> Big deal, check the kversion. :)

Not so good.  For example, if you made your DOSEMU patch to use the
saved SS check the version, then the backported revert would break
you.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

14.08.2015 04:21, Andy Lutomirski пишет:

On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev  wrote:

14.08.2015 03:27, Linus Torvalds пишет:

On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev  wrote:

For example because you can as well do:
prctl(ARCH_SET_SIGNAL_SS, 0)
which will mean "restore ss in sighandler to its current value",

I really think a prctl() is the wrong thing to do.

If you want a signal handler to save/restore segments, I think it
should be a SA_xyz flag to sigaction() (the way we have SA_RESTART

Yes, I was proposing the new sigaction() flag in this thread
already too. But at the end, prctl() looks better to me because
it allows to pass the TLS value to use when restoring FS.
The thing is that I am trying to find the similar treatment for
both the SS and FS problems. If you don't think they need a
similar treatment, then perhaps the Andy's patch is enough.


etc).  And off by default because of the obvious compatibility issues.

Of course.

So, what we have right now (in the latest Andy's patch) is:
1. lar heuristics
2. new uc_flags flag

What it solves: dosemu's regression.

What prctl() can give:
- fix to dosemu's regression
- fix to the TLS problem in the future
- no hack and heuristics

With SA_xyz you can only solve the SS problem, so it is
probably not any better than the uc_flags things coded
up by Andy.

I'm leaning slightly toward LAR heuristic + SA_SAVE_SS.

Stop right here, doesn't the SA_xyz allow to avoid the
lar heuristic? Why would you still need the lar heuristic then?
Just call it SA_RESTORE_SS instead of SA_SAVE_SS, and
the lar heuristic is gone.


Unfortunately, I don't think we were clever enough to allow this to be
probed easily -- we silently ignore unrecognized sa_flags bits.

Big deal, check the kversion. :)

Unforunately, in my eyes SA_xyz doesn't help with FS, so
whether it is better than uc_flags or not, is not what I care
about.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev  wrote:
> 14.08.2015 03:27, Linus Torvalds пишет:
>>
>> On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev  wrote:
>>>
>>> For example because you can as well do:
>>> prctl(ARCH_SET_SIGNAL_SS, 0)
>>> which will mean "restore ss in sighandler to its current value",
>>
>> I really think a prctl() is the wrong thing to do.
>>
>> If you want a signal handler to save/restore segments, I think it
>> should be a SA_xyz flag to sigaction() (the way we have SA_RESTART
>
> Yes, I was proposing the new sigaction() flag in this thread
> already too. But at the end, prctl() looks better to me because
> it allows to pass the TLS value to use when restoring FS.
> The thing is that I am trying to find the similar treatment for
> both the SS and FS problems. If you don't think they need a
> similar treatment, then perhaps the Andy's patch is enough.
>
>> etc).  And off by default because of the obvious compatibility issues.
>
> Of course.
>
> So, what we have right now (in the latest Andy's patch) is:
> 1. lar heuristics
> 2. new uc_flags flag
>
> What it solves: dosemu's regression.
>
> What prctl() can give:
> - fix to dosemu's regression
> - fix to the TLS problem in the future
> - no hack and heuristics
>
> With SA_xyz you can only solve the SS problem, so it is
> probably not any better than the uc_flags things coded
> up by Andy.

I'm leaning slightly toward LAR heuristic + SA_SAVE_SS.  Using a
sigaction flag is a bit less weird than using uc_flags.  It's also
kind of nice that it's more composable -- you can install a SIGUSR1
handler that's just normal code and set SA_SAVE_SS and it'll work,
whereas with uc_flags you need to explicitly twiddle uc_flags in the
handler.

Unfortunately, I don't think we were clever enough to allow this to be
probed easily -- we silently ignore unrecognized sa_flags bits.

--Andy

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

14.08.2015 03:27, Linus Torvalds пишет:

On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev  wrote:

For example because you can as well do:
prctl(ARCH_SET_SIGNAL_SS, 0)
which will mean "restore ss in sighandler to its current value",

I really think a prctl() is the wrong thing to do.

If you want a signal handler to save/restore segments, I think it
should be a SA_xyz flag to sigaction() (the way we have SA_RESTART

Yes, I was proposing the new sigaction() flag in this thread
already too. But at the end, prctl() looks better to me because
it allows to pass the TLS value to use when restoring FS.
The thing is that I am trying to find the similar treatment for
both the SS and FS problems. If you don't think they need a
similar treatment, then perhaps the Andy's patch is enough.


etc).  And off by default because of the obvious compatibility issues.

Of course.

So, what we have right now (in the latest Andy's patch) is:
1. lar heuristics
2. new uc_flags flag

What it solves: dosemu's regression.

What prctl() can give:
- fix to dosemu's regression
- fix to the TLS problem in the future
- no hack and heuristics

With SA_xyz you can only solve the SS problem, so it is
probably not any better than the uc_flags things coded
up by Andy.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Linus Torvalds]

On Thu, Aug 13, 2015 at 5:24 PM, Andy Lutomirski  wrote:
>
> So yes, it mostly works.  It also sucks, and it makes it extremely
> unpleasant for any other program to do this.

Well, I'd argue that

 (a) we don't really _want_ any other programs to do that

 (b) but yeah, we might want to make it easier to do cleanly and
explicitly for dosemu (and any other possible programs that do want to
do it)

so if this is for just things like dosemu and for test applications
etc, let's just introduce something like SA_RESTORE_SS for those to
explicitly opt in to "I want this signal handler to save and restore
SS".

That's how we have handled these kinds of things in the past (ie
SA_SIGINFO extends the stack frame with siginfo, sa_restorer says that
user space will use its own sigrestore function, etc etc).

Yeah, the SA_xyzzy flags aren't exactly _common_, but it's how we've
handled these kinds of compat issues in the past (SA_ONESHOT, SA_MASK,
and SA_NOCLDWAIT are obviously about the traditional BSD/SysV
differences, and SA_RESTORER is a Linux internal compatibility thing
etc)

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Linus Torvalds]

On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev  wrote:
>
> For example because you can as well do:
> prctl(ARCH_SET_SIGNAL_SS, 0)
> which will mean "restore ss in sighandler to its current value",

I really think a prctl() is the wrong thing to do.

If you want a signal handler to save/restore segments, I think it
should be a SA_xyz flag to sigaction() (the way we have SA_RESTART
etc).  And off by default because of the obvious compatibility issues.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Thu, Aug 13, 2015 at 5:08 PM, Linus Torvalds
 wrote:
> On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev  wrote:
>> 14.08.2015 02:00, Andy Lutomirski пишет:
>>>
>>> DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
>>> threading library starts using WRFSBASE instead of arch_prctl.
>>
>> Hmm, how about the following:
>>
>> prctl(ARCH_SET_SIGNAL_FS, my_tls)
>> If my_tls==NULL - use current fsbase (including one of WRFSBASE).
>> If my_tls==(void)-1 - don't restore.
>>
>> Can this work?
>
> I'm really inclined to wonder whether we need the change and such a flag at 
> all.
>
> Basically, no _normal_ application will ever play with segments at all
> on x86-64. So our current behavior of not touching any segments at all
> for signal handling would seem to be the right thing to do - because
> it handles all the sane cases optimally.
>
> And applications that *do* play with segments very much know they do
> so, and we already put the onus on *them* to save/restore segments.
> That's how dosemu clearly works today.

I agree for all but CS and SS, which are special.  CS is fine already.
The way that DOSEMU works around SS it is hideous: it just gives up on
sigreturn working and fixes the segments with IRET.  (Also, if DOSEMU
ever wants to get ESP[31:16] right, it *can't*: only the kernel can
usefully do espfix64, and DOSEMU can't get the kernel to return from
64-bit code to 16-bit code, because we zap SS.  DOSEMU fudges it by
forcibly zeroing ESP[31:16]), but that's not a full solution and I
wouldn't be surprised if something breaks as a result.

So yes, it mostly works.  It also sucks, and it makes it extremely
unpleasant for any other program to do this.  I'd argue that keeping
things like the sigreturn_64 test working is quite valuable, because
it's a royal PITA to exercise this code cleanly without proper control
of SS.  Unfortunately, making it hard for sigreturn_64 to exercise
this stuff doesn't mean that the bad guys can't do it, because they'll
use malformed ELF files, or ptrace, or stupid modify_ldt races (except
I hopefully fixed those), or x32, or compat, or some other hack I
haven't thought of yet, and they'll hit the same bugs.  I've lost
count of the number of bugs of various severities that the sigreturn
tests have shaken out *and* caught in patches that were emailed in.

We could say "forget sigreturn_64, use sigreturn_32 instead", but that
can't exercise !IA32_EMULATION kernels, and that code is a bit
different.

(BadIRET, for example, is nominally unreachable from 64-bit code
without modify_ldt and the sigreturn fix, except that I think know of
one really nasty way to do it.  I have no intention of implementing
that, so keeping selftests working nicely makes me *much* more
confident.)

Obviously, if we reintroduce SS restoration, we need to do it much
more carefully.  My RFC patches are an attempt to do that, but it
needs a lot of care to make sure all the bases are covered.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

14.08.2015 03:05, Andy Lutomirski пишет:

On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev  wrote:

14.08.2015 02:00, Andy Lutomirski пишет:


On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev  wrote:

14.08.2015 01:29, Andy Lutomirski пишет:

On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev  wrote:

14.08.2015 01:11, Andy Lutomirski пишет:


Now suppose you set some magic flag and jump (via sigreturn,
trampoline, whatever) into DOS code.  The DOS code loads 0x7 into FS
and then gets #GP.  You land in a signal handler.  As far as the
kernel's concerned, the FS base register is whatever the base of LDT
entry 0 is.  What else is the kernel supposed to shove in there?

The same as what happens when you do in userspace:
---
asm ("mov $0,%%fs\n");
prctl(ARCH_SET_FS, my_tls_base);
---

This was the trick I did before gcc started to use FS in prolog,
now I have to do this in asm.
But how simpler for the kernel is to do the same?


I think that making this work fully in the kernel would require a
full-blown FS equivalent of sigaltstack, and that seems like overkill.

Setting selector and base is what you call an "equivalent of
sigaltstack"?

Yes.  sigaltstack says "hey, kernel! here's my SP for signal
handling."  I think we'd need something similar to tell the kernel
what my_tls_base is.  Using the most recent thing passed to
ARCH_SET_FS is no good because WRFSBASE systems might not use
ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
as we enable WRFSBASE.

If someone uses WRFSBASE and wants things to be preserved
in a sighandler, he'll just not set the aforementioned flag. No
regression.
Whoever wants to use that flag properly, will not use WRFSBASE,
and will use ARCH_SET_FS or set_thread_area().
What exactly breakage do you have in mind?

DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
threading library starts using WRFSBASE instead of arch_prctl.

Hmm, how about the following:

prctl(ARCH_SET_SIGNAL_FS, my_tls)
If my_tls==NULL - use current fsbase (including one of WRFSBASE).
If my_tls==(void)-1 - don't restore.

Can this work?

Certainly, but why?

For example because you can as well do:
prctl(ARCH_SET_SIGNAL_SS, 0)
which will mean "restore ss in sighandler to its current value",
and this will fix the regression right here right now, without
any lar heuristic, and will keep the correct behaviour of always
restoring ss for those who need that.


   ISTM user code should do this itself with a
little bit of asm unless there's a good reason it wouldn't work.

Any example of that asm?

I can even code up the ARCH_SET_SIGNAL_SS patch if you want,
it seems absolutely trivial, much simpler than the aforementioned asm,
much simpler than the patches you propose.
So my question is more like "why not", rather than "why".
Just because it is simple and clean, IMHO.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Linus Torvalds]

On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev  wrote:
> 14.08.2015 02:00, Andy Lutomirski пишет:
>>
>> DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
>> threading library starts using WRFSBASE instead of arch_prctl.
>
> Hmm, how about the following:
>
> prctl(ARCH_SET_SIGNAL_FS, my_tls)
> If my_tls==NULL - use current fsbase (including one of WRFSBASE).
> If my_tls==(void)-1 - don't restore.
>
> Can this work?

I'm really inclined to wonder whether we need the change and such a flag at all.

Basically, no _normal_ application will ever play with segments at all
on x86-64. So our current behavior of not touching any segments at all
for signal handling would seem to be the right thing to do - because
it handles all the sane cases optimally.

And applications that *do* play with segments very much know they do
so, and we already put the onus on *them* to save/restore segments.
That's how dosemu clearly works today.

So why not just keep to that policy?  It has worked fairly well so
far. Only when we tried to change that policy did we hit these
problems, because existing applications obviously already live with
what we do (or rather, what we _don't_ do) right now...

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev  wrote:
> 14.08.2015 02:00, Andy Lutomirski пишет:
>
>> On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev  wrote:
>>>
>>> 14.08.2015 01:29, Andy Lutomirski пишет:

 On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev  wrote:
>
> 14.08.2015 01:11, Andy Lutomirski пишет:
>
>> Now suppose you set some magic flag and jump (via sigreturn,
>> trampoline, whatever) into DOS code.  The DOS code loads 0x7 into FS
>> and then gets #GP.  You land in a signal handler.  As far as the
>> kernel's concerned, the FS base register is whatever the base of LDT
>> entry 0 is.  What else is the kernel supposed to shove in there?
>
> The same as what happens when you do in userspace:
> ---
> asm ("mov $0,%%fs\n");
> prctl(ARCH_SET_FS, my_tls_base);
> ---
>
> This was the trick I did before gcc started to use FS in prolog,
> now I have to do this in asm.
> But how simpler for the kernel is to do the same?
>
>> I think that making this work fully in the kernel would require a
>> full-blown FS equivalent of sigaltstack, and that seems like overkill.
>
> Setting selector and base is what you call an "equivalent of
> sigaltstack"?

 Yes.  sigaltstack says "hey, kernel! here's my SP for signal
 handling."  I think we'd need something similar to tell the kernel
 what my_tls_base is.  Using the most recent thing passed to
 ARCH_SET_FS is no good because WRFSBASE systems might not use
 ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
 as we enable WRFSBASE.
>>>
>>> If someone uses WRFSBASE and wants things to be preserved
>>> in a sighandler, he'll just not set the aforementioned flag. No
>>> regression.
>>> Whoever wants to use that flag properly, will not use WRFSBASE,
>>> and will use ARCH_SET_FS or set_thread_area().
>>> What exactly breakage do you have in mind?
>>
>> DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
>> threading library starts using WRFSBASE instead of arch_prctl.
>
> Hmm, how about the following:
>
> prctl(ARCH_SET_SIGNAL_FS, my_tls)
> If my_tls==NULL - use current fsbase (including one of WRFSBASE).
> If my_tls==(void)-1 - don't restore.
>
> Can this work?

Certainly, but why?  ISTM user code should do this itself with a
little bit of asm unless there's a good reason it wouldn't work.  A
good reason it wouldn't work is that high-performance applications
need this and an extra syscall is too slow, but IMO that would need
evidence.

--Andy


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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Linus Torvalds]

On Thu, Aug 13, 2015 at 4:43 PM, Stas Sergeev  wrote:
> In fact, in the cases I can remember, the kernel patches
> were never reverted, see this for instance:
> https://lkml.org/lkml/2005/3/26/21
> And there were many other breakages too, for example when
> kernel started to use top-down memory allocations. These
> were because of the poor code in dosemu, and dosemu was
> asked to fix the code. I guess the policy to never break userspace
> was not existing back then. Or there is some margin below
> which the code quality is considered not worth the troubles. :)

Back in 2005 we may well not have been as strict about regressions as
we are now, no. The strict policy of no regressions actually
originally started mainly wrt suspend/resume issues, where the "fix
one machine, break another" kind of back-and-forth caused endless
problems, and meant that we didn't actually necessarily make any
forward progress, just moving a problem around.

(That said, I'd like to think that we've _always_ tried very hard to
not break stuff, it just wasn't necessarily the kind of very explicit
and hard rule that it is these days).

Also, there are certainly developers who push back on fixing the
regressions they caused. That is in fact the cause of some of my more
memorable explosions. But if I'm not brought into the discussion, and
the push-back happens on a mailing list, I may not even be aware of
the regression and the fact that a developer isn't willing to fix it.

I've also seen other projects be more willing to work around problems
like this than I personally would consider to be a good idea. For
example, we had some Wine regressions that broke a steam game or two,
and it was debugged on the steam and wine lists, and took a longish
time to actually even get to the attention of kernel people, because
the developers were actually willing to try to do an update and fix
their application to not do the thing that caused problems. Which I
certainly appreciate, but at the same time that doesn't necessarily
help the user who sits there with a game that just didn't work. So
even if an app is getting updated eventually, the kernel breakage
should be fixed.

So if some patch causes problems, and the author of the patch doesn't
acknowledge the problem or even if the application developer says "we
can work around that", always feel free to escalate the issue and
bring in upper maintainers.

That said, it *does* depend a bit on just how core the area is.
Sometimes it just gets too painful to fix things, and while the "no
regressions" rule is pretty damn close to the strictest rule we have,
there are never any completely absolute rules. As mentioned, there are
exceptions to the regression rule too, and sometimes the result might
just end up being "very few people are actually affected, and there's
a sufficiently good reason for the regression that we'll just cop
out".

But that should really be a very rare occurrence. We used to have
quite a lot of those kinds of issues with the GPU layer (resulting in
flag-days with the X server etc), and it really causes huge problems.

So there are no absolutes. But regressions are a serious problem, and
need to be treated as such. I will not _guarantee_ that we always fix
them, but I would hope we do our best.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

14.08.2015 02:00, Andy Lutomirski пишет:

On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev  wrote:

14.08.2015 01:29, Andy Lutomirski пишет:

On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev  wrote:

14.08.2015 01:11, Andy Lutomirski пишет:


Now suppose you set some magic flag and jump (via sigreturn,
trampoline, whatever) into DOS code.  The DOS code loads 0x7 into FS
and then gets #GP.  You land in a signal handler.  As far as the
kernel's concerned, the FS base register is whatever the base of LDT
entry 0 is.  What else is the kernel supposed to shove in there?

The same as what happens when you do in userspace:
---
asm ("mov $0,%%fs\n");
prctl(ARCH_SET_FS, my_tls_base);
---

This was the trick I did before gcc started to use FS in prolog,
now I have to do this in asm.
But how simpler for the kernel is to do the same?


I think that making this work fully in the kernel would require a
full-blown FS equivalent of sigaltstack, and that seems like overkill.

Setting selector and base is what you call an "equivalent of
sigaltstack"?

Yes.  sigaltstack says "hey, kernel! here's my SP for signal
handling."  I think we'd need something similar to tell the kernel
what my_tls_base is.  Using the most recent thing passed to
ARCH_SET_FS is no good because WRFSBASE systems might not use
ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
as we enable WRFSBASE.

If someone uses WRFSBASE and wants things to be preserved
in a sighandler, he'll just not set the aforementioned flag. No regression.
Whoever wants to use that flag properly, will not use WRFSBASE,
and will use ARCH_SET_FS or set_thread_area().
What exactly breakage do you have in mind?

DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
threading library starts using WRFSBASE instead of arch_prctl.

Hmm, how about the following:

prctl(ARCH_SET_SIGNAL_FS, my_tls)
If my_tls==NULL - use current fsbase (including one of WRFSBASE).
If my_tls==(void)-1 - don't restore.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

14.08.2015 02:18, Linus Torvalds пишет:

On Thu, Aug 13, 2015 at 4:05 PM, Linus Torvalds
 wrote:

The _only_ thing that matters is that something broke.

To clarify: things like test programs etc don't matter. Real
applications, used by real users. That's what regressions cover. If
you have a workflow that isn't just some random kernel test thing, and
you depend on it, and we break it, the kernel is supposed to fix it.

There are some (very few) exceptions.

If it's a security issue, we may not be able to "fix" it, because
other concerns can obviously take precedence.

Also, sometimes the reports come in way too late - if you were running
some stable distro kernel for several years, and updated, and notice a
change that happened four years ago and modern applications now rely
on the _new_ behavior, we may not be able to fix the regression any
more.

But no, "it was an unintentional kernel bug and clearly just stupid
crap code, and we fixed it and now the kernel is much better and
cleaner" is not a valid reason for regressions. We'll go back to the
stupid and crap code if necessary, however much that may annoy us.

IMHO at least such ocasions should be listed somewhere,
and the software authors should be asked to fix their code.
Then you'll be able to re-visit the problem later.
It may be unreasonable to carry the compatibility hacks forever
if the software that needed it, released the fix 10 years ago.

In fact, in the cases I can remember, the kernel patches
were never reverted, see this for instance:
https://lkml.org/lkml/2005/3/26/21
And there were many other breakages too, for example when
kernel started to use top-down memory allocations. These
were because of the poor code in dosemu, and dosemu was
asked to fix the code. I guess the policy to never break userspace
was not existing back then. Or there is some margin below
which the code quality is considered not worth the troubles. :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Raymond Jennings]

On 08/13/15 16:18, Linus Torvalds wrote:

On Thu, Aug 13, 2015 at 4:05 PM, Linus Torvalds
 wrote:

The _only_ thing that matters is that something broke.

To clarify: things like test programs etc don't matter. Real
applications, used by real users. That's what regressions cover. If
you have a workflow that isn't just some random kernel test thing, and
you depend on it, and we break it, the kernel is supposed to fix it.

There are some (very few) exceptions.

If it's a security issue, we may not be able to "fix" it, because
other concerns can obviously take precedence.

Also, sometimes the reports come in way too late - if you were running
some stable distro kernel for several years, and updated, and notice a
change that happened four years ago and modern applications now rely
on the _new_ behavior, we may not be able to fix the regression any
more.

But no, "it was an unintentional kernel bug and clearly just stupid
crap code, and we fixed it and now the kernel is much better and
cleaner" is not a valid reason for regressions. We'll go back to the
stupid and crap code if necessary, however much that may annoy us.

For an example of the kind of things we may have to do, see commits

 64f371bc3107 autofs: make the autofsv5 packet file descriptor use
a packetized pipe
 9883035ae7ed pipes: add a "packetized pipe" mode for writing

and just wonder at the insanity. That's the kinds of things that
happen when one application had actively worked around a bug in
compatibility handling, and then trying to "fix" that bug just caused
another application to break instead.

Linus
Is there a way to temporally confine the bad crap code just to the 
applications that depend on it, or does a userspace app latching onto 
bad behavior effectively lock down the abi for the future?


I know that some features in the kernel get deprecated over a process 
(devfs for example) once userspace is given an alternative...would there 
be a process like that to deal with userspace code that is pinning a 
piece of crap in the kernel?

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Linus Torvalds]

On Thu, Aug 13, 2015 at 4:05 PM, Linus Torvalds
 wrote:
>
> The _only_ thing that matters is that something broke.

To clarify: things like test programs etc don't matter. Real
applications, used by real users. That's what regressions cover. If
you have a workflow that isn't just some random kernel test thing, and
you depend on it, and we break it, the kernel is supposed to fix it.

There are some (very few) exceptions.

If it's a security issue, we may not be able to "fix" it, because
other concerns can obviously take precedence.

Also, sometimes the reports come in way too late - if you were running
some stable distro kernel for several years, and updated, and notice a
change that happened four years ago and modern applications now rely
on the _new_ behavior, we may not be able to fix the regression any
more.

But no, "it was an unintentional kernel bug and clearly just stupid
crap code, and we fixed it and now the kernel is much better and
cleaner" is not a valid reason for regressions. We'll go back to the
stupid and crap code if necessary, however much that may annoy us.

For an example of the kind of things we may have to do, see commits

64f371bc3107 autofs: make the autofsv5 packet file descriptor use
a packetized pipe
9883035ae7ed pipes: add a "packetized pipe" mode for writing

and just wonder at the insanity. That's the kinds of things that
happen when one application had actively worked around a bug in
compatibility handling, and then trying to "fix" that bug just caused
another application to break instead.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

14.08.2015 02:00, Andy Lutomirski пишет:

On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev  wrote:

14.08.2015 01:29, Andy Lutomirski пишет:

On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev  wrote:

14.08.2015 01:11, Andy Lutomirski пишет:


Now suppose you set some magic flag and jump (via sigreturn,
trampoline, whatever) into DOS code.  The DOS code loads 0x7 into FS
and then gets #GP.  You land in a signal handler.  As far as the
kernel's concerned, the FS base register is whatever the base of LDT
entry 0 is.  What else is the kernel supposed to shove in there?

The same as what happens when you do in userspace:
---
asm ("mov $0,%%fs\n");
prctl(ARCH_SET_FS, my_tls_base);
---

This was the trick I did before gcc started to use FS in prolog,
now I have to do this in asm.
But how simpler for the kernel is to do the same?


I think that making this work fully in the kernel would require a
full-blown FS equivalent of sigaltstack, and that seems like overkill.

Setting selector and base is what you call an "equivalent of
sigaltstack"?

Yes.  sigaltstack says "hey, kernel! here's my SP for signal
handling."  I think we'd need something similar to tell the kernel
what my_tls_base is.  Using the most recent thing passed to
ARCH_SET_FS is no good because WRFSBASE systems might not use
ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
as we enable WRFSBASE.

If someone uses WRFSBASE and wants things to be preserved
in a sighandler, he'll just not set the aforementioned flag. No regression.
Whoever wants to use that flag properly, will not use WRFSBASE,
and will use ARCH_SET_FS or set_thread_area().
What exactly breakage do you have in mind?

DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
threading library starts using WRFSBASE instead of arch_prctl.

Whoever wants to use the new flag, will need to call
prctl(ARCH_SET_FS, needed_tls) or the like, before altering FS.
"needed_tls" will be the current TLS in most cases.
This will make kernel to know what TLS should be restored in
sighandler. Yes, that's resembles sigaltstack to some degree,
but is simple? Nothing special on kernel side, and not a big
deal for the user to call prctl().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Linus Torvalds]

On Thu, Aug 13, 2015 at 3:01 PM, Raymond Jennings  wrote:
>
> So it still counts as a regression if the kernel pulls the rug out from
> under someone that was relying on undocumented or buggy behavior?

Absolutely. There are no excuses for regressions. If the code was
badly written and left itself open to user space "misusing" it, it's
our problem. Especially if the code was badly written to begin with,
and user space worked around our bad code.

We don't then "fix" code and blame user space for doing bad things.

In particular, we don't cop out and say "hey, you didn't follow the
docs" (whether they existed or not) or "you didn't do what we meant
you to do".

The _only_ thing that matters is that something broke.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev  wrote:
> 14.08.2015 01:29, Andy Lutomirski пишет:
>>
>> On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev  wrote:
>>>
>>> 14.08.2015 01:11, Andy Lutomirski пишет:
>>>
 Now suppose you set some magic flag and jump (via sigreturn,
 trampoline, whatever) into DOS code.  The DOS code loads 0x7 into FS
 and then gets #GP.  You land in a signal handler.  As far as the
 kernel's concerned, the FS base register is whatever the base of LDT
 entry 0 is.  What else is the kernel supposed to shove in there?
>>>
>>> The same as what happens when you do in userspace:
>>> ---
>>> asm ("mov $0,%%fs\n");
>>> prctl(ARCH_SET_FS, my_tls_base);
>>> ---
>>>
>>> This was the trick I did before gcc started to use FS in prolog,
>>> now I have to do this in asm.
>>> But how simpler for the kernel is to do the same?
>>>
 I think that making this work fully in the kernel would require a
 full-blown FS equivalent of sigaltstack, and that seems like overkill.
>>>
>>> Setting selector and base is what you call an "equivalent of
>>> sigaltstack"?
>>
>> Yes.  sigaltstack says "hey, kernel! here's my SP for signal
>> handling."  I think we'd need something similar to tell the kernel
>> what my_tls_base is.  Using the most recent thing passed to
>> ARCH_SET_FS is no good because WRFSBASE systems might not use
>> ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
>> as we enable WRFSBASE.
>
> If someone uses WRFSBASE and wants things to be preserved
> in a sighandler, he'll just not set the aforementioned flag. No regression.
> Whoever wants to use that flag properly, will not use WRFSBASE,
> and will use ARCH_SET_FS or set_thread_area().
> What exactly breakage do you have in mind?

DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
threading library starts using WRFSBASE instead of arch_prctl.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

14.08.2015 01:29, Andy Lutomirski пишет:

On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev  wrote:

14.08.2015 01:11, Andy Lutomirski пишет:


Now suppose you set some magic flag and jump (via sigreturn,
trampoline, whatever) into DOS code.  The DOS code loads 0x7 into FS
and then gets #GP.  You land in a signal handler.  As far as the
kernel's concerned, the FS base register is whatever the base of LDT
entry 0 is.  What else is the kernel supposed to shove in there?

The same as what happens when you do in userspace:
---
asm ("mov $0,%%fs\n");
prctl(ARCH_SET_FS, my_tls_base);
---

This was the trick I did before gcc started to use FS in prolog,
now I have to do this in asm.
But how simpler for the kernel is to do the same?


I think that making this work fully in the kernel would require a
full-blown FS equivalent of sigaltstack, and that seems like overkill.

Setting selector and base is what you call an "equivalent of sigaltstack"?

Yes.  sigaltstack says "hey, kernel! here's my SP for signal
handling."  I think we'd need something similar to tell the kernel
what my_tls_base is.  Using the most recent thing passed to
ARCH_SET_FS is no good because WRFSBASE systems might not use
ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
as we enable WRFSBASE.

If someone uses WRFSBASE and wants things to be preserved
in a sighandler, he'll just not set the aforementioned flag. No regression.
Whoever wants to use that flag properly, will not use WRFSBASE,
and will use ARCH_SET_FS or set_thread_area().
What exactly breakage do you have in mind?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev  wrote:
> 14.08.2015 01:11, Andy Lutomirski пишет:
>
>> Now suppose you set some magic flag and jump (via sigreturn,
>> trampoline, whatever) into DOS code.  The DOS code loads 0x7 into FS
>> and then gets #GP.  You land in a signal handler.  As far as the
>> kernel's concerned, the FS base register is whatever the base of LDT
>> entry 0 is.  What else is the kernel supposed to shove in there?
>
> The same as what happens when you do in userspace:
> ---
> asm ("mov $0,%%fs\n");
> prctl(ARCH_SET_FS, my_tls_base);
> ---
>
> This was the trick I did before gcc started to use FS in prolog,
> now I have to do this in asm.
> But how simpler for the kernel is to do the same?
>
>> I think that making this work fully in the kernel would require a
>> full-blown FS equivalent of sigaltstack, and that seems like overkill.
>
> Setting selector and base is what you call an "equivalent of sigaltstack"?

Yes.  sigaltstack says "hey, kernel! here's my SP for signal
handling."  I think we'd need something similar to tell the kernel
what my_tls_base is.  Using the most recent thing passed to
ARCH_SET_FS is no good because WRFSBASE systems might not use
ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
as we enable WRFSBASE.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

14.08.2015 01:11, Andy Lutomirski пишет:

On Thu, Aug 13, 2015 at 3:02 PM, Stas Sergeev  wrote:

14.08.2015 00:46, Linus Torvalds пишет:

On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings 
wrote:

I am curious about what's supposed to happen normally on signal delivery.

Is SS a register that's supposed to be preserved like EIP/RIP and CS when
a
signal is delivered?

What exactly does "supposed" mean?

On x86-64, we traditionally haven't touched SS, because it doesn't
really matter in 64-bit long mode. And apparently dosemu depended on
that behavior.

So clearly, we're not "supposed" to save/restore it. Because reality
matters a hell of a lot more than any theoretical arguments.

Unless you introduce some clever flag to explicitly request its restoring.
There is another problem as well which is that gcc assumes
FS base to point to TLS at function prolog. Since FS is not
restored too, the only suggestion I get is to write a sighandlers
in asm... I wonder if someone really should write a sighandler in
asm to restore FS base manually with a syscall.
So I think the reality is asking for a new flag. :)

I still don't see how this hypothetical flag would work.

The relevant task state consists of FS and the hidden FS base
register.  If you build with -fstack-protector, GCC really wants the
FS base register to point to the right place.  So you can't change it
in the middle of a C function (because the prologue and epilogue will
fail to match).

Now suppose you set some magic flag and jump (via sigreturn,
trampoline, whatever) into DOS code.  The DOS code loads 0x7 into FS
and then gets #GP.  You land in a signal handler.  As far as the
kernel's concerned, the FS base register is whatever the base of LDT
entry 0 is.  What else is the kernel supposed to shove in there?

The same as what happens when you do in userspace:
---
asm ("mov $0,%%fs\n");
prctl(ARCH_SET_FS, my_tls_base);
---

This was the trick I did before gcc started to use FS in prolog,
now I have to do this in asm.
But how simpler for the kernel is to do the same?


I think that making this work fully in the kernel would require a
full-blown FS equivalent of sigaltstack, and that seems like overkill.

Setting selector and base is what you call an "equivalent of sigaltstack"?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Thu, Aug 13, 2015 at 3:02 PM, Stas Sergeev  wrote:
> 14.08.2015 00:46, Linus Torvalds пишет:
>>
>> On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings 
>> wrote:
>>>
>>> I am curious about what's supposed to happen normally on signal delivery.
>>>
>>> Is SS a register that's supposed to be preserved like EIP/RIP and CS when
>>> a
>>> signal is delivered?
>>
>> What exactly does "supposed" mean?
>>
>> On x86-64, we traditionally haven't touched SS, because it doesn't
>> really matter in 64-bit long mode. And apparently dosemu depended on
>> that behavior.
>>
>> So clearly, we're not "supposed" to save/restore it. Because reality
>> matters a hell of a lot more than any theoretical arguments.
>
> Unless you introduce some clever flag to explicitly request its restoring.
> There is another problem as well which is that gcc assumes
> FS base to point to TLS at function prolog. Since FS is not
> restored too, the only suggestion I get is to write a sighandlers
> in asm... I wonder if someone really should write a sighandler in
> asm to restore FS base manually with a syscall.
> So I think the reality is asking for a new flag. :)

I still don't see how this hypothetical flag would work.

The relevant task state consists of FS and the hidden FS base
register.  If you build with -fstack-protector, GCC really wants the
FS base register to point to the right place.  So you can't change it
in the middle of a C function (because the prologue and epilogue will
fail to match).

Now suppose you set some magic flag and jump (via sigreturn,
trampoline, whatever) into DOS code.  The DOS code loads 0x7 into FS
and then gets #GP.  You land in a signal handler.  As far as the
kernel's concerned, the FS base register is whatever the base of LDT
entry 0 is.  What else is the kernel supposed to shove in there?

I think that making this work fully in the kernel would require a
full-blown FS equivalent of sigaltstack, and that seems like overkill.

Now, if it turns out that Oracle or whoever wants to write a JVM that
uses WRFSBASE but still handles signals using standard C signal
handlers, they're going to have the same problem.  They, too, could
fix it in libc, or someone could come up with an in-kernel mechanism
that gets enabled at the same time as WRFSBASE and is careful not to
break existing code.

I really think that we want to have a single, coherent change whenever
WRFSBASE and WRGSBASE get enabled that covers all the bases.  None of
the patch sets so far have done that.  But this cuts both ways: I
don't think we should change FS and GS behavior in signal handlers
until we are confident that we know what's happening with the FSGSBASE
instructions.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

14.08.2015 01:01, Raymond Jennings пишет:



On 08/13/15 14:46, Linus Torvalds wrote:
On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings 
 wrote:
I am curious about what's supposed to happen normally on signal 
delivery.


Is SS a register that's supposed to be preserved like EIP/RIP and CS 
when a

signal is delivered?

What exactly does "supposed" mean?
Basically, when a process/thread receives a signal, what happens to 
its registers?

So clearly, we're not "supposed" to save/restore it. Because reality
matters a hell of a lot more than any theoretical arguments.
So it still counts as a regression if the kernel pulls the rug out 
from under someone that was relying on undocumented or buggy behavior?



You probably want to read the whole thread...
Or start from here:
https://lkml.org/lkml/2015/8/12/800
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

14.08.2015 00:46, Linus Torvalds пишет:

On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings  wrote:

I am curious about what's supposed to happen normally on signal delivery.

Is SS a register that's supposed to be preserved like EIP/RIP and CS when a
signal is delivered?

What exactly does "supposed" mean?

On x86-64, we traditionally haven't touched SS, because it doesn't
really matter in 64-bit long mode. And apparently dosemu depended on
that behavior.

So clearly, we're not "supposed" to save/restore it. Because reality
matters a hell of a lot more than any theoretical arguments.

Unless you introduce some clever flag to explicitly request its restoring.
There is another problem as well which is that gcc assumes
FS base to point to TLS at function prolog. Since FS is not
restored too, the only suggestion I get is to write a sighandlers
in asm... I wonder if someone really should write a sighandler in
asm to restore FS base manually with a syscall.
So I think the reality is asking for a new flag. :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Raymond Jennings]

On 08/13/15 14:46, Linus Torvalds wrote:

On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings  wrote:

I am curious about what's supposed to happen normally on signal delivery.

Is SS a register that's supposed to be preserved like EIP/RIP and CS when a
signal is delivered?

What exactly does "supposed" mean?
Basically, when a process/thread receives a signal, what happens to its 
registers?

So clearly, we're not "supposed" to save/restore it. Because reality
matters a hell of a lot more than any theoretical arguments.
So it still counts as a regression if the kernel pulls the rug out from 
under someone that was relying on undocumented or buggy behavior?

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Linus Torvalds]

On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings  wrote:
>
> I am curious about what's supposed to happen normally on signal delivery.
>
> Is SS a register that's supposed to be preserved like EIP/RIP and CS when a
> signal is delivered?

What exactly does "supposed" mean?

On x86-64, we traditionally haven't touched SS, because it doesn't
really matter in 64-bit long mode. And apparently dosemu depended on
that behavior.

So clearly, we're not "supposed" to save/restore it. Because reality
matters a hell of a lot more than any theoretical arguments.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Raymond Jennings]

On 08/13/15 13:09, Linus Torvalds wrote:

On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov  wrote:

If only I'm not missin something obvious this should not hurt us.
But I gonna build test kernel and check to be sure tomorrow, ok?

Thanks,

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

I am curious about what's supposed to happen normally on signal delivery.

Is SS a register that's supposed to be preserved like EIP/RIP and CS 
when a signal is delivered?

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

13.08.2015 22:49, Andy Lutomirski пишет:

On Aug 13, 2015 12:05 PM, "Stas Sergeev"  wrote:

13.08.2015 21:41, Andy Lutomirski пишет:


Stas: I think uc_flags is okay.  We don't currently read it during
sigreturn, but I see no reason that we can't start reading it.

Andy, we definitely have some communication discontinuity here. :)
The point is not sigreturn. If we are talking about the flags that
will in the future control also TLS, how would you limit it to sigreturn()?
It should control the restoring of FS _on signal delivery_, not only
on sigreturn()! So how uc_flags can be used for this at all?

Ah, you want it restored on signal delivery.  What would it be
restored to?

Null descriptor and TLS base in MSR I guess, no?


   ISTM that can be done easily enough in user code, so
maybe we should leave it to user code.

But it is actually not.
gcc relies of fs pointing to TLS on the function prolog, so
the asm signal handlers again?
And there are just too many trickery for an asm handler.
Should it do the syscall to set fs base via MSR? And to what
value? Why do you think the user should mess with all this
pain? It is just much easier to do on a kernel side, is it not?
And IMHO this is the kernel's responsibility to adhere to the
ABI constraints when entering the signal handler, and the
ABI says fs should point to TLS.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Linus Torvalds]

On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov  wrote:
>
> If only I'm not missin something obvious this should not hurt us.
> But I gonna build test kernel and check to be sure tomorrow, ok?

Thanks,

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Cyrill Gorcunov]

On Thu, Aug 13, 2015 at 12:53:03PM -0700, Linus Torvalds wrote:
> On Thu, Aug 13, 2015 at 11:41 AM, Andy Lutomirski  wrote:
> > On Thu, Aug 13, 2015 at 11:35 AM, Linus Torvalds
> >  wrote:
> >>
> >> Ok. So I'm inclined to do the bigger revert, just to fix the compile
> >> issue. It would be crazy to force some silly autoconf script for
> >> random header info.
> >
> > Yeah, probably makes sense, but one of us should explicitly test CRIU
> > (both new and old versions) on the result.  CRIU does interesting
> > things involving sigcontext and protocol buffers.
> 
> I've reverted it in the -git tree, I'm adding Pavel and Cyrill to the
> cc, to see if they can check the impact on CRIU..
> 
> Pavel/Cyrill? Current top-of-tree (but that will change) commit
> ed596cde9425 ("Revert x86 sigcontext cleanups").

If only I'm not missin something obvious this should not hurt us.
But I gonna build test kernel and check to be sure tomorrow, ok?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Linus Torvalds]

On Thu, Aug 13, 2015 at 12:59 PM, Stas Sergeev  wrote:
>
> It doesn't: fedora provides a "sanitized up" version of sigcontext.h
> in /usr/include/bits, which comes from glibc-headers-2.21-7.fc22.x86_64.
> So it seems the "sanitized up" headers come from glibc, which
> means all other distros would have that too.

Yes. Except the whole point of uapi was that in the long term the
glibc people should just be able to pick up the kernel ones directly.

And while that may involve some further editing, it sure as hell
shouldn't involve "oh, I know, this got renamed, so now I have to
rename it back". That would be crazy.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

13.08.2015 22:37, Linus Torvalds пишет:

On Thu, Aug 13, 2015 at 12:13 PM, Stas Sergeev  wrote:

As for the compilation failure - I am surprised you even care.
I thought the "we don't break userspace" covers only run-time,
not compile-time. Oh well.

I definitely care.

Compile issues may be slightly lower on my radar, but the basic rule
should be that upgrading a kernel shouldn't cause problems.

It doesn't: fedora provides a "sanitized up" version of sigcontext.h
in /usr/include/bits, which comes from glibc-headers-2.21-7.fc22.x86_64.
So it seems the "sanitized up" headers come from glibc, which
means all other distros would have that too.


The only exception is for stuff that gets very intimate with the
kernel itself - ie things like external modules etc. Those we don't
really try to cater to, or care about.

Things that actually include internal kernel headers tend to have just
themselves to blame and historically we really didn't care very much
(long long ago we had issues with ext3fs-tools etc until those kinds
of things just ended up making their own copies).

But the point of the uabi headers was that even _that_ is supposed to
actually work, at least for the limited case of those headers.. So if
a uabi header change causes problems, we really *should* care, because
otherwise, what was the point of that whole uabi rework, really?

I thought this is mainly to help glibc and distributors to
provide a sanitized-up versions.
If it was for something else, then this "something else" didn't
reach the user PCs yet. :) Fedora-22 still has the sanitized
version in the glibc-headers package, so no compilation break
because of your change was ever actually observed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Linus Torvalds]

On Thu, Aug 13, 2015 at 11:41 AM, Andy Lutomirski  wrote:
> On Thu, Aug 13, 2015 at 11:35 AM, Linus Torvalds
>  wrote:
>>
>> Ok. So I'm inclined to do the bigger revert, just to fix the compile
>> issue. It would be crazy to force some silly autoconf script for
>> random header info.
>
> Yeah, probably makes sense, but one of us should explicitly test CRIU
> (both new and old versions) on the result.  CRIU does interesting
> things involving sigcontext and protocol buffers.

I've reverted it in the -git tree, I'm adding Pavel and Cyrill to the
cc, to see if they can check the impact on CRIU..

Pavel/Cyrill? Current top-of-tree (but that will change) commit
ed596cde9425 ("Revert x86 sigcontext cleanups").

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Aug 13, 2015 12:05 PM, "Stas Sergeev"  wrote:
>
> 13.08.2015 21:41, Andy Lutomirski пишет:
>
>> Stas: I think uc_flags is okay.  We don't currently read it during
>> sigreturn, but I see no reason that we can't start reading it.
>
> Andy, we definitely have some communication discontinuity here. :)
> The point is not sigreturn. If we are talking about the flags that
> will in the future control also TLS, how would you limit it to sigreturn()?
> It should control the restoring of FS _on signal delivery_, not only
> on sigreturn()! So how uc_flags can be used for this at all?

Ah, you want it restored on signal delivery.  What would it be
restored to?  ISTM that can be done easily enough in user code, so
maybe we should leave it to user code.

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Linus Torvalds]

On Thu, Aug 13, 2015 at 12:13 PM, Stas Sergeev  wrote:
>
> As for the compilation failure - I am surprised you even care.
> I thought the "we don't break userspace" covers only run-time,
> not compile-time. Oh well.

I definitely care.

Compile issues may be slightly lower on my radar, but the basic rule
should be that upgrading a kernel shouldn't cause problems.

The only exception is for stuff that gets very intimate with the
kernel itself - ie things like external modules etc. Those we don't
really try to cater to, or care about.

Things that actually include internal kernel headers tend to have just
themselves to blame and historically we really didn't care very much
(long long ago we had issues with ext3fs-tools etc until those kinds
of things just ended up making their own copies).

But the point of the uabi headers was that even _that_ is supposed to
actually work, at least for the limited case of those headers.. So if
a uabi header change causes problems, we really *should* care, because
otherwise, what was the point of that whole uabi rework, really?

(And no, we've not always succeeded in that "shouldn't cause problems"
space.  So I'm not claiming we have a perfect track record, but I do
claim that I at least care very deeply)

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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

13.08.2015 22:01, Andy Lutomirski пишет:

On Thu, Aug 13, 2015 at 11:57 AM, Stas Sergeev  wrote:

13.08.2015 21:35, Linus Torvalds пишет:

On Thu, Aug 13, 2015 at 10:51 AM, Stas Sergeev  wrote:

Hello Linus, I verified that patch-minimal.diff is enough
to fix the problem, BUT! dosemu is in fact using the .fs and
.gs fields of sigcontext as a placeholders. Why the minimal
patch alone helps is simply because the kernel headers
installed in a system do not yet represent the newer kernel
developments and have the .fs and .gs fields in.

Ok. So I'm inclined to do the bigger revert, just to fix the compile
issue. It would be crazy to force some silly autoconf script for
random header info.

But OTOH these fields already lost their meaning.
It may make sense to force people to stop using them,
in case you ever want to re-use them again in the future.
 From what Andy says, it seems there are the distant plans
to start restoring FS again. If people still use sigcontext.fs
by that time, you'll get problems. If you force everyone to
stop using them - you'll be safe.

There are distant plans to think about restoring them, at least.  But
it's not just FS -- it's FSBASE as well, and that's not going to fit
in the same slot.  And we still don't get to break old DOSEMU versions
(knowingly, anyway).


In fact, I think the "silly autoconf script" you mentioned above,
should indeed be reverted, and instead I should use
sigcontext.reserved1[8] array to store FS/GS? Is this
safer against ever re-using this space? Not sure...

Honestly, I'd just save it somewhere outside sigcontext.  If it's
application data, treat it as such.  OTOH, if you've already been
saving it in the old FS/GS slots, I see no great reason to change it.

OK, as you promise not to re-use the same slots in the future,
I won't change it. Thanks.
As for the compilation failure - I am surprised you even care.
I thought the "we don't break userspace" covers only run-time,
not compile-time. Oh well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

13.08.2015 21:41, Andy Lutomirski пишет:

Stas: I think uc_flags is okay.  We don't currently read it during
sigreturn, but I see no reason that we can't start reading it.

Andy, we definitely have some communication discontinuity here. :)
The point is not sigreturn. If we are talking about the flags that
will in the future control also TLS, how would you limit it to sigreturn()?
It should control the restoring of FS _on signal delivery_, not only
on sigreturn()! So how uc_flags can be used for this at all?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski]

On Thu, Aug 13, 2015 at 11:57 AM, Stas Sergeev  wrote:
> 13.08.2015 21:35, Linus Torvalds пишет:
>>
>> On Thu, Aug 13, 2015 at 10:51 AM, Stas Sergeev  wrote:
>>>
>>> Hello Linus, I verified that patch-minimal.diff is enough
>>> to fix the problem, BUT! dosemu is in fact using the .fs and
>>> .gs fields of sigcontext as a placeholders. Why the minimal
>>> patch alone helps is simply because the kernel headers
>>> installed in a system do not yet represent the newer kernel
>>> developments and have the .fs and .gs fields in.
>>
>> Ok. So I'm inclined to do the bigger revert, just to fix the compile
>> issue. It would be crazy to force some silly autoconf script for
>> random header info.
>
> But OTOH these fields already lost their meaning.
> It may make sense to force people to stop using them,
> in case you ever want to re-use them again in the future.
> From what Andy says, it seems there are the distant plans
> to start restoring FS again. If people still use sigcontext.fs
> by that time, you'll get problems. If you force everyone to
> stop using them - you'll be safe.

There are distant plans to think about restoring them, at least.  But
it's not just FS -- it's FSBASE as well, and that's not going to fit
in the same slot.  And we still don't get to break old DOSEMU versions
(knowingly, anyway).

>
> In fact, I think the "silly autoconf script" you mentioned above,
> should indeed be reverted, and instead I should use
> sigcontext.reserved1[8] array to store FS/GS? Is this
> safer against ever re-using this space? Not sure...

Honestly, I'd just save it somewhere outside sigcontext.  If it's
application data, treat it as such.  OTOH, if you've already been
saving it in the old FS/GS slots, I see no great reason to change it.

--Andy


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

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

13.08.2015 21:35, Linus Torvalds пишет:

On Thu, Aug 13, 2015 at 10:51 AM, Stas Sergeev  wrote:

Hello Linus, I verified that patch-minimal.diff is enough
to fix the problem, BUT! dosemu is in fact using the .fs and
.gs fields of sigcontext as a placeholders. Why the minimal
patch alone helps is simply because the kernel headers
installed in a system do not yet represent the newer kernel
developments and have the .fs and .gs fields in.

Ok. So I'm inclined to do the bigger revert, just to fix the compile
issue. It would be crazy to force some silly autoconf script for
random header info.

But OTOH these fields already lost their meaning.
It may make sense to force people to stop using them,
in case you ever want to re-use them again in the future.
From what Andy says, it seems there are the distant plans
to start restoring FS again. If people still use sigcontext.fs
by that time, you'll get problems. If you force everyone to
stop using them - you'll be safe.

Also, at least in the past, resolving the compile-time problems
was up to the distributions: they always provided the "sanitized up"
version of kernel headers. Not sure what the current policy is...
In fact, here in Fedora-22, I have
/usr/include/asm/sigcontext.h
that is straight from the kernel, but signal.h is instead using
a "sanitized up" version in
/usr/include/bits/sigcontext.h
so the userspace compiles fine.

In fact, I think the "silly autoconf script" you mentioned above,
should indeed be reverted, and instead I should use
sigcontext.reserved1[8] array to store FS/GS? Is this
safer against ever re-using this space? Not sure...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/