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]
Message-ID: <51bacda4-058b-f5e4-8f40-acc2e6f44520@list.ru>
Date:   Fri, 28 Apr 2017 01:15:19 +0300
From:   Stas Sergeev <stsp@...t.ru>
To:     Andy Lutomirski <luto@...nel.org>, Nadav Amit <namit@...are.com>
Cc:     "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Borislav Petkov <bp@...en8.de>, Rik van Riel <riel@...hat.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Michal Hocko <mhocko@...e.com>,
        Sasha Levin <sasha.levin@...cle.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v3 1/4] x86/vm86/32: Switch to flush_tlb_mm_range() in
 mark_screen_rdonly()

27.04.2017 19:08, Andy Lutomirski пишет:
> Those should probably be pgd_none(), not pgd_none_or_clear_bad().
>
> But this whole function is just garbage.  It mucks with page
> protections without even looking up the VMA.  What happens if the
> pages are file-backed?  How about chardevs?
>
> I'd like to delete it.  Stas, do you know if there's any code at all
> that uses VM86_SCREEN_BITMAP?  Some Googling didn't turn any up at
> all.
dosemu1 has this:
https://sourceforge.net/p/dosemu/code/ci/master/tree/src/env/video/video.c
Scroll down to line 255.
---

#if VIDEO_CHECK_DIRTY
if (!config_dualmon) {
vm86s.flags |= VM86_SCREEN_BITMAP;
}
#endif --- The check expands to "if 0": 
https://sourceforge.net/p/dosemu/code/ci/master/tree/src/include/video.h 
line 27: ---

#define VIDEO_CHECK_DIRTY 0 --- Plus, in video.c you can see the comment 
that basically says that this functionality was of no use (not sure what 
exactly they were saying though). dosemu2 has no traces of this code at 
all. So perfectly fine with me if you remove it. In fact, I've cleaned 
up dosemu2 from any fancy stuff of vm86(), so probably more cleanups are 
possible on kernel side. I even wanted to switch to vm86old() if not for 
the very nasty bug that vm86old() generates SIGTRAP when int3 is called 
in v86. If this is fixed (and its a 1-line fix), we can remove entire 
vm86(). :)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ