X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1566071222; bh=l52jy2oUCpuaRPS8J7Bv0ADYRdbPR2jZmicwZ2jsIUo=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=OMpQBF/V4gKkUNB774mUlA4Zx3cLwLCulAONyAh9rdcMLoURkNvvGueGR/jgs445f isxuvAI6hMhrGFdPQdEbWHeqeYAV0aKag5rbKMVuaxpBd/7yTmVc1ZYhfBcNQetqHQ k2dAf3aq3u1XGUcm9GNMy2gprsM67yljd3mD6PcE= Authentication-Results: mxback15j.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: [PATCH] exec: fix inversions in leak detection logic To: djgpp AT delorie DOT com References: <964e3268-2f75-ee73-ab5a-b01bf1aadb98 AT yandex DOT ru> From: "stsp (stsp2 AT yandex DOT ru) [via djgpp AT delorie DOT com]" Message-ID: <19c9edb1-5813-bac2-68dc-59d3fb07d81f@yandex.ru> Date: Sat, 17 Aug 2019 22:47:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-MW Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id x7HJlovT001612 Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 17.08.2019 22:02, Rod Pemberton пишет: >> This is obviously >> wrong, as "changed" means that __dpmi_free_ldt_descriptor() actually >> worked and set the NP bit. > If the NP bit is set for __dpmi_free_ldt_descriptor(), wouldn't that > imply the 0xf0 mask was incorrect, but the main code logic is still > correct? ... I don't think so. Changing S bit (not sure how it works in LDT though) or reducing DPL equally well makes the descriptor inaccessible for user space (same as P=0). > I.e., it appears to me that they're attempting to detect a change of > descriptors, a "leak", if there is a change in the lar byte. That > would seem to be valid, if NP isn't modified by > __dpmi_free_ldt_descriptor(). Is NP supposed to be modified by > __dpmi_free_ldt_descriptor() or not? ... If NP (actually P) isn't modified, then DPL can be reduced - same effect. Only not doing anything at all is a leak. Obviously: if the "free" function does nothing - its a leak. You can't deduce a leak by checking that the "free" function did "something" (whatever it is); you should instead see what it did NOT do. > You're patch seems to be detecting /NO CHANGE/ of descriptor, i.e., not > a descriptor leak, NO CHANGE by a "free" function is, by definition, a leak. I don't know any other way of detecting a leak. > at which point "lie about lar" code is executed upon "lie about lar" is strange, to say the least. There is no way I am aware of, in x86, to trap the lar, so I am very surprised lar can ever lie. __dpmi_get_descriptor() have much more chances to lie. > the non-leaked descriptor. Why "lie about lar" when there is no > descriptor leak? ... Because they don't trust lar and think the leak is there nevertheless... Impossible, yes, I agree. But its not me who wrote that, and I have no idea why. The only thing that is correct in that code, is this comment: --- If the get descriptor call fails we also know this descriptor is currently not user allocated. --- Which means freed! And even from that you can see the condition was inverted. This is the only valid sentense there, and I suggest to trust it, rather than any code that surrounds it. > I'm confused by this patch, but I'm also not familiar with what the > code does. Even so, I suspect you fixed the problem in the wrong > manner. Could you try only modifying the mask to see if that fixes > your issue? This will make thing very DPMI-host-dependent. One host only clears P, another one can do other things.