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 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
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 mo
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 that
"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, but
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 ab
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 a
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 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 l
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:
>
> http:/
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.
>
> Afa
* 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 upp
* 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
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 n
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 actua
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 th
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 almo
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
>wrote
"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 thi
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 tas
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 prett
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 wou
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
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
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 wo
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 segmen
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 your
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,
Bor
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?), i
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 9:44:22
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.
S
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 PDT,
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
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 do
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 prote
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 espf
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
>> userspac
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.
Anywa
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
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 put
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 corrupted
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 co
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 o
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 3
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 architec
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: b3b42ac
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: Ba
59 matches
Mail list logo
