All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Martin Pärtel" <martin.partel@gmail.com>
To: user-mode-linux-devel@lists.sourceforge.net
Cc: Richard Weinberger <richard@nod.at>
Subject: Re: [uml-devel] [PATCH] um: pass siginfo to guest process
Date: Fri, 08 Jun 2012 00:41:33 +0300	[thread overview]
Message-ID: <4FD1200D.8030101@gmail.com> (raw)
In-Reply-To: <4FD11C88.6090308@nod.at>

(ack, forgot to reply to list)

On 06/08/2012 12:26 AM, Richard Weinberger wrote:

> Am 07.06.2012 22:59, schrieb Martin Pärtel:
>> Signal handlers in UML guest processes now get correct siginfo_t fields
>> for SIGTRAP, SIGFPE, SIGILL and SIGBUS. Specifically, si_addr and si_code
>> are now correct where previously they were si_addr = NULL and si_code = 128.
>
> What exactly is broken?
> In my SIGSEGV test case si_addr is not NULL, it contains the correct faulting address.
>


SIGSEGV is probably fine. At least SIGFPE is not. Test program below.



>> +
>> +			ptrace(PTRACE_GETSIGINFO, pid, 0,&si);
>> +
>
> Doesn't this leak the host siginfo_t into the guest?
>


Docs for PTRACE_GETSIGINFO say `si' gets a copy. After that, `si' is not 
used for anything other than giving it to the guest. But I really can't 
say I understand the surrounding code too well so please review carefully :)



---
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <signal.h>

void handler(int num, siginfo_t *info, void *data)
{
     printf("CAUGHT SIGNAL %d - si_addr = %p - si_code = %d\n", num, 
info->si_addr, info->si_code);
     _exit(1);
}

int main()
{
     struct sigaction act;
     act.sa_sigaction = &handler;
     sigemptyset(&act.sa_mask);
     act.sa_flags = SA_SIGINFO;

     sigaction(SIGFPE, &act, NULL);

     printf("%d\n", 3 / 0);

     return 0;
}

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel


  reply	other threads:[~2012-06-07 21:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-07 20:59 [uml-devel] [PATCH] um: pass siginfo to guest process Martin Pärtel
2012-06-07 21:26 ` Richard Weinberger
2012-06-07 21:41   ` Martin Pärtel [this message]
     [not found]   ` <4FD11F90.5080407@gmail.com>
2012-06-07 22:07     ` Richard Weinberger
2012-06-07 22:42       ` Martin Pärtel
2012-06-07 22:47         ` Richard Weinberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FD1200D.8030101@gmail.com \
    --to=martin.partel@gmail.com \
    --cc=richard@nod.at \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.