Mail Archives: djgpp/2019/08/17/15:04:38
On Sat, 17 Aug 2019 19:18:10 +0300
"Stas Sergeev (stsp2 AT yandex DOT ru) [via djgpp AT delorie DOT com]"
<djgpp AT delorie DOT com> wrote:
> For some reason the conditions in the leak detection logic
> were all inverted.
...
> They tested lar before and after descriptor
> free, and assumed a leak if the lar byte changed.
Yes.
> 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.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? ...
You're patch seems to be detecting /NO CHANGE/ of descriptor, i.e., not
a descriptor leak, at which point "lie about lar" code is executed upon
the non-leaked descriptor. Why "lie about lar" when there is no
descriptor leak? ...
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?
Rod Pemberton
--
Let me say it yet again. Reducing gun violence doesn't reduce
violence. Dead is dead, whether by gun, car, hammer, club, or knife.
- Raw text -