On 05/12/2014 06:16 AM, Josh Boyer wrote:
> On Wed, May 7, 2014 at 12:57 PM, Linus Torvalds
> wrote:
>> On Wed, May 7, 2014 at 2:18 AM, Sven Joachim wrote:
>>>
>>> It seems that at least some 32-bit programs are also broken, since after
>>> upgrading the kernel to 3.14.3 I can no longer start my
On Wed, May 7, 2014 at 12:57 PM, Linus Torvalds
wrote:
> On Wed, May 7, 2014 at 2:18 AM, Sven Joachim wrote:
>>
>> It seems that at least some 32-bit programs are also broken, since after
>> upgrading the kernel to 3.14.3 I can no longer start my old chess
>> database program:
Now that this has
On Wed, May 7, 2014 at 12:57 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wed, May 7, 2014 at 2:18 AM, Sven Joachim svenj...@gmx.de wrote:
It seems that at least some 32-bit programs are also broken, since after
upgrading the kernel to 3.14.3 I can no longer start my old chess
On 05/12/2014 06:16 AM, Josh Boyer wrote:
On Wed, May 7, 2014 at 12:57 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wed, May 7, 2014 at 2:18 AM, Sven Joachim svenj...@gmx.de wrote:
It seems that at least some 32-bit programs are also broken, since after
upgrading the kernel to
On 05/08/2014 06:50 AM, H. Peter Anvin wrote:
> Actually it could use KVM instead of CPU emulation on nearly all modern
> processors...
That being said, it would be cool if someone would either port the
lredir backend (MFS) into Qemu, or finish the 9P front end I started
writing at one point,
On 05/08/2014 06:50 AM, H. Peter Anvin wrote:
> Actually it could use KVM instead of CPU emulation on nearly all modern
> processors...
Of course, at that point you might just run qemu-kvm instead of DOSEMU,
since I seem to recall that DOSEMU is still a real version of DOS. I
have to admit to
Actually it could use KVM instead of CPU emulation on nearly all modern
processors...
On May 7, 2014 11:43:59 PM PDT, Sven Joachim wrote:
>On 2014-05-07 19:09 +0200, H. Peter Anvin wrote:
>
>> On 05/07/2014 09:57 AM, Linus Torvalds wrote:
>>>
>>> Afaik, 16-bit programs under wine already need
On 2014-05-07 19:09 +0200, H. Peter Anvin wrote:
> On 05/07/2014 09:57 AM, Linus Torvalds wrote:
>>
>> Afaik, 16-bit programs under wine already need
>>
>> echo 0 > /proc/sys/vm/mmap_min_addr
>>
>> because they want to map things at address 0, so this isn't a new concept.
>>
>
> I think
On 2014-05-07 19:09 +0200, H. Peter Anvin wrote:
On 05/07/2014 09:57 AM, Linus Torvalds wrote:
Afaik, 16-bit programs under wine already need
echo 0 /proc/sys/vm/mmap_min_addr
because they want to map things at address 0, so this isn't a new concept.
I think that applies to
Actually it could use KVM instead of CPU emulation on nearly all modern
processors...
On May 7, 2014 11:43:59 PM PDT, Sven Joachim svenj...@gmx.de wrote:
On 2014-05-07 19:09 +0200, H. Peter Anvin wrote:
On 05/07/2014 09:57 AM, Linus Torvalds wrote:
Afaik, 16-bit programs under wine already
On 05/08/2014 06:50 AM, H. Peter Anvin wrote:
Actually it could use KVM instead of CPU emulation on nearly all modern
processors...
Of course, at that point you might just run qemu-kvm instead of DOSEMU,
since I seem to recall that DOSEMU is still a real version of DOS. I
have to admit to
On 05/08/2014 06:50 AM, H. Peter Anvin wrote:
Actually it could use KVM instead of CPU emulation on nearly all modern
processors...
That being said, it would be cool if someone would either port the
lredir backend (MFS) into Qemu, or finish the 9P front end I started
writing at one point, but
"H. Peter Anvin" writes:
> On 05/07/2014 09:57 AM, Linus Torvalds wrote:
>>
>> Afaik, 16-bit programs under wine already need
>>
>> echo 0 > /proc/sys/vm/mmap_min_addr
>>
>> because they want to map things at address 0, so this isn't a new concept.
>>
>
> I think that applies to DOSEMU,
On 05/07/2014 09:57 AM, Linus Torvalds wrote:
>
> Afaik, 16-bit programs under wine already need
>
> echo 0 > /proc/sys/vm/mmap_min_addr
>
> because they want to map things at address 0, so this isn't a new concept.
>
I think that applies to DOSEMU, but not to Wine.
Sven: if you have the
On Wed, May 7, 2014 at 2:18 AM, Sven Joachim wrote:
>
> It seems that at least some 32-bit programs are also broken, since after
> upgrading the kernel to 3.14.3 I can no longer start my old chess
> database program:
So for backporting (and for 3.15) maybe this (TOTALLY UNTESTED) patch
would be
On Wed, May 07, 2014 at 11:18:49AM +0200, Sven Joachim wrote:
> I would rather not set up a virtual machine just for wine (I don't
> have Windows anymore).
What about reactos? (I'm not saying this shouldn't be addressed,
regardless...)
--
Regards/Gruss,
Boris.
Sent from a fat crate under
On 2014-04-14 09:48 +0200, Alexandre Julliard wrote:
> Linus Torvalds writes:
>
>> On Fri, Apr 11, 2014 at 11:45 AM, Brian Gerst wrote:
>>>
>>> I haven't tested it recently but I do know it has worked on 64-bit
>>> kernels. There is no reason for it not to, the only thing not
>>> supported in
On 2014-04-14 09:48 +0200, Alexandre Julliard wrote:
Linus Torvalds torva...@linux-foundation.org writes:
On Fri, Apr 11, 2014 at 11:45 AM, Brian Gerst brge...@gmail.com wrote:
I haven't tested it recently but I do know it has worked on 64-bit
kernels. There is no reason for it not to, the
On Wed, May 07, 2014 at 11:18:49AM +0200, Sven Joachim wrote:
I would rather not set up a virtual machine just for wine (I don't
have Windows anymore).
What about reactos? (I'm not saying this shouldn't be addressed,
regardless...)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my
On Wed, May 7, 2014 at 2:18 AM, Sven Joachim svenj...@gmx.de wrote:
It seems that at least some 32-bit programs are also broken, since after
upgrading the kernel to 3.14.3 I can no longer start my old chess
database program:
So for backporting (and for 3.15) maybe this (TOTALLY UNTESTED)
On 05/07/2014 09:57 AM, Linus Torvalds wrote:
Afaik, 16-bit programs under wine already need
echo 0 /proc/sys/vm/mmap_min_addr
because they want to map things at address 0, so this isn't a new concept.
I think that applies to DOSEMU, but not to Wine.
Sven: if you have the ability
H. Peter Anvin h...@zytor.com writes:
On 05/07/2014 09:57 AM, Linus Torvalds wrote:
Afaik, 16-bit programs under wine already need
echo 0 /proc/sys/vm/mmap_min_addr
because they want to map things at address 0, so this isn't a new concept.
I think that applies to DOSEMU, but not
For both of these, though, it is really kind of broken that it is a global
switch, whereas typically only one application on the whole system needs it, so
it would be much better to have application-specific controls. How to do that
is another matter...
On April 14, 2014 12:27:56 AM PDT, Ingo
* Borislav Petkov wrote:
> On Mon, Apr 14, 2014 at 09:21:13AM +0200, Ingo Molnar wrote:
> > Apparently the game in question is "Exile: Escape from the pit":
> >
> > http://osdir.com/ml/wine-bugs/2014-04/msg01159.html
>
> Ah, thanks.
>
> Well, FWIW, you can get the game for free:
>
>
On Mon, Apr 14, 2014 at 09:21:13AM +0200, Ingo Molnar wrote:
> Apparently the game in question is "Exile: Escape from the pit":
>
> http://osdir.com/ml/wine-bugs/2014-04/msg01159.html
Ah, thanks.
Well, FWIW, you can get the game for free:
http://www.spiderwebsoftware.com/exile/winexile.html
Linus Torvalds writes:
> On Fri, Apr 11, 2014 at 11:45 AM, Brian Gerst wrote:
>>
>> I haven't tested it recently but I do know it has worked on 64-bit
>> kernels. There is no reason for it not to, the only thing not
>> supported in long mode is vm86. 16-bit protected mode is unchanged.
>
>
* H. Peter Anvin wrote:
> On 04/11/2014 11:41 AM, Linus Torvalds wrote:
> >
> > Ok, so you actually do this on x86-64, and it currently works? For
> > some reason I thought that 16-bit windows apps already didn't work.
> >
>
> Some will work, because not all 16-bit software care about the
* Borislav Petkov wrote:
> On Sat, Apr 12, 2014 at 05:13:40PM -0400, Brian Gerst wrote:
> > Performance is bad in general, running a 32-bit Fedora 20 guest.
>
> So this means you haven't tried the game in the guest yet, so that
> we can know for sure that a guest doesn't solve your problem or
* Borislav Petkov b...@alien8.de wrote:
On Sat, Apr 12, 2014 at 05:13:40PM -0400, Brian Gerst wrote:
Performance is bad in general, running a 32-bit Fedora 20 guest.
So this means you haven't tried the game in the guest yet, so that
we can know for sure that a guest doesn't solve your
* H. Peter Anvin h...@linux.intel.com wrote:
On 04/11/2014 11:41 AM, Linus Torvalds wrote:
Ok, so you actually do this on x86-64, and it currently works? For
some reason I thought that 16-bit windows apps already didn't work.
Some will work, because not all 16-bit software care
Linus Torvalds torva...@linux-foundation.org writes:
On Fri, Apr 11, 2014 at 11:45 AM, Brian Gerst brge...@gmail.com wrote:
I haven't tested it recently but I do know it has worked on 64-bit
kernels. There is no reason for it not to, the only thing not
supported in long mode is vm86.
On Mon, Apr 14, 2014 at 09:21:13AM +0200, Ingo Molnar wrote:
Apparently the game in question is Exile: Escape from the pit:
http://osdir.com/ml/wine-bugs/2014-04/msg01159.html
Ah, thanks.
Well, FWIW, you can get the game for free:
http://www.spiderwebsoftware.com/exile/winexile.html
I
* Borislav Petkov b...@alien8.de wrote:
On Mon, Apr 14, 2014 at 09:21:13AM +0200, Ingo Molnar wrote:
Apparently the game in question is Exile: Escape from the pit:
http://osdir.com/ml/wine-bugs/2014-04/msg01159.html
Ah, thanks.
Well, FWIW, you can get the game for free:
For both of these, though, it is really kind of broken that it is a global
switch, whereas typically only one application on the whole system needs it, so
it would be much better to have application-specific controls. How to do that
is another matter...
On April 14, 2014 12:27:56 AM PDT, Ingo
2014-04-12 15:25, H. Peter Anvin:
> On 04/12/2014 02:53 PM, Linus Torvalds wrote:
>> On Sat, Apr 12, 2014 at 12:44 PM, H. Peter Anvin wrote:
>>> Run a 32-bit VM. The 32-bit kernel does this right.
>>
>> I really don't think that's the answer.
>>
>> If people really run these 16-bit programs, we
2014-04-12 15:25, H. Peter Anvin:
On 04/12/2014 02:53 PM, Linus Torvalds wrote:
On Sat, Apr 12, 2014 at 12:44 PM, H. Peter Anvin h...@zytor.com wrote:
Run a 32-bit VM. The 32-bit kernel does this right.
I really don't think that's the answer.
If people really run these 16-bit programs, we
On 04/11/2014 02:53 PM, Andy Lutomirski wrote:
>
> If you want a fully correct solution, you can use a fancier allocation
> policy that can fit quite a few cpus per 4G :)
>
The more I think about this, I think this might actually be a reasonable
option, *IF* someone is willing to deal with
On Sat, Apr 12, 2014 at 7:56 PM, Andi Kleen wrote:
>
> Why? Either it works or it doesn't.
>
> If it works it doesn't make any sense to have a sysctl.
BS.
It "works" exactly like mmap() at NULL "works".
It is a potential security leak, because x86-64 screwed up the
architecture definition in
It leaks security sensitive information to userspace and corrupts the upper
half of ESP because it lacks the equivalent of the espfix workaround.
On April 12, 2014 7:56:48 PM PDT, Andi Kleen wrote:
>"H. Peter Anvin" writes:
>>
>> But yes, we can make it configurable, but the default should
I would think any sensible application with 16-bit segments would be using
sigaltstack. Does anyone know what Wine does?
On April 12, 2014 6:29:11 PM PDT, Andy Lutomirski wrote:
>On Sat, Apr 12, 2014 at 6:25 PM, Andy Lutomirski
>wrote:
>> On Sat, Apr 12, 2014 at 5:03 PM, H. Peter Anvin
"H. Peter Anvin" writes:
>
> But yes, we can make it configurable, but the default should almost
> certainly be off.
Why? Either it works or it doesn't.
If it works it doesn't make any sense to have a sysctl.
-Andi
--
a...@linux.intel.com -- Speaking for myself only
--
To unsubscribe from
Linus Torvalds writes:
> On Fri, Apr 11, 2014 at 11:27 AM, Brian Gerst wrote:
>> Is this bug really still present in modern CPUs? This change breaks
>> running 16-bit apps in Wine. I have a few really old games I like to
>> play on occasion, and I don't have a copy of Win 3.11 to put in a VM.
On Sat, Apr 12, 2014 at 6:25 PM, Andy Lutomirski wrote:
> On Sat, Apr 12, 2014 at 5:03 PM, H. Peter Anvin wrote:
>> A signal arriving while in the user space trampoline could seriously
>> complicate life.
>
> Agreed.
Maybe I don't agree. Have signals ever worked sensibly when delivered
to a
On Sat, Apr 12, 2014 at 5:03 PM, H. Peter Anvin wrote:
>>
>> No self modifying code... The far jump must be in the indirect form
>> anyhow. The CS:EIP must be accessible from user mode, but not
>> necessarily from compatibility mode. So the trampoline (the jump)
>> and data (CS:EIP) can live
On 04/12/2014 04:49 PM, Alexander van Heukelum wrote:
> On Sun, Apr 13, 2014, at 1:31, H. Peter Anvin wrote:
> d. Trampoline in user space
>
> A return to the vdso with values set up in registers r8-r15 would enable
> a trampoline in user space. Unfortunately there is no way
>
On Sun, Apr 13, 2014, at 1:31, H. Peter Anvin wrote:
> >>> d. Trampoline in user space
> >>>
> >>> A return to the vdso with values set up in registers r8-r15 would enable
> >>> a trampoline in user space. Unfortunately there is no way
> >>> to do a far JMP entirely with register state so this
Hi,
> This is a writeup I did to a select audience before this was public:
I'ld like to add an option d.2. for your consideration. Can you think of a
fundamental problem with it?
Greetings,
Alexander
> > Some workarounds I have considered:
> >
> > a. Using paging in a similar way to the
On 04/12/2014 04:26 PM, Alexander van Heukelum wrote:
>>>
>>> c. Trampoline in kernel space
>>>
>>> A trampoline in kernel space is not feasible since all ring transition
>>> instructions capable of returning to 16-bit mode require the use of the
>>> stack.
>
> "16 bit mode" -> "a mode with
On 04/12/2014 02:53 PM, Linus Torvalds wrote:
> On Sat, Apr 12, 2014 at 12:44 PM, H. Peter Anvin wrote:
>> Run a 32-bit VM. The 32-bit kernel does this right.
>
> I really don't think that's the answer.
>
> If people really run these 16-bit programs, we need to allow it.
> Clearly it used to
On Sat, Apr 12, 2014 at 12:44 PM, H. Peter Anvin wrote:
> Run a 32-bit VM. The 32-bit kernel does this right.
I really don't think that's the answer.
If people really run these 16-bit programs, we need to allow it.
Clearly it used to work.
Just make the unconditional "don't allow 16-bit
On Sat, Apr 12, 2014 at 05:13:40PM -0400, Brian Gerst wrote:
> Performance is bad in general, running a 32-bit Fedora 20 guest.
So this means you haven't tried the game in the guest yet, so that we
can know for sure that a guest doesn't solve your problem or what?
Btw, which game is that and can
On Sat, Apr 12, 2014 at 4:59 PM, Borislav Petkov wrote:
> On Sat, Apr 12, 2014 at 04:34:14PM -0400, Brian Gerst wrote:
>> My experience with kvm so far is that is slow and clunky. It may be OK
>> for a server environment, but interactively it's difficult to use.
>
> Are you saying, you've run
On Sat, Apr 12, 2014 at 04:34:14PM -0400, Brian Gerst wrote:
> My experience with kvm so far is that is slow and clunky. It may be OK
> for a server environment, but interactively it's difficult to use.
Are you saying, you've run your game in a guest and perf. is sucky?
--
Regards/Gruss,
On Sat, Apr 12, 2014 at 4:11 PM, Borislav Petkov wrote:
> On Sat, Apr 12, 2014 at 12:44:42PM -0700, H. Peter Anvin wrote:
>> Run a 32-bit VM. The 32-bit kernel does this right.
>
> Yes, even better.
>
>> I suspect it would also work fine in a Qemu user mode guest (is
>> this supported by KVM?),
For this particular game, not 16-bit in general. The installer, also
16-bit, runs perfectly. Already filed wine bug 35977.
On Sat, Apr 12, 2014 at 1:18 PM, H. Peter Anvin wrote:
> So Wine regressed and noone noticed? They doesn't sound like an active user
> base.
>
> On April 11, 2014
On Sat, Apr 12, 2014 at 12:44:42PM -0700, H. Peter Anvin wrote:
> Run a 32-bit VM. The 32-bit kernel does this right.
Yes, even better.
> I suspect it would also work fine in a Qemu user mode guest (is
> this supported by KVM?), in a ReactOS VM, or some other number of
> combinations.
Right.
Run a 32-bit VM. The 32-bit kernel does this right.
I suspect it would also work fine in a Qemu user mode guest (is this supported
by KVM?), in a ReactOS VM, or some other number of combinations.
The real question is how many real users are actually affected.
On April 12, 2014 12:35:41 PM
On Sat, Apr 12, 2014 at 10:18:25AM -0700, H. Peter Anvin wrote:
> So Wine regressed and noone noticed? They doesn't sound like an active
> user base.
Btw, wouldn't this obscure use case simply work in a KVM guest with a
kernel <= 3.14?
Because if so, we simply cut it at 3.14, everything newer
So Wine regressed and noone noticed? They doesn't sound like an active user
base.
On April 11, 2014 9:44:22 PM PDT, Brian Gerst wrote:
>On Fri, Apr 11, 2014 at 2:50 PM, Linus Torvalds
> wrote:
>> On Fri, Apr 11, 2014 at 11:45 AM, Brian Gerst
>wrote:
>>>
>>> I haven't tested it recently but I
So Wine regressed and noone noticed? They doesn't sound like an active user
base.
On April 11, 2014 9:44:22 PM PDT, Brian Gerst brge...@gmail.com wrote:
On Fri, Apr 11, 2014 at 2:50 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Fri, Apr 11, 2014 at 11:45 AM, Brian Gerst
On Sat, Apr 12, 2014 at 10:18:25AM -0700, H. Peter Anvin wrote:
So Wine regressed and noone noticed? They doesn't sound like an active
user base.
Btw, wouldn't this obscure use case simply work in a KVM guest with a
kernel = 3.14?
Because if so, we simply cut it at 3.14, everything newer has
Run a 32-bit VM. The 32-bit kernel does this right.
I suspect it would also work fine in a Qemu user mode guest (is this supported
by KVM?), in a ReactOS VM, or some other number of combinations.
The real question is how many real users are actually affected.
On April 12, 2014 12:35:41 PM
On Sat, Apr 12, 2014 at 12:44:42PM -0700, H. Peter Anvin wrote:
Run a 32-bit VM. The 32-bit kernel does this right.
Yes, even better.
I suspect it would also work fine in a Qemu user mode guest (is
this supported by KVM?), in a ReactOS VM, or some other number of
combinations.
Right.
So
For this particular game, not 16-bit in general. The installer, also
16-bit, runs perfectly. Already filed wine bug 35977.
On Sat, Apr 12, 2014 at 1:18 PM, H. Peter Anvin h...@zytor.com wrote:
So Wine regressed and noone noticed? They doesn't sound like an active user
base.
On April 11,
On Sat, Apr 12, 2014 at 4:11 PM, Borislav Petkov b...@alien8.de wrote:
On Sat, Apr 12, 2014 at 12:44:42PM -0700, H. Peter Anvin wrote:
Run a 32-bit VM. The 32-bit kernel does this right.
Yes, even better.
I suspect it would also work fine in a Qemu user mode guest (is
this supported by
On Sat, Apr 12, 2014 at 04:34:14PM -0400, Brian Gerst wrote:
My experience with kvm so far is that is slow and clunky. It may be OK
for a server environment, but interactively it's difficult to use.
Are you saying, you've run your game in a guest and perf. is sucky?
--
Regards/Gruss,
On Sat, Apr 12, 2014 at 4:59 PM, Borislav Petkov b...@alien8.de wrote:
On Sat, Apr 12, 2014 at 04:34:14PM -0400, Brian Gerst wrote:
My experience with kvm so far is that is slow and clunky. It may be OK
for a server environment, but interactively it's difficult to use.
Are you saying, you've
On Sat, Apr 12, 2014 at 05:13:40PM -0400, Brian Gerst wrote:
Performance is bad in general, running a 32-bit Fedora 20 guest.
So this means you haven't tried the game in the guest yet, so that we
can know for sure that a guest doesn't solve your problem or what?
Btw, which game is that and can
On Sat, Apr 12, 2014 at 12:44 PM, H. Peter Anvin h...@zytor.com wrote:
Run a 32-bit VM. The 32-bit kernel does this right.
I really don't think that's the answer.
If people really run these 16-bit programs, we need to allow it.
Clearly it used to work.
Just make the unconditional don't allow
On 04/12/2014 02:53 PM, Linus Torvalds wrote:
On Sat, Apr 12, 2014 at 12:44 PM, H. Peter Anvin h...@zytor.com wrote:
Run a 32-bit VM. The 32-bit kernel does this right.
I really don't think that's the answer.
If people really run these 16-bit programs, we need to allow it.
Clearly it
On 04/12/2014 04:26 PM, Alexander van Heukelum wrote:
c. Trampoline in kernel space
A trampoline in kernel space is not feasible since all ring transition
instructions capable of returning to 16-bit mode require the use of the
stack.
16 bit mode - a mode with 16-bit stack
Yes... I
Hi,
This is a writeup I did to a select audience before this was public:
I'ld like to add an option d.2. for your consideration. Can you think of a
fundamental problem with it?
Greetings,
Alexander
Some workarounds I have considered:
a. Using paging in a similar way to the 32-bit
On Sun, Apr 13, 2014, at 1:31, H. Peter Anvin wrote:
d. Trampoline in user space
A return to the vdso with values set up in registers r8-r15 would enable
a trampoline in user space. Unfortunately there is no way
to do a far JMP entirely with register state so this would require
On 04/12/2014 04:49 PM, Alexander van Heukelum wrote:
On Sun, Apr 13, 2014, at 1:31, H. Peter Anvin wrote:
d. Trampoline in user space
A return to the vdso with values set up in registers r8-r15 would enable
a trampoline in user space. Unfortunately there is no way
to do a far JMP entirely
On Sat, Apr 12, 2014 at 5:03 PM, H. Peter Anvin h...@zytor.com wrote:
No self modifying code... The far jump must be in the indirect form
anyhow. The CS:EIP must be accessible from user mode, but not
necessarily from compatibility mode. So the trampoline (the jump)
and data (CS:EIP) can live
On Sat, Apr 12, 2014 at 6:25 PM, Andy Lutomirski l...@amacapital.net wrote:
On Sat, Apr 12, 2014 at 5:03 PM, H. Peter Anvin h...@zytor.com wrote:
A signal arriving while in the user space trampoline could seriously
complicate life.
Agreed.
Maybe I don't agree. Have signals ever worked
Linus Torvalds torva...@linux-foundation.org writes:
On Fri, Apr 11, 2014 at 11:27 AM, Brian Gerst brge...@gmail.com wrote:
Is this bug really still present in modern CPUs? This change breaks
running 16-bit apps in Wine. I have a few really old games I like to
play on occasion, and I don't
H. Peter Anvin h...@zytor.com writes:
But yes, we can make it configurable, but the default should almost
certainly be off.
Why? Either it works or it doesn't.
If it works it doesn't make any sense to have a sysctl.
-Andi
--
a...@linux.intel.com -- Speaking for myself only
--
To
I would think any sensible application with 16-bit segments would be using
sigaltstack. Does anyone know what Wine does?
On April 12, 2014 6:29:11 PM PDT, Andy Lutomirski l...@amacapital.net wrote:
On Sat, Apr 12, 2014 at 6:25 PM, Andy Lutomirski l...@amacapital.net
wrote:
On Sat, Apr 12, 2014
It leaks security sensitive information to userspace and corrupts the upper
half of ESP because it lacks the equivalent of the espfix workaround.
On April 12, 2014 7:56:48 PM PDT, Andi Kleen a...@firstfloor.org wrote:
H. Peter Anvin h...@zytor.com writes:
But yes, we can make it configurable,
On Sat, Apr 12, 2014 at 7:56 PM, Andi Kleen a...@firstfloor.org wrote:
Why? Either it works or it doesn't.
If it works it doesn't make any sense to have a sysctl.
BS.
It works exactly like mmap() at NULL works.
It is a potential security leak, because x86-64 screwed up the
architecture
On 04/11/2014 02:53 PM, Andy Lutomirski wrote:
If you want a fully correct solution, you can use a fancier allocation
policy that can fit quite a few cpus per 4G :)
The more I think about this, I think this might actually be a reasonable
option, *IF* someone is willing to deal with actually
On Fri, Apr 11, 2014 at 2:50 PM, Linus Torvalds
wrote:
> On Fri, Apr 11, 2014 at 11:45 AM, Brian Gerst wrote:
>>
>> I haven't tested it recently but I do know it has worked on 64-bit
>> kernels. There is no reason for it not to, the only thing not
>> supported in long mode is vm86. 16-bit
On 04/11/2014 03:15 PM, Andy Lutomirski wrote:
>
> I just looked up my hideous code. I was doing this to test the
> now-deleted int 0xcc vsyscall stuff. I used modify_ldt because either
> I didn't realize that __USER32_CS was usable or I didn't think it was
> ABI. Or I was just being silly.
>
On Fri, Apr 11, 2014 at 2:59 PM, H. Peter Anvin wrote:
> On 04/11/2014 02:53 PM, Andy Lutomirski wrote:
>>
>> How big of a functionality problem is it? Apparently it doesn't break
>> 16-bit code on wine.
>>
>
> It breaks *some* 16-bit code. This is actually the reason that 32 bits
> has the
On 04/11/2014 02:53 PM, Andy Lutomirski wrote:
>
> How big of a functionality problem is it? Apparently it doesn't break
> 16-bit code on wine.
>
It breaks *some* 16-bit code. This is actually the reason that 32 bits
has the espfix workaround - it wasn't identified as an infoleak at the time.
On 04/11/2014 02:24 PM, H. Peter Anvin wrote:
> On 04/11/2014 02:16 PM, Andy Lutomirski wrote:
>> I wonder if there's an easy-ish good-enough fix:
>>
>> Allocate some percpu space in the fixmap. (OK, this is ugly, but
>> kvmclock already does it, so it's possible.) To return to 16-bit
>>
On Fri, Apr 11, 2014 at 2:16 PM, Andy Lutomirski wrote:
>
> I wonder if there's an easy-ish good-enough fix:
Heh. Yes. Check the thread on lkml about three weeks ago under the
subject "x86-64: Information leak: kernel stack address leaks to user
space". It had exactly that as a suggestion.
On 04/11/2014 02:16 PM, Andy Lutomirski wrote:
> On 04/11/2014 11:29 AM, H. Peter Anvin wrote:
>> On 04/11/2014 11:27 AM, Brian Gerst wrote:
>>> Is this bug really still present in modern CPUs? This change breaks
>>> running 16-bit apps in Wine. I have a few really old games I like to
>>> play
On 04/11/2014 11:29 AM, H. Peter Anvin wrote:
> On 04/11/2014 11:27 AM, Brian Gerst wrote:
>> Is this bug really still present in modern CPUs? This change breaks
>> running 16-bit apps in Wine. I have a few really old games I like to
>> play on occasion, and I don't have a copy of Win 3.11 to
On Fri, Apr 11, 2014 at 11:45 AM, Brian Gerst wrote:
>
> I haven't tested it recently but I do know it has worked on 64-bit
> kernels. There is no reason for it not to, the only thing not
> supported in long mode is vm86. 16-bit protected mode is unchanged.
Afaik 64-bit windows doesn't support
On 04/11/2014 11:41 AM, Linus Torvalds wrote:
>
> Ok, so you actually do this on x86-64, and it currently works? For
> some reason I thought that 16-bit windows apps already didn't work.
>
Some will work, because not all 16-bit software care about the upper
half of ESP getting randomly
On Fri, Apr 11, 2014 at 2:41 PM, Linus Torvalds
wrote:
> On Fri, Apr 11, 2014 at 11:27 AM, Brian Gerst wrote:
>> Is this bug really still present in modern CPUs? This change breaks
>> running 16-bit apps in Wine. I have a few really old games I like to
>> play on occasion, and I don't have a
On Fri, Apr 11, 2014 at 11:27 AM, Brian Gerst wrote:
> Is this bug really still present in modern CPUs? This change breaks
> running 16-bit apps in Wine. I have a few really old games I like to
> play on occasion, and I don't have a copy of Win 3.11 to put in a VM.
Ok, so you actually do this
On Fri, Apr 11, 2014 at 2:29 PM, H. Peter Anvin wrote:
> On 04/11/2014 11:27 AM, Brian Gerst wrote:
>> Is this bug really still present in modern CPUs? This change breaks
>> running 16-bit apps in Wine. I have a few really old games I like to
>> play on occasion, and I don't have a copy of Win
On 04/11/2014 11:27 AM, Brian Gerst wrote:
> Is this bug really still present in modern CPUs? This change breaks
> running 16-bit apps in Wine. I have a few really old games I like to
> play on occasion, and I don't have a copy of Win 3.11 to put in a VM.
It is not a bug, per se, but an
Is this bug really still present in modern CPUs? This change breaks
running 16-bit apps in Wine. I have a few really old games I like to
play on occasion, and I don't have a copy of Win 3.11 to put in a VM.
On Fri, Apr 11, 2014 at 1:36 PM, tip-bot for H. Peter Anvin
wrote:
> Commit-ID:
On 04/11/2014 11:12 AM, Andy Lutomirski wrote:
>
> If this is what I think it is (hi, Spender), then it is probably only
> useful for 3.14.y and not earlier kernels.
>
Not really. The kernel stack address is sensitive regardless of kASLR;
in fact, it is completely orthogonal to kASLR.
On 04/11/2014 10:36 AM, tip-bot for H. Peter Anvin wrote:
> Commit-ID: b3b42ac2cbae1f3cecbb6229964a4d48af31d382
> Gitweb: http://git.kernel.org/tip/b3b42ac2cbae1f3cecbb6229964a4d48af31d382
> Author: H. Peter Anvin
> AuthorDate: Sun, 16 Mar 2014 15:31:54 -0700
> Committer: H. Peter Anvin
Commit-ID: b3b42ac2cbae1f3cecbb6229964a4d48af31d382
Gitweb: http://git.kernel.org/tip/b3b42ac2cbae1f3cecbb6229964a4d48af31d382
Author: H. Peter Anvin
AuthorDate: Sun, 16 Mar 2014 15:31:54 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 11 Apr 2014 10:10:09 -0700
x86-64, modify_ldt:
1 - 100 of 118 matches
Mail list logo
