Re: [PATCH] cryptui: use add_oid_to_usage correctly (Coverity)

2013-02-02 Thread Juan Lang
On Sat, Feb 2, 2013 at 5:05 AM, Marcus Meissner wrote:

> On Fri, Feb 01, 2013 at 03:48:27PM -0800, Juan Lang wrote:
> > On Fri, Feb 1, 2013 at 3:45 PM, Juan Lang  wrote:
> >
> > > Hi Marcus,
> > >
> > > -add_oid_to_usage(usage, ptr);
> > > +usage = add_oid_to_usage(usage, ptr);
> > >
> > > This looks fine, but would you mind making the same change on line 337?
> > >
> > > Actually, perhaps I hit sent too early. If this memory allocation
> fails,
> > which is the only situation under which add_oid_to_usage doesn't just
> > return its first parameter, it'll immediately crash on the next
> invocation
> > with a NULL pointer dereference.
> >
> > I'm not sure it's worth all the trouble in an out of memory situation.
> > Perhaps just remove the return value and let the caller crash.
>
> Actually the loop around checks that as a condition and would lead to
> return NULL:
>
> for (ptr = usageStr, comma = strchr(ptr, ','); usage && ptr &&
> *ptr;
>
> For the second one the loop around does not catch it.
>
> I think the add_oid_to_usage() should not even do it this way  and not
> touch "usage"
> at all, but instead return a memory allocation error and let the caller
> handle it:/
>
> Or just let it crash.
>

Yeah, I think just letting it crash is better than trying to sort it all
out. Thanks, and sorry for the confusing and buggy code :/
--Juan



Re: [PATCH] cryptui: use add_oid_to_usage correctly (Coverity)

2013-02-02 Thread Marcus Meissner
On Fri, Feb 01, 2013 at 03:48:27PM -0800, Juan Lang wrote:
> On Fri, Feb 1, 2013 at 3:45 PM, Juan Lang  wrote:
> 
> > Hi Marcus,
> >
> > -add_oid_to_usage(usage, ptr);
> > +usage = add_oid_to_usage(usage, ptr);
> >
> > This looks fine, but would you mind making the same change on line 337?
> >
> > Actually, perhaps I hit sent too early. If this memory allocation fails,
> which is the only situation under which add_oid_to_usage doesn't just
> return its first parameter, it'll immediately crash on the next invocation
> with a NULL pointer dereference.
> 
> I'm not sure it's worth all the trouble in an out of memory situation.
> Perhaps just remove the return value and let the caller crash.

Actually the loop around checks that as a condition and would lead to return 
NULL:

for (ptr = usageStr, comma = strchr(ptr, ','); usage && ptr && *ptr;

For the second one the loop around does not catch it.

I think the add_oid_to_usage() should not even do it this way  and not touch 
"usage"
at all, but instead return a memory allocation error and let the caller handle 
it:/

Or just let it crash.

Ciao, Marcus




Re: [PATCH] Support for game DRM which overwrite the GS segment selector

2013-02-02 Thread Austin English
On Jan 31, 2013 8:15 AM, "Alessandro Pignotti" 
wrote:
>
> Hi again,
>
> I've quickly implemented the aforementioned idea of fixing the segment
> in the segfault handler when needed. I'm attaching my proposed patch.
>
> Alessandro
>
> Il giorno mer, 30/01/2013 alle 16.44 +0100, Alessandro Pignotti ha
> scritto:
> > Hi everyone,
> >
> > I'm trying to get a specific game which employs a seemingly custom
> > protection scheme to work. The DRM does various bad things as usual, but
> > a very bad one is manipulating to GS segment selector and setting it to
> > a NULL segment. The GS segment is used by libc though in various ways
> > (stack protection and syscall support, and probably others).
> >
> > I managed to get the activation procedure to go further and further by
> > enclosing each offending syscall using the following 2 macros.
> >
> > #define SAFE_GS_START \
> > do { \
> > wine_set_gs(ntdll_get_thread_data()->gs); \
> > do
> >
> > #define SAFE_GS_END \
> > while(0); \
> > } while(0)
> >
> > Still, this method is very cumbersome since system calls happens in many
> > places even outside of ntdll. Fixing the GS is also needed to support
> > sigsetjmp which is used by wine's exception handling.
> >
> > I'd like to ask for feedback about what would be a sane way of
> > supporting this application. A possible solution would be to modify
> > wine's segfault handler to check if the instruction has a GS prefix
> > (0x65 IIRC) and try to execute the instruction again after fixing the
> > GS.
> >
> > Please keep me in CC since I'm not subscribed to the ML.
> >
> > Regards,
> > Alessandro Pignotti

Out of curiosity, what game is this? What protection does Protection ID
show it uses?