Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
04.04.2017 05:05, Ricardo Neri пишет: On Sat, 2017-04-01 at 16:08 +0300, Stas Sergeev wrote: 30.03.2017 08:14, Ricardo Neri пишет: You know the wine's requirements now - they are very small. And dosemu doesn't need anything at all but smsw. And even smsw is very rare. But emulation is still needed for SMSW, right? Likely so. If you want, I can enable the logging of this command and see if it is used by some of the DOS programs I have. It would be great if you could do that, if you don't mind. OK, scheduled to the week-end. I'll let you know. Thanks! OK, done the testing. It appears smsw is used in v86 by windows-3.1 and dos4gw at the very least, and these are the "major" apps. So doing without a fixup in v86 will not go unnoticed. Unfortunately this also means that KVM-vm86 should be properly tested. I have also found a weird program that does SGDT under v86. This causes "ERROR: SGDT not implemented" under dosemu, but the prog still works fine as it obviously does not care about the results. This app can easily be broken of course, if that makes any sense (likely not). Thanks for inputs! Then it seems that we will need emulation for sgdt and smsw. I wouldn't claim we need an emulation of sgdt. One or 2 exotic apps do not count much, considering the overall small usage of dosemu and an easiness of re-adding them to dosemu itself. So if it makes any sense to not add it for vm86, then please leave it omitted. However it seems Andy wants an overall completeness here, lot let me just say I'll be fine with either option. Perhaps sidt? If only for overall completeness. If it makes any sense to, please leave it omitted. sldt and str will not need emulation in either protected mode or virtual-8086 mode. At a later stage I can look into working in the syscall as Andy proposes. I will also look into the kvm-v86 path for dosemu2. It seems we have an agreement :) Do we? Yes, fine with me. -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
Ricardo Neriwrites: > On Fri, 2017-03-31 at 16:11 +0200, Alexandre Julliard wrote: >> Ricardo Neri writes: >> >> > On Thu, 2017-03-30 at 13:10 +0300, Stas Sergeev wrote: >> >> 30.03.2017 08:14, Ricardo Neri пишет: >> >> In fact, smsw has an interesting property, which is that >> >> no one will ever want to disable its in-kernel emulation >> >> to provide its own. >> >> So while I'll try to estimate its usage, emulating it in kernel >> >> will not be that problematic in either case. >> > >> > Ah good to know! >> > >> >> As for protected mode, if wine only needs sgdt/sidt, then >> >> again, no one will want to disable its emulation. Not the >> >> case with sldt, but AFAICS wine doesn't need sldt, and so >> >> we can leave sldt without a fixups. Is my understanding >> >> correct? >> > >> > This is my understanding as well. I could not find any use of sldt in >> > wine. Alexandre, would you mind confirming? >> >> Some versions of the Themida software protection are known to use sldt >> as part of the virtual machine detection code [1]. The check currently >> fails because it expects the LDT to be zero, so the app is already >> broken, but sldt segfaulting would still cause a crash where there >> wasn't one before. >> >> However, I'm only aware of one application using this, and being able to >> catch and emulate sldt ourselves would actually give us a chance to fix >> this app in newer Wine versions, so I'm not opposed to having it >> segfault. > > Great! Then this is in line with what we are aiming to do with dosemu2: > not emulate str and sldt. >> >> In fact it would be nice to be able to make sidt/sgdt/etc. segfault >> too. I know a new syscall is a pain, but as far as Wine is concerned, >> being able to opt out from any emulation would be potentially useful. > > I see. I guess for now there should not be a problem with emulating > sidt/sgdt/smsw, right? In this way we don't break current versions of > winehq and programs using it. In a phase two we can introduce the > syscall so that kernel fixups can be disabled. Does this make sense? Yes, that makes sense. -- Alexandre Julliard julli...@winehq.org -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Fri, 2017-03-31 at 16:11 +0200, Alexandre Julliard wrote: > Ricardo Neriwrites: > > > On Thu, 2017-03-30 at 13:10 +0300, Stas Sergeev wrote: > >> 30.03.2017 08:14, Ricardo Neri пишет: > >> But at least dosemu implements it, so probably it is needed. > >> >>> Right. > >> >>> > >> Of course if it is used by one of 100 DOS progs, then there > >> is an option to just add its support to dosemu2 and pretend > >> the compatibility problems did not exist. :) > >> >>> Do you mean relaying the GP fault to dosemu instead of trapping it and > >> >>> emulating it in the kernel? > >> >> Yes, that would be optimal if this does not severely break > >> >> the current setups. If we can find out that smsw is not in > >> >> the real use, we can probably do exactly that. > >> >> But other > >> >> instructions are not in real use in v86 for sure, so I > >> >> wouldn't be adding the explicit test-cases to the kernel > >> >> that will make you depend on some particular behaviour > >> >> that no one may need. > >> >> My objection was that we shouldn't > >> >> write tests before we know exactly how we want this to work. > >> > OK, if only SMSW is used then I'll keep the emulation for SMSW only. > >> In fact, smsw has an interesting property, which is that > >> no one will ever want to disable its in-kernel emulation > >> to provide its own. > >> So while I'll try to estimate its usage, emulating it in kernel > >> will not be that problematic in either case. > > > > Ah good to know! > > > >> As for protected mode, if wine only needs sgdt/sidt, then > >> again, no one will want to disable its emulation. Not the > >> case with sldt, but AFAICS wine doesn't need sldt, and so > >> we can leave sldt without a fixups. Is my understanding > >> correct? > > > > This is my understanding as well. I could not find any use of sldt in > > wine. Alexandre, would you mind confirming? > > Some versions of the Themida software protection are known to use sldt > as part of the virtual machine detection code [1]. The check currently > fails because it expects the LDT to be zero, so the app is already > broken, but sldt segfaulting would still cause a crash where there > wasn't one before. > > However, I'm only aware of one application using this, and being able to > catch and emulate sldt ourselves would actually give us a chance to fix > this app in newer Wine versions, so I'm not opposed to having it > segfault. Great! Then this is in line with what we are aiming to do with dosemu2: not emulate str and sldt. > > In fact it would be nice to be able to make sidt/sgdt/etc. segfault > too. I know a new syscall is a pain, but as far as Wine is concerned, > being able to opt out from any emulation would be potentially useful. I see. I guess for now there should not be a problem with emulating sidt/sgdt/smsw, right? In this way we don't break current versions of winehq and programs using it. In a phase two we can introduce the syscall so that kernel fixups can be disabled. Does this make sense? Thanks and BR, Ricardo -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
,linux-msdos@vger.kernel.org,wine-de...@winehq.org From: h...@zytor.com Message-ID: <3fd12652-aa83-4d73-9914-bba089e58...@zytor.com> On April 1, 2017 6:08:43 AM PDT, Stas Sergeev wrote: >30.03.2017 08:14, Ricardo Neri пишет: >>> You know the wine's >>> requirements now - they are very small. And >>> dosemu doesn't need anything at all but smsw. >>> And even smsw is very rare. >> But emulation is still needed for SMSW, right? > Likely so. > If you want, I can enable the logging of this command > and see if it is used by some of the DOS programs I have. It would be great if you could do that, if you don't mind. >>> OK, scheduled to the week-end. >>> I'll let you know. >> Thanks! >OK, done the testing. >It appears smsw is used in v86 by windows-3.1 and dos4gw >at the very least, and these are the "major" apps. So doing >without a fixup in v86 will not go unnoticed. Unfortunately >this also means that KVM-vm86 should be properly tested. >I have also found a weird program that does SGDT under >v86. This causes "ERROR: SGDT not implemented" under >dosemu, but the prog still works fine as it obviously does >not care about the results. This app can easily be broken >of course, if that makes any sense (likely not). Using SMSW to detect v86 mode is relatively common. pushf hides the VM flag, but SMSW is available, providing the v86 virtualization hole. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
30.03.2017 08:14, Ricardo Neri пишет: You know the wine's requirements now - they are very small. And dosemu doesn't need anything at all but smsw. And even smsw is very rare. But emulation is still needed for SMSW, right? Likely so. If you want, I can enable the logging of this command and see if it is used by some of the DOS programs I have. It would be great if you could do that, if you don't mind. OK, scheduled to the week-end. I'll let you know. Thanks! OK, done the testing. It appears smsw is used in v86 by windows-3.1 and dos4gw at the very least, and these are the "major" apps. So doing without a fixup in v86 will not go unnoticed. Unfortunately this also means that KVM-vm86 should be properly tested. I have also found a weird program that does SGDT under v86. This causes "ERROR: SGDT not implemented" under dosemu, but the prog still works fine as it obviously does not care about the results. This app can easily be broken of course, if that makes any sense (likely not). -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Fri, Mar 31, 2017 at 2:26 PM, Stas Sergeevwrote: > 31.03.2017 17:11, Alexandre Julliard пишет: >> >> In fact it would be nice to be able to make sidt/sgdt/etc. segfault >> too. I know a new syscall is a pain, > > Maybe arch_prctl() then? I still like my idea of a generic mechanism to turn off backwards-compatibility things. After all, hardened programs should turn off UMIP fixups entirely. They should also turn off vsyscall emulation entirely, and I see no reason that these mechanisms should be different. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
31.03.2017 17:11, Alexandre Julliard пишет: In fact it would be nice to be able to make sidt/sgdt/etc. segfault too. I know a new syscall is a pain, Maybe arch_prctl() then? -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
Ricardo Neriwrites: > On Thu, 2017-03-30 at 13:10 +0300, Stas Sergeev wrote: >> 30.03.2017 08:14, Ricardo Neri пишет: >> But at least dosemu implements it, so probably it is needed. >> >>> Right. >> >>> >> Of course if it is used by one of 100 DOS progs, then there >> is an option to just add its support to dosemu2 and pretend >> the compatibility problems did not exist. :) >> >>> Do you mean relaying the GP fault to dosemu instead of trapping it and >> >>> emulating it in the kernel? >> >> Yes, that would be optimal if this does not severely break >> >> the current setups. If we can find out that smsw is not in >> >> the real use, we can probably do exactly that. >> >> But other >> >> instructions are not in real use in v86 for sure, so I >> >> wouldn't be adding the explicit test-cases to the kernel >> >> that will make you depend on some particular behaviour >> >> that no one may need. >> >> My objection was that we shouldn't >> >> write tests before we know exactly how we want this to work. >> > OK, if only SMSW is used then I'll keep the emulation for SMSW only. >> In fact, smsw has an interesting property, which is that >> no one will ever want to disable its in-kernel emulation >> to provide its own. >> So while I'll try to estimate its usage, emulating it in kernel >> will not be that problematic in either case. > > Ah good to know! > >> As for protected mode, if wine only needs sgdt/sidt, then >> again, no one will want to disable its emulation. Not the >> case with sldt, but AFAICS wine doesn't need sldt, and so >> we can leave sldt without a fixups. Is my understanding >> correct? > > This is my understanding as well. I could not find any use of sldt in > wine. Alexandre, would you mind confirming? Some versions of the Themida software protection are known to use sldt as part of the virtual machine detection code [1]. The check currently fails because it expects the LDT to be zero, so the app is already broken, but sldt segfaulting would still cause a crash where there wasn't one before. However, I'm only aware of one application using this, and being able to catch and emulate sldt ourselves would actually give us a chance to fix this app in newer Wine versions, so I'm not opposed to having it segfault. In fact it would be nice to be able to make sidt/sgdt/etc. segfault too. I know a new syscall is a pain, but as far as Wine is concerned, being able to opt out from any emulation would be potentially useful. [1] https://www.winehq.org/pipermail/wine-bugs/2008-February/094470.html -- Alexandre Julliard julli...@winehq.org -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Thu, 2017-03-30 at 13:10 +0300, Stas Sergeev wrote: > 30.03.2017 08:14, Ricardo Neri пишет: > But at least dosemu implements it, so probably it is needed. > >>> Right. > >>> > Of course if it is used by one of 100 DOS progs, then there > is an option to just add its support to dosemu2 and pretend > the compatibility problems did not exist. :) > >>> Do you mean relaying the GP fault to dosemu instead of trapping it and > >>> emulating it in the kernel? > >> Yes, that would be optimal if this does not severely break > >> the current setups. If we can find out that smsw is not in > >> the real use, we can probably do exactly that. > >> But other > >> instructions are not in real use in v86 for sure, so I > >> wouldn't be adding the explicit test-cases to the kernel > >> that will make you depend on some particular behaviour > >> that no one may need. > >> My objection was that we shouldn't > >> write tests before we know exactly how we want this to work. > > OK, if only SMSW is used then I'll keep the emulation for SMSW only. > In fact, smsw has an interesting property, which is that > no one will ever want to disable its in-kernel emulation > to provide its own. > So while I'll try to estimate its usage, emulating it in kernel > will not be that problematic in either case. Ah good to know! > As for protected mode, if wine only needs sgdt/sidt, then > again, no one will want to disable its emulation. Not the > case with sldt, but AFAICS wine doesn't need sldt, and so > we can leave sldt without a fixups. Is my understanding > correct? This is my understanding as well. I could not find any use of sldt in wine. Alexandre, would you mind confirming? > In this case, I suppose, we are very well on a way to avoid > the extra syscalls to toggle the emulation features. Great! Then I will keep the emulation for sgdt, sidt, and smsw but not for str and sldt; for both vm86 and protected mode. This seems to be the agreement. Thanks and BR, Ricardo -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
30.03.2017 08:14, Ricardo Neri пишет: But at least dosemu implements it, so probably it is needed. Right. Of course if it is used by one of 100 DOS progs, then there is an option to just add its support to dosemu2 and pretend the compatibility problems did not exist. :) Do you mean relaying the GP fault to dosemu instead of trapping it and emulating it in the kernel? Yes, that would be optimal if this does not severely break the current setups. If we can find out that smsw is not in the real use, we can probably do exactly that. But other instructions are not in real use in v86 for sure, so I wouldn't be adding the explicit test-cases to the kernel that will make you depend on some particular behaviour that no one may need. My objection was that we shouldn't write tests before we know exactly how we want this to work. OK, if only SMSW is used then I'll keep the emulation for SMSW only. In fact, smsw has an interesting property, which is that no one will ever want to disable its in-kernel emulation to provide its own. So while I'll try to estimate its usage, emulating it in kernel will not be that problematic in either case. As for protected mode, if wine only needs sgdt/sidt, then again, no one will want to disable its emulation. Not the case with sldt, but AFAICS wine doesn't need sldt, and so we can leave sldt without a fixups. Is my understanding correct? In this case, I suppose, we are very well on a way to avoid the extra syscalls to toggle the emulation features. -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Wed, 2017-03-29 at 23:55 +0300, Stas Sergeev wrote: > 29.03.2017 07:38, Ricardo Neri пишет: > >> Probably you could also remove > >> the sldt and str emulation for protected mode, because, > >> as I understand from this thread, wine does not > >> need those. > > I see. I would lean on keeping the emulation because I already > > implemented it :), for completeness, and because it is performed in a > > single switch. The bulk of the emulation code deals with operands. > But this is not for free. > As Andy said, you will then need a syscall and > a feature mask to be able to disable this emulation. > And AFAIK you haven't implemented that yet, so > there is something to consider. Right, I see your point. > You know the wine's > requirements now - they are very small. And > dosemu doesn't need anything at all but smsw. > And even smsw is very rare. > >>> But emulation is still needed for SMSW, right? > >> Likely so. > >> If you want, I can enable the logging of this command > >> and see if it is used by some of the DOS programs I have. > > It would be great if you could do that, if you don't mind. > OK, scheduled to the week-end. > I'll let you know. Thanks! > > >> But at least dosemu implements it, so probably it is needed. > > Right. > > > >> Of course if it is used by one of 100 DOS progs, then there > >> is an option to just add its support to dosemu2 and pretend > >> the compatibility problems did not exist. :) > > Do you mean relaying the GP fault to dosemu instead of trapping it and > > emulating it in the kernel? > Yes, that would be optimal if this does not severely break > the current setups. If we can find out that smsw is not in > the real use, we can probably do exactly that. > But other > instructions are not in real use in v86 for sure, so I > wouldn't be adding the explicit test-cases to the kernel > that will make you depend on some particular behaviour > that no one may need. > My objection was that we shouldn't > write tests before we know exactly how we want this to work. OK, if only SMSW is used then I'll keep the emulation for SMSW only. -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
11.03.2017 02:59, Ricardo Neri пишет: On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote: Why would you need one? Or do you really want to allow these instructions in v86 by the means of emulation? If so - this wasn't clearly stated in the patch description, neither it was properly discussed, it seems. It str and sldt can be emulated in vm86 but as Andy mention, the behavior sould be the same with and without emulation. Why would you do that? I looked up the dosemu2 CPU simulator code that is used under x86-64. It says this: --- CODE_FLUSH(); if (REALMODE()) goto illegal_op; PC += ModRMSim(PC+1, mode) + 1; error("SLDT not implemented\n"); break; case 1: /* STR */ /* Store Task Register */ CODE_FLUSH(); if (REALMODE()) goto illegal_op; PC += ModRMSim(PC+1, mode) + 1; error("STR not implemented\n"); break; ... case 0: /* SGDT */ /* Store Global Descriptor Table Register */ PC++; PC += ModRM(opc, PC, mode|DATA16|MSTORE); error("SGDT not implemented\n"); break; case 1: /* SIDT */ /* Store Interrupt Descriptor Table Register */ PC++; PC += ModRM(opc, PC, mode|DATA16|MSTORE); error("SIDT not implemented\n"); break; --- It only implements smsw. So maybe you can make your code much simpler and remove the unneeded emulation? Same is for prot mode. You know the wine's requirements now - they are very small. And dosemu doesn't need anything at all but smsw. And even smsw is very rare. -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
29.03.2017 07:38, Ricardo Neri пишет: Probably you could also remove the sldt and str emulation for protected mode, because, as I understand from this thread, wine does not need those. I see. I would lean on keeping the emulation because I already implemented it :), for completeness, and because it is performed in a single switch. The bulk of the emulation code deals with operands. But this is not for free. As Andy said, you will then need a syscall and a feature mask to be able to disable this emulation. And AFAIK you haven't implemented that yet, so there is something to consider. You know the wine's requirements now - they are very small. And dosemu doesn't need anything at all but smsw. And even smsw is very rare. But emulation is still needed for SMSW, right? Likely so. If you want, I can enable the logging of this command and see if it is used by some of the DOS programs I have. It would be great if you could do that, if you don't mind. OK, scheduled to the week-end. I'll let you know. But at least dosemu implements it, so probably it is needed. Right. Of course if it is used by one of 100 DOS progs, then there is an option to just add its support to dosemu2 and pretend the compatibility problems did not exist. :) Do you mean relaying the GP fault to dosemu instead of trapping it and emulating it in the kernel? Yes, that would be optimal if this does not severely break the current setups. If we can find out that smsw is not in the real use, we can probably do exactly that. But other instructions are not in real use in v86 for sure, so I wouldn't be adding the explicit test-cases to the kernel that will make you depend on some particular behaviour that no one may need. My objection was that we shouldn't write tests before we know exactly how we want this to work. -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Tue, 2017-03-28 at 12:38 +0300, Stas Sergeev wrote: > 28.03.2017 02:46, Ricardo Neri пишет: > > On Tue, 2017-03-14 at 00:25 +0300, Stas Sergeev wrote: > >> 11.03.2017 02:59, Ricardo Neri пишет: > >>> On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote: > >>> > Why would you need one? > Or do you really want to allow these instructions > in v86 by the means of emulation? If so - this wasn't > clearly stated in the patch description, neither it was > properly discussed, it seems. > >>> It str and sldt can be emulated in vm86 but as Andy mention, the > >>> behavior sould be the same with and without emulation. > >> Why would you do that? > >> I looked up the dosemu2 CPU simulator code that > >> is used under x86-64. It says this: > > Stas, I apologize for the delayed reply; I missed your e-mail. > >> It only implements smsw. > >> So maybe you can make your code much > >> simpler and remove the unneeded emulation? > >> Same is for prot mode. > > Do you mean the unneeded emulation for SLDT and STR? > Not quite, I meant also sgdt and sidt in vm86. > Yes that it will be a somewhat "incompatible" change, > but if there is nothing to stay compatible with, > then why to worry? My idea of compatibility was to have the emulation code behave exactly as a processor without UMIP :) > Probably you could also remove > the sldt and str emulation for protected mode, because, > as I understand from this thread, wine does not > need those. I see. I would lean on keeping the emulation because I already implemented it :), for completeness, and because it is performed in a single switch. The bulk of the emulation code deals with operands. > > Note that these days dosemu2 uses v86 mode set > up under kvm rather than vm86(). Your patches > affect that the same way as they do for vm86() > syscall, or can there be some differences? My code does not touch kvm at all. I would need to assess how kvm will behave. > Or should > the UMIP be enabled under kvm by hands? There was an attempt to emulate UMIP that was submitted a while ago: https://lkml.org/lkml/2016/7/12/644 > > >> You know the wine's > >> requirements now - they are very small. And > >> dosemu doesn't need anything at all but smsw. > >> And even smsw is very rare. > > But emulation is still needed for SMSW, right? > Likely so. > If you want, I can enable the logging of this command > and see if it is used by some of the DOS programs I have. It would be great if you could do that, if you don't mind. > But at least dosemu implements it, so probably it is needed. Right. > Of course if it is used by one of 100 DOS progs, then there > is an option to just add its support to dosemu2 and pretend > the compatibility problems did not exist. :) Do you mean relaying the GP fault to dosemu instead of trapping it and emulating it in the kernel? Thanks and BR, Ricardo -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Tue, 2017-03-14 at 00:25 +0300, Stas Sergeev wrote: > 11.03.2017 02:59, Ricardo Neri пишет: > > On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote: > > > >> Why would you need one? > >> Or do you really want to allow these instructions > >> in v86 by the means of emulation? If so - this wasn't > >> clearly stated in the patch description, neither it was > >> properly discussed, it seems. > > It str and sldt can be emulated in vm86 but as Andy mention, the > > behavior sould be the same with and without emulation. > Why would you do that? > I looked up the dosemu2 CPU simulator code that > is used under x86-64. It says this: Stas, I apologize for the delayed reply; I missed your e-mail. > --- > CODE_FLUSH(); > if (REALMODE()) goto illegal_op; > PC += ModRMSim(PC+1, mode) + 1; > error("SLDT not implemented\n"); > break; > case 1: /* STR */ > /* Store Task Register */ > CODE_FLUSH(); > if (REALMODE()) goto illegal_op; > PC += ModRMSim(PC+1, mode) + 1; > error("STR not implemented\n"); > break; > ... > case 0: /* SGDT */ > /* Store Global Descriptor Table > Register */ > PC++; PC += ModRM(opc, PC, > mode|DATA16|MSTORE); > error("SGDT not implemented\n"); > break; > case 1: /* SIDT */ > /* Store Interrupt Descriptor Table > Register */ > PC++; PC += ModRM(opc, PC, > mode|DATA16|MSTORE); > error("SIDT not implemented\n"); > break; > --- > > It only implements smsw. > So maybe you can make your code much > simpler and remove the unneeded emulation? > Same is for prot mode. Do you mean the unneeded emulation for SLDT and STR? > You know the wine's > requirements now - they are very small. And > dosemu doesn't need anything at all but smsw. > And even smsw is very rare. But emulation is still needed for SMSW, right? The majority of my patches deal with computing the effective based on the instruction operands and linear addresses based on the effective address and the segment descriptor. Only two or three patches deal with identifying particular UMIP-protected instructions. Not having to worry about STR and SLDT in vm86 could simplify things a bit, though. Thanks and BR, Ricardo -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Fri, 2017-03-10 at 06:17 -0800, Andy Lutomirski wrote: > On Fri, Mar 10, 2017 at 3:33 AM, Stas Sergeevwrote: > > 10.03.2017 05:39, Andy Lutomirski пишет: > > > >> On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev wrote: > >>> > >>> 09.03.2017 04:15, Ricardo Neri пишет: > >>> > On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote: > > > > On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev wrote: > >> > >> 08.03.2017 19:06, Andy Lutomirski пишет: > >>> > >>> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev wrote: > > 08.03.2017 03:32, Ricardo Neri пишет: > > > > These are the instructions covered by UMIP: > > * SGDT - Store Global Descriptor Table > > * SIDT - Store Interrupt Descriptor Table > > * SLDT - Store Local Descriptor Table > > * SMSW - Store Machine Status Word > > * STR - Store Task Register > > > > This patchset initially treated tasks running in virtual-8086 > > > > mode as a > > > > special case. However, I received clarification that DOSEMU[8] > > > > does not > > > > support applications that use these instructions. > >>> > >>> Can you remind me what was special about it? It looks like you > > > > still > >>> > >>> emulate them in v8086 mode. > >> > >> Indeed, sorry, I meant prot mode here. :) > >> So I wonder what was cited to be special about v86. > > Initially my patches disabled UMIP on virtual-8086 instructions, without > regards of protected mode (i.e., UMIP was always enabled). I didn't have > emulation at the time. Then, I added emulation code that now covers > protected and virtual-8086 modes. I guess it is not special anymore. > >>> > >>> But isn't SLDT just throw UD in v86? > >>> How does UMIP affect this? How does your patch affect > >>> this? > >> > >> Er, right. Ricardo, your code may need fixing. But don't you have a > >> test case for this? > > > > Why would you need one? > > Or do you really want to allow these instructions > > in v86 by the means of emulation? If so - this wasn't > > clearly stated in the patch description, neither it was > > properly discussed, it seems. > > What I meant was: if the patches incorrectly started making these > instructions work in vm86 mode where they used to cause a vm86 exit, > then that's a bug that the selftest should have caught. Yes, this is the case. I will fix this behavior... and update the test cases. -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Sat, 2017-03-11 at 02:58 +0300, Stas Sergeev wrote: > 11.03.2017 02:47, Ricardo Neri пишет: > >> > It doesn't need to be a matter of this particular > patch set, i.e. this proposal should not trigger a > v7 resend of all 21 patches. :) But it would be useful > for the future development of dosemu2. > >>> Would dosemu2 use 32-bit processes in order to keep segmentation? If it > >>> could use 64-bit processes, emulation is not used in this case and the > >>> SIGSEGV is delivered to user space. > >> It does use the mix: 64bit process but some segments > >> are 32bit for DOS code. > > Do you mean that dosemu2 will start as a 64-bit process and will jump to > > 32-bit code segments? > Yes, so the offending insns are executed only in 32bit > and 16bit segments, even if the process itself is 64bit. > I guess you handle 16bit segments same as 32bit ones. I have code to handle 16-bit and 32-bit address encodings differently. Segmentation is used if !user_64bit_mode(regs). In such a case, the emulation code will check the segment descriptor D flag and the address-size overrides prefix to determine the address size and use 16-bit or 32-bit address encodings as applicable. > > > My emulation code should work in this case as it > > will use segmentation in 32-bit code descriptors. Is there anything else > > needed? > If I understand you correctly, you are saying that SLDT > executed in 64bit code segment, will inevitably segfault > to userspace. Correct. > If this is the case and it makes your code > simpler, then its perfectly fine with me as dosemu does > not do this and the 64bit DOS progs are not anticipated. But if 32-bit or 16-bit code segments are used emulation will be used. Thanks and BR, Ricardo -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote: > 10.03.2017 05:39, Andy Lutomirski пишет: > > On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeevwrote: > >> 09.03.2017 04:15, Ricardo Neri пишет: > >> > >>> On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote: > On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev wrote: > > 08.03.2017 19:06, Andy Lutomirski пишет: > >> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev wrote: > >>> 08.03.2017 03:32, Ricardo Neri пишет: > These are the instructions covered by UMIP: > * SGDT - Store Global Descriptor Table > * SIDT - Store Interrupt Descriptor Table > * SLDT - Store Local Descriptor Table > * SMSW - Store Machine Status Word > * STR - Store Task Register > > This patchset initially treated tasks running in virtual-8086 > mode as a > special case. However, I received clarification that DOSEMU[8] > does not > support applications that use these instructions. > >> Can you remind me what was special about it? It looks like you > still > >> emulate them in v8086 mode. > > Indeed, sorry, I meant prot mode here. :) > > So I wonder what was cited to be special about v86. > >>> Initially my patches disabled UMIP on virtual-8086 instructions, without > >>> regards of protected mode (i.e., UMIP was always enabled). I didn't have > >>> emulation at the time. Then, I added emulation code that now covers > >>> protected and virtual-8086 modes. I guess it is not special anymore. > >> But isn't SLDT just throw UD in v86? > >> How does UMIP affect this? How does your patch affect > >> this? > > Er, right. Ricardo, your code may need fixing. But don't you have a > > test case for this? > Why would you need one? > Or do you really want to allow these instructions > in v86 by the means of emulation? If so - this wasn't > clearly stated in the patch description, neither it was > properly discussed, it seems. It str and sldt can be emulated in vm86 but as Andy mention, the behavior sould be the same with and without emulation. Thanks and BR, Ricardo -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
11.03.2017 02:47, Ricardo Neri пишет: It doesn't need to be a matter of this particular patch set, i.e. this proposal should not trigger a v7 resend of all 21 patches. :) But it would be useful for the future development of dosemu2. Would dosemu2 use 32-bit processes in order to keep segmentation? If it could use 64-bit processes, emulation is not used in this case and the SIGSEGV is delivered to user space. It does use the mix: 64bit process but some segments are 32bit for DOS code. Do you mean that dosemu2 will start as a 64-bit process and will jump to 32-bit code segments? Yes, so the offending insns are executed only in 32bit and 16bit segments, even if the process itself is 64bit. I guess you handle 16bit segments same as 32bit ones. My emulation code should work in this case as it will use segmentation in 32-bit code descriptors. Is there anything else needed? If I understand you correctly, you are saying that SLDT executed in 64bit code segment, will inevitably segfault to userspace. If this is the case and it makes your code simpler, then its perfectly fine with me as dosemu does not do this and the 64bit DOS progs are not anticipated. -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Thu, 2017-03-09 at 18:39 -0800, Andy Lutomirski wrote: > On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeevwrote: > > 09.03.2017 04:15, Ricardo Neri пишет: > > > >> On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote: > >>> > >>> On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev wrote: > > 08.03.2017 19:06, Andy Lutomirski пишет: > > > > On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev wrote: > >> > >> 08.03.2017 03:32, Ricardo Neri пишет: > >>> > >>> These are the instructions covered by UMIP: > >>> * SGDT - Store Global Descriptor Table > >>> * SIDT - Store Interrupt Descriptor Table > >>> * SLDT - Store Local Descriptor Table > >>> * SMSW - Store Machine Status Word > >>> * STR - Store Task Register > >>> > >>> This patchset initially treated tasks running in virtual-8086 > >>> > >>> mode as a > >>> > >>> special case. However, I received clarification that DOSEMU[8] > >>> > >>> does not > >>> > >>> support applications that use these instructions. > > > > Can you remind me what was special about it? It looks like you > >>> > >>> still > > > > emulate them in v8086 mode. > > Indeed, sorry, I meant prot mode here. :) > So I wonder what was cited to be special about v86. > >> > >> Initially my patches disabled UMIP on virtual-8086 instructions, without > >> regards of protected mode (i.e., UMIP was always enabled). I didn't have > >> emulation at the time. Then, I added emulation code that now covers > >> protected and virtual-8086 modes. I guess it is not special anymore. > > > > But isn't SLDT just throw UD in v86? > > How does UMIP affect this? How does your patch affect > > this? > > Er, right. Ricardo, your code may need fixing. But don't you have a > test case for this? The behavior should be the same with and without > your patches applied. The exception is #UD, not #GP, so maybe your > code just never executes in the vm86 case. Ouch! Yes, I am afraid my code will attempt to emulate sldt in vm86 mode. The test cases that I have for vm86 are only for the instructions that are valid in vm86: smsw, sidt and sgdt. I will add test cases for str and sldt and make sure that a #UD is issued. Would this trigger a v7 series? Thanks and BR, Ricardo > > --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Fri, 2017-03-10 at 01:01 +0300, Stas Sergeev wrote: > 09.03.2017 03:46, Ricardo Neri пишет: > > On Wed, 2017-03-08 at 17:08 +0300, Stas Sergeev wrote: > >> 08.03.2017 03:32, Ricardo Neri пишет: > >>> These are the instructions covered by UMIP: > >>> * SGDT - Store Global Descriptor Table > >>> * SIDT - Store Interrupt Descriptor Table > >>> * SLDT - Store Local Descriptor Table > >>> * SMSW - Store Machine Status Word > >>> * STR - Store Task Register > >>> > >>> This patchset initially treated tasks running in virtual-8086 mode as a > >>> special case. However, I received clarification that DOSEMU[8] does not > >>> support applications that use these instructions. > >> Yes, this is the case. > >> But at least in the past there was an attempt to > >> support SLDT as it is used by an ancient pharlap > >> DOS extender (currently unsupported by dosemu1/2). > >> So how difficult would it be to add an optional > >> possibility of delivering such SIGSEGV to userspace > >> so that the kernel's dummy emulation can be overridden? > > I suppose a umip=noemulation kernel parameter could be added in this > > case. > Why? > It doesn't need to be global: the app should be > able to change that on its own. Note that no app currently > requires this, so its just for the future, and in the > future the app can start using the new API for this, > if you provide one. Right, I missed this detail. Then, yes the API should allow only one app to relay the SIGSEGV. > > > >> It doesn't need to be a matter of this particular > >> patch set, i.e. this proposal should not trigger a > >> v7 resend of all 21 patches. :) But it would be useful > >> for the future development of dosemu2. > > Would dosemu2 use 32-bit processes in order to keep segmentation? If it > > could use 64-bit processes, emulation is not used in this case and the > > SIGSEGV is delivered to user space. > It does use the mix: 64bit process but some segments > are 32bit for DOS code. Do you mean that dosemu2 will start as a 64-bit process and will jump to 32-bit code segments? My emulation code should work in this case as it will use segmentation in 32-bit code descriptors. Is there anything else needed? Thanks and BR, Ricardo -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
11.03.2017 00:04, Andy Lutomirski пишет: On Fri, Mar 10, 2017 at 2:30 AM, Stas Sergeevwrote: 10.03.2017 05:41, Andy Lutomirski пишет: On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neri wrote: On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote: 08.03.2017 19:46, Andy Lutomirski пишет: No no, since I meant prot mode, this is not what I need. I would never need to disable UMIP as to allow the prot mode apps to do SLDT. Instead it would be good to have an ability to provide a replacement for the dummy emulation that is currently being proposed for kernel. All is needed for this, is just to deliver a SIGSEGV. That's what I meant. Turning off FIXUP_UMIP would leave UMIP on but turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86 GP exit). But then I am confused with the word "compat" in your "COMPAT_MASK0_X86_UMIP_FIXUP" and "sys_adjust_compat_mask(int op, int word, u32 mask);" Leaving UMIP on and only disabling a fixup doesn't sound like a compat option to me. I would expect compat to disable it completely. I guess that the _UMIP_FIXUP part makes it clear that emulation, not UMIP is disabled, allowing the SIGSEGV be delivered to the user space program. Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a COMPAT_MASK0_X86_UMIP to disable UMIP make sense? Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its purpose? Applications could simply use this compat mask to bypass UMIP and gain access to the instructions it protects. I was obviously extremely unclear. The point of the proposed syscall is to let programs opt out of legacy features. I guess both "compat" and "legacy" are misleading here. Maybe these are "x86-specific" or "hypervisor-specific", but a mere enabling of UMIP doesn't immediately make the use of SLDT instruction a legacy IMHO. Sure it is. :) Using SLDT from user mode is a legacy ability that just happens to still work on existing CPUs and kernels. Once UMIP goes in, it will officially be obsolete Yes, but the names you suggest, imply that "UMIP_FIXUP" is legacy or compat, which I find misleading because it have just appeared. Maybe something like "COMPAT_X86_UMIP_INSNS_EMU"? -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Fri, Mar 10, 2017 at 2:30 AM, Stas Sergeevwrote: > 10.03.2017 05:41, Andy Lutomirski пишет: > >> On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neri >> wrote: >>> >>> On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote: 08.03.2017 19:46, Andy Lutomirski пишет: >> >> No no, since I meant prot mode, this is not what I need. >> I would never need to disable UMIP as to allow the >> prot mode apps to do SLDT. Instead it would be good >> to have an ability to provide a replacement for the dummy >> emulation that is currently being proposed for kernel. >> All is needed for this, is just to deliver a SIGSEGV. > > That's what I meant. Turning off FIXUP_UMIP would leave UMIP on but > turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86 > GP exit). But then I am confused with the word "compat" in your "COMPAT_MASK0_X86_UMIP_FIXUP" and "sys_adjust_compat_mask(int op, int word, u32 mask);" Leaving UMIP on and only disabling a fixup doesn't sound like a compat option to me. I would expect compat to disable it completely. >>> >>> I guess that the _UMIP_FIXUP part makes it clear that emulation, not >>> UMIP is disabled, allowing the SIGSEGV be delivered to the user space >>> program. >>> >>> Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a >>> COMPAT_MASK0_X86_UMIP to disable UMIP make sense? >>> >>> Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its >>> purpose? Applications could simply use this compat mask to bypass UMIP >>> and gain access to the instructions it protects. >>> >> I was obviously extremely unclear. The point of the proposed syscall >> is to let programs opt out of legacy features. > > I guess both "compat" and "legacy" are misleading > here. Maybe these are "x86-specific" or "hypervisor-specific", > but a mere enabling of UMIP doesn't immediately make > the use of SLDT instruction a legacy IMHO. Sure it is. :) Using SLDT from user mode is a legacy ability that just happens to still work on existing CPUs and kernels. Once UMIP goes in, it will officially be obsolete -- it will just be supported for backwards compatibility. New code should opt out and emulate in usermode if needed. (And the vast, vast majority of Linux programs don't use these instructions in the first place.) Similarly, vsyscalls were obsolete the as soon as better alternatives were fully supported and the kernel started making them slow, and the fact that new static glibc programs still used them for a little while didn't make them any less obsolete. > >> I'll ponder this a bit more. > > So if we are to invent something new, it would be nice to > also think up a clear terminology for it. Maybe something > like "X86_FEATURE_xxx_MASK" or alike. But they're misfeatures, not features. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
10.03.2017 05:41, Andy Lutomirski пишет: On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neriwrote: On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote: 08.03.2017 19:46, Andy Lutomirski пишет: No no, since I meant prot mode, this is not what I need. I would never need to disable UMIP as to allow the prot mode apps to do SLDT. Instead it would be good to have an ability to provide a replacement for the dummy emulation that is currently being proposed for kernel. All is needed for this, is just to deliver a SIGSEGV. That's what I meant. Turning off FIXUP_UMIP would leave UMIP on but turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86 GP exit). But then I am confused with the word "compat" in your "COMPAT_MASK0_X86_UMIP_FIXUP" and "sys_adjust_compat_mask(int op, int word, u32 mask);" Leaving UMIP on and only disabling a fixup doesn't sound like a compat option to me. I would expect compat to disable it completely. I guess that the _UMIP_FIXUP part makes it clear that emulation, not UMIP is disabled, allowing the SIGSEGV be delivered to the user space program. Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a COMPAT_MASK0_X86_UMIP to disable UMIP make sense? Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its purpose? Applications could simply use this compat mask to bypass UMIP and gain access to the instructions it protects. I was obviously extremely unclear. The point of the proposed syscall is to let programs opt out of legacy features. I guess both "compat" and "legacy" are misleading here. Maybe these are "x86-specific" or "hypervisor-specific", but a mere enabling of UMIP doesn't immediately make the use of SLDT instruction a legacy IMHO. I'll ponder this a bit more. So if we are to invent something new, it would be nice to also think up a clear terminology for it. Maybe something like "X86_FEATURE_xxx_MASK" or alike. -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Fri, Mar 10, 2017 at 3:33 AM, Stas Sergeevwrote: > 10.03.2017 05:39, Andy Lutomirski пишет: > >> On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev wrote: >>> >>> 09.03.2017 04:15, Ricardo Neri пишет: >>> On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote: > > On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev wrote: >> >> 08.03.2017 19:06, Andy Lutomirski пишет: >>> >>> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev wrote: 08.03.2017 03:32, Ricardo Neri пишет: > > These are the instructions covered by UMIP: > * SGDT - Store Global Descriptor Table > * SIDT - Store Interrupt Descriptor Table > * SLDT - Store Local Descriptor Table > * SMSW - Store Machine Status Word > * STR - Store Task Register > > This patchset initially treated tasks running in virtual-8086 > > mode as a > > special case. However, I received clarification that DOSEMU[8] > > does not > > support applications that use these instructions. >>> >>> Can you remind me what was special about it? It looks like you > > still >>> >>> emulate them in v8086 mode. >> >> Indeed, sorry, I meant prot mode here. :) >> So I wonder what was cited to be special about v86. Initially my patches disabled UMIP on virtual-8086 instructions, without regards of protected mode (i.e., UMIP was always enabled). I didn't have emulation at the time. Then, I added emulation code that now covers protected and virtual-8086 modes. I guess it is not special anymore. >>> >>> But isn't SLDT just throw UD in v86? >>> How does UMIP affect this? How does your patch affect >>> this? >> >> Er, right. Ricardo, your code may need fixing. But don't you have a >> test case for this? > > Why would you need one? > Or do you really want to allow these instructions > in v86 by the means of emulation? If so - this wasn't > clearly stated in the patch description, neither it was > properly discussed, it seems. What I meant was: if the patches incorrectly started making these instructions work in vm86 mode where they used to cause a vm86 exit, then that's a bug that the selftest should have caught. -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
10.03.2017 05:39, Andy Lutomirski пишет: On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeevwrote: 09.03.2017 04:15, Ricardo Neri пишет: On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote: On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev wrote: 08.03.2017 19:06, Andy Lutomirski пишет: On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev wrote: 08.03.2017 03:32, Ricardo Neri пишет: These are the instructions covered by UMIP: * SGDT - Store Global Descriptor Table * SIDT - Store Interrupt Descriptor Table * SLDT - Store Local Descriptor Table * SMSW - Store Machine Status Word * STR - Store Task Register This patchset initially treated tasks running in virtual-8086 mode as a special case. However, I received clarification that DOSEMU[8] does not support applications that use these instructions. Can you remind me what was special about it? It looks like you still emulate them in v8086 mode. Indeed, sorry, I meant prot mode here. :) So I wonder what was cited to be special about v86. Initially my patches disabled UMIP on virtual-8086 instructions, without regards of protected mode (i.e., UMIP was always enabled). I didn't have emulation at the time. Then, I added emulation code that now covers protected and virtual-8086 modes. I guess it is not special anymore. But isn't SLDT just throw UD in v86? How does UMIP affect this? How does your patch affect this? Er, right. Ricardo, your code may need fixing. But don't you have a test case for this? Why would you need one? Or do you really want to allow these instructions in v86 by the means of emulation? If so - this wasn't clearly stated in the patch description, neither it was properly discussed, it seems. -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neriwrote: > On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote: >> 08.03.2017 19:46, Andy Lutomirski пишет: >> >> No no, since I meant prot mode, this is not what I need. >> >> I would never need to disable UMIP as to allow the >> >> prot mode apps to do SLDT. Instead it would be good >> >> to have an ability to provide a replacement for the dummy >> >> emulation that is currently being proposed for kernel. >> >> All is needed for this, is just to deliver a SIGSEGV. >> > That's what I meant. Turning off FIXUP_UMIP would leave UMIP on but >> > turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86 >> > GP exit). >> But then I am confused with the word "compat" in >> your "COMPAT_MASK0_X86_UMIP_FIXUP" and >> "sys_adjust_compat_mask(int op, int word, u32 mask);" >> >> Leaving UMIP on and only disabling a fixup doesn't >> sound like a compat option to me. I would expect >> compat to disable it completely. > > I guess that the _UMIP_FIXUP part makes it clear that emulation, not > UMIP is disabled, allowing the SIGSEGV be delivered to the user space > program. > > Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a > COMPAT_MASK0_X86_UMIP to disable UMIP make sense? > > Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its > purpose? Applications could simply use this compat mask to bypass UMIP > and gain access to the instructions it protects. > I was obviously extremely unclear. The point of the proposed syscall is to let programs opt out of legacy features. So there would be a bit to disable emulation of UMIP-blocked instructions (this giving the unadulterated #GP). There would not be a bit to disable UMIP itself. There's also a flaw in my proposal. Disable-vsyscall would be per-mm and disable-umip-emulation would be per-task, so they'd need to be in separate words to make any sense. I'll ponder this a bit more. -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeevwrote: > 09.03.2017 04:15, Ricardo Neri пишет: > >> On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote: >>> >>> On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev wrote: 08.03.2017 19:06, Andy Lutomirski пишет: > > On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev wrote: >> >> 08.03.2017 03:32, Ricardo Neri пишет: >>> >>> These are the instructions covered by UMIP: >>> * SGDT - Store Global Descriptor Table >>> * SIDT - Store Interrupt Descriptor Table >>> * SLDT - Store Local Descriptor Table >>> * SMSW - Store Machine Status Word >>> * STR - Store Task Register >>> >>> This patchset initially treated tasks running in virtual-8086 >>> >>> mode as a >>> >>> special case. However, I received clarification that DOSEMU[8] >>> >>> does not >>> >>> support applications that use these instructions. > > Can you remind me what was special about it? It looks like you >>> >>> still > > emulate them in v8086 mode. Indeed, sorry, I meant prot mode here. :) So I wonder what was cited to be special about v86. >> >> Initially my patches disabled UMIP on virtual-8086 instructions, without >> regards of protected mode (i.e., UMIP was always enabled). I didn't have >> emulation at the time. Then, I added emulation code that now covers >> protected and virtual-8086 modes. I guess it is not special anymore. > > But isn't SLDT just throw UD in v86? > How does UMIP affect this? How does your patch affect > this? Er, right. Ricardo, your code may need fixing. But don't you have a test case for this? The behavior should be the same with and without your patches applied. The exception is #UD, not #GP, so maybe your code just never executes in the vm86 case. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
09.03.2017 03:46, Ricardo Neri пишет: On Wed, 2017-03-08 at 17:08 +0300, Stas Sergeev wrote: 08.03.2017 03:32, Ricardo Neri пишет: These are the instructions covered by UMIP: * SGDT - Store Global Descriptor Table * SIDT - Store Interrupt Descriptor Table * SLDT - Store Local Descriptor Table * SMSW - Store Machine Status Word * STR - Store Task Register This patchset initially treated tasks running in virtual-8086 mode as a special case. However, I received clarification that DOSEMU[8] does not support applications that use these instructions. Yes, this is the case. But at least in the past there was an attempt to support SLDT as it is used by an ancient pharlap DOS extender (currently unsupported by dosemu1/2). So how difficult would it be to add an optional possibility of delivering such SIGSEGV to userspace so that the kernel's dummy emulation can be overridden? I suppose a umip=noemulation kernel parameter could be added in this case. Why? It doesn't need to be global: the app should be able to change that on its own. Note that no app currently requires this, so its just for the future, and in the future the app can start using the new API for this, if you provide one. It doesn't need to be a matter of this particular patch set, i.e. this proposal should not trigger a v7 resend of all 21 patches. :) But it would be useful for the future development of dosemu2. Would dosemu2 use 32-bit processes in order to keep segmentation? If it could use 64-bit processes, emulation is not used in this case and the SIGSEGV is delivered to user space. It does use the mix: 64bit process but some segments are 32bit for DOS code. -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
09.03.2017 04:15, Ricardo Neri пишет: On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote: On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeevwrote: 08.03.2017 19:06, Andy Lutomirski пишет: On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev wrote: 08.03.2017 03:32, Ricardo Neri пишет: These are the instructions covered by UMIP: * SGDT - Store Global Descriptor Table * SIDT - Store Interrupt Descriptor Table * SLDT - Store Local Descriptor Table * SMSW - Store Machine Status Word * STR - Store Task Register This patchset initially treated tasks running in virtual-8086 mode as a special case. However, I received clarification that DOSEMU[8] does not support applications that use these instructions. Can you remind me what was special about it? It looks like you still emulate them in v8086 mode. Indeed, sorry, I meant prot mode here. :) So I wonder what was cited to be special about v86. Initially my patches disabled UMIP on virtual-8086 instructions, without regards of protected mode (i.e., UMIP was always enabled). I didn't have emulation at the time. Then, I added emulation code that now covers protected and virtual-8086 modes. I guess it is not special anymore. But isn't SLDT just throw UD in v86? How does UMIP affect this? How does your patch affect this? -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
09.03.2017 04:11, Ricardo Neri пишет: On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote: 08.03.2017 19:46, Andy Lutomirski пишет: No no, since I meant prot mode, this is not what I need. I would never need to disable UMIP as to allow the prot mode apps to do SLDT. Instead it would be good to have an ability to provide a replacement for the dummy emulation that is currently being proposed for kernel. All is needed for this, is just to deliver a SIGSEGV. That's what I meant. Turning off FIXUP_UMIP would leave UMIP on but turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86 GP exit). But then I am confused with the word "compat" in your "COMPAT_MASK0_X86_UMIP_FIXUP" and "sys_adjust_compat_mask(int op, int word, u32 mask);" Leaving UMIP on and only disabling a fixup doesn't sound like a compat option to me. I would expect compat to disable it completely. I guess that the _UMIP_FIXUP part makes it clear that emulation, not UMIP is disabled, allowing the SIGSEGV be delivered to the user space program. Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a COMPAT_MASK0_X86_UMIP to disable UMIP make sense? Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its purpose? Applications could simply use this compat mask to bypass UMIP and gain access to the instructions it protects. I don't think someone will want to completely disable UMIP, so why do you need such functionality? My question was only what does "compat" mean in "COMPAT_MASK0_X86_UMIP_FIXUP", compat with what. -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote: > On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeevwrote: > > 08.03.2017 19:06, Andy Lutomirski пишет: > >> > >> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev wrote: > >>> > >>> 08.03.2017 03:32, Ricardo Neri пишет: > > These are the instructions covered by UMIP: > * SGDT - Store Global Descriptor Table > * SIDT - Store Interrupt Descriptor Table > * SLDT - Store Local Descriptor Table > * SMSW - Store Machine Status Word > * STR - Store Task Register > > This patchset initially treated tasks running in virtual-8086 > mode as a > special case. However, I received clarification that DOSEMU[8] > does not > support applications that use these instructions. > >> > >> Can you remind me what was special about it? It looks like you > still > >> emulate them in v8086 mode. > > > > Indeed, sorry, I meant prot mode here. :) > > So I wonder what was cited to be special about v86. Initially my patches disabled UMIP on virtual-8086 instructions, without regards of protected mode (i.e., UMIP was always enabled). I didn't have emulation at the time. Then, I added emulation code that now covers protected and virtual-8086 modes. I guess it is not special anymore. Thanks and BR, Ricardo -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote: > 08.03.2017 19:46, Andy Lutomirski пишет: > >> No no, since I meant prot mode, this is not what I need. > >> I would never need to disable UMIP as to allow the > >> prot mode apps to do SLDT. Instead it would be good > >> to have an ability to provide a replacement for the dummy > >> emulation that is currently being proposed for kernel. > >> All is needed for this, is just to deliver a SIGSEGV. > > That's what I meant. Turning off FIXUP_UMIP would leave UMIP on but > > turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86 > > GP exit). > But then I am confused with the word "compat" in > your "COMPAT_MASK0_X86_UMIP_FIXUP" and > "sys_adjust_compat_mask(int op, int word, u32 mask);" > > Leaving UMIP on and only disabling a fixup doesn't > sound like a compat option to me. I would expect > compat to disable it completely. I guess that the _UMIP_FIXUP part makes it clear that emulation, not UMIP is disabled, allowing the SIGSEGV be delivered to the user space program. Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a COMPAT_MASK0_X86_UMIP to disable UMIP make sense? Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its purpose? Applications could simply use this compat mask to bypass UMIP and gain access to the instructions it protects. Thanks and BR, Ricardo -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Wed, 2017-03-08 at 17:08 +0300, Stas Sergeev wrote: > 08.03.2017 03:32, Ricardo Neri пишет: > > These are the instructions covered by UMIP: > > * SGDT - Store Global Descriptor Table > > * SIDT - Store Interrupt Descriptor Table > > * SLDT - Store Local Descriptor Table > > * SMSW - Store Machine Status Word > > * STR - Store Task Register > > > > This patchset initially treated tasks running in virtual-8086 mode as a > > special case. However, I received clarification that DOSEMU[8] does not > > support applications that use these instructions. > Yes, this is the case. > But at least in the past there was an attempt to > support SLDT as it is used by an ancient pharlap > DOS extender (currently unsupported by dosemu1/2). > So how difficult would it be to add an optional > possibility of delivering such SIGSEGV to userspace > so that the kernel's dummy emulation can be overridden? I suppose a umip=noemulation kernel parameter could be added in this case. > It doesn't need to be a matter of this particular > patch set, i.e. this proposal should not trigger a > v7 resend of all 21 patches. :) But it would be useful > for the future development of dosemu2. Would dosemu2 use 32-bit processes in order to keep segmentation? If it could use 64-bit processes, emulation is not used in this case and the SIGSEGV is delivered to user space. Thanks and BR, Ricardo -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
08.03.2017 19:06, Andy Lutomirski пишет: On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeevwrote: 08.03.2017 03:32, Ricardo Neri пишет: These are the instructions covered by UMIP: * SGDT - Store Global Descriptor Table * SIDT - Store Interrupt Descriptor Table * SLDT - Store Local Descriptor Table * SMSW - Store Machine Status Word * STR - Store Task Register This patchset initially treated tasks running in virtual-8086 mode as a special case. However, I received clarification that DOSEMU[8] does not support applications that use these instructions. Can you remind me what was special about it? It looks like you still emulate them in v8086 mode. Indeed, sorry, I meant prot mode here. :) So I wonder what was cited to be special about v86. Yes, this is the case. But at least in the past there was an attempt to support SLDT as it is used by an ancient pharlap DOS extender (currently unsupported by dosemu1/2). So how difficult would it be to add an optional possibility of delivering such SIGSEGV to userspace so that the kernel's dummy emulation can be overridden? It doesn't need to be a matter of this particular patch set, i.e. this proposal should not trigger a v7 resend of all 21 patches. :) But it would be useful for the future development of dosemu2. What I'd actually like to see is a totally separate patchset that adds an inheritable (but reset on exec) per-task mask of legacy compatibility features to disable. Maybe: sys_adjust_compat_mask(int op, int word, u32 mask); No no, since I meant prot mode, this is not what I need. I would never need to disable UMIP as to allow the prot mode apps to do SLDT. Instead it would be good to have an ability to provide a replacement for the dummy emulation that is currently being proposed for kernel. All is needed for this, is just to deliver a SIGSEGV. -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeevwrote: > 08.03.2017 19:06, Andy Lutomirski пишет: >> >> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev wrote: >>> >>> 08.03.2017 03:32, Ricardo Neri пишет: These are the instructions covered by UMIP: * SGDT - Store Global Descriptor Table * SIDT - Store Interrupt Descriptor Table * SLDT - Store Local Descriptor Table * SMSW - Store Machine Status Word * STR - Store Task Register This patchset initially treated tasks running in virtual-8086 mode as a special case. However, I received clarification that DOSEMU[8] does not support applications that use these instructions. >> >> Can you remind me what was special about it? It looks like you still >> emulate them in v8086 mode. > > Indeed, sorry, I meant prot mode here. :) > So I wonder what was cited to be special about v86. Not sure. Ricardo? > >>> Yes, this is the case. >>> But at least in the past there was an attempt to >>> support SLDT as it is used by an ancient pharlap >>> DOS extender (currently unsupported by dosemu1/2). >>> So how difficult would it be to add an optional >>> possibility of delivering such SIGSEGV to userspace >>> so that the kernel's dummy emulation can be overridden? >>> It doesn't need to be a matter of this particular >>> patch set, i.e. this proposal should not trigger a >>> v7 resend of all 21 patches. :) But it would be useful >>> for the future development of dosemu2. >> >> What I'd actually like to see is a totally separate patchset that adds >> an inheritable (but reset on exec) per-task mask of legacy >> compatibility features to disable. Maybe: >> >> sys_adjust_compat_mask(int op, int word, u32 mask); > > No no, since I meant prot mode, this is not what I need. > I would never need to disable UMIP as to allow the > prot mode apps to do SLDT. Instead it would be good > to have an ability to provide a replacement for the dummy > emulation that is currently being proposed for kernel. > All is needed for this, is just to deliver a SIGSEGV. That's what I meant. Turning off FIXUP_UMIP would leave UMIP on but turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86 GP exit). --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
08.03.2017 19:46, Andy Lutomirski пишет: No no, since I meant prot mode, this is not what I need. I would never need to disable UMIP as to allow the prot mode apps to do SLDT. Instead it would be good to have an ability to provide a replacement for the dummy emulation that is currently being proposed for kernel. All is needed for this, is just to deliver a SIGSEGV. That's what I meant. Turning off FIXUP_UMIP would leave UMIP on but turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86 GP exit). But then I am confused with the word "compat" in your "COMPAT_MASK0_X86_UMIP_FIXUP" and "sys_adjust_compat_mask(int op, int word, u32 mask);" Leaving UMIP on and only disabling a fixup doesn't sound like a compat option to me. I would expect compat to disable it completely. -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeevwrote: > 08.03.2017 03:32, Ricardo Neri пишет: >> >> These are the instructions covered by UMIP: >> * SGDT - Store Global Descriptor Table >> * SIDT - Store Interrupt Descriptor Table >> * SLDT - Store Local Descriptor Table >> * SMSW - Store Machine Status Word >> * STR - Store Task Register >> >> This patchset initially treated tasks running in virtual-8086 mode as a >> special case. However, I received clarification that DOSEMU[8] does not >> support applications that use these instructions. Can you remind me what was special about it? It looks like you still emulate them in v8086 mode. > > Yes, this is the case. > But at least in the past there was an attempt to > support SLDT as it is used by an ancient pharlap > DOS extender (currently unsupported by dosemu1/2). > So how difficult would it be to add an optional > possibility of delivering such SIGSEGV to userspace > so that the kernel's dummy emulation can be overridden? > It doesn't need to be a matter of this particular > patch set, i.e. this proposal should not trigger a > v7 resend of all 21 patches. :) But it would be useful > for the future development of dosemu2. What I'd actually like to see is a totally separate patchset that adds an inheritable (but reset on exec) per-task mask of legacy compatibility features to disable. Maybe: sys_adjust_compat_mask(int op, int word, u32 mask); op could indicate that we want to so SET, OR, AND, or READ. word would be 0 for now. It could be a prctl, too. Things in the mask could include: COMPAT_MASK0_X86_64_VSYSCALL [1] COMPAT_MASK0_X86_UMIP_FIXUP I'm sure I could think of more along these lines. Then DOSEMU (and future WINE versions, too) could just mask off X86_UMIP_FIXUP and do their own emulation [1] For those of you thinking about this and realizing that VSYSCALL readability is inherently global and not per-task, I know how to fix that for essentially no cost :) --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
On Tue, Mar 7, 2017 at 4:32 PM, Ricardo Neriwrote: > This is v6 of this series. The five previous submissions can be found > here [1], here [2], here[3], here[4], and here[5]. This version addresses > the comments received in v4 plus improvements of the handling of emulation > in 64-bit builds. Please see details in the change log. > Hi Ingo and Thomas- I think this series is in good enough shape that you should consider making a topic branch (x86/umip?) for it so that it can soak in -next and further development can be done incrementally. In the unlikely event that a major problem shows up, you could skip the pull request to Linus for a cycle. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html