Mail Archives: djgpp/2019/08/17/15:51:44
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.
- Raw text -