lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 30 Mar 2017 13:10:59 +0300
From:   Stas Sergeev <stsp@...t.ru>
To:     Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Andy Lutomirski <luto@...nel.org>,
        Borislav Petkov <bp@...e.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Brian Gerst <brgerst@...il.com>,
        Chris Metcalf <cmetcalf@...lanox.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Huang Rui <ray.huang@....com>, Jiri Slaby <jslaby@...e.cz>,
        Jonathan Corbet <corbet@....net>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Chen Yucong <slaoub@...il.com>,
        Alexandre Julliard <julliard@...ehq.org>,
        Fenghua Yu <fenghua.yu@...el.com>,
        "Ravi V. Shankar" <ravi.v.shankar@...el.com>,
        Shuah Khan <shuah@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        X86 ML <x86@...nel.org>, linux-msdos@...r.kernel.org,
        wine-devel@...ehq.org
Subject: 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ