linux-kernel - Re: [RFC PATCH 01/17] shm-signal: shared-memory signals

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49D285AE.7030604@redhat.com>
Date:	Wed, 01 Apr 2009 00:05:50 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Gregory Haskins <ghaskins@...ell.com>
CC:	linux-kernel@...r.kernel.org, agraf@...e.de, pmullaney@...ell.com,
	pmorreale@...ell.com, anthony@...emonkey.ws, rusty@...tcorp.com.au,
	netdev@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [RFC PATCH 01/17] shm-signal: shared-memory signals

Gregory Haskins wrote:
>>> +struct shm_signal_irq {
>>> +    __u8                  enabled;
>>> +    __u8                  pending;
>>> +    __u8                  dirty;
>>> +};
>>>   
>>>       
>> Some ABIs may choose to pad this, suggest explicit padding.
>>     
>
> Yeah, good idea.  What is the official way to do this these days?  Are
> GCC pragmas allowed?
>
>   

I just add a __u8 pad[5] in such cases.

>>> +
>>> +struct shm_signal;
>>> +
>>> +struct shm_signal_ops {
>>> +    int      (*inject)(struct shm_signal *s);
>>> +    void     (*fault)(struct shm_signal *s, const char *fmt, ...);
>>>   
>>>       
>> Eww.  Must we involve strings and printf formats?
>>     
>
> This is still somewhat of a immature part of the design.  Its supposed
> to be used so that by default, its a panic.  But on the host side, we
> can do something like inject a machine-check.  That way malicious/broken
> guests cannot (should not? ;) be able to take down the host.  Note today
> I do not map this to anything other than the default panic, so this
> needs some love.
>
> But given the asynchronous nature of the fault, I want to be sure we
> have decent accounting to avoid bug reports like "silent MCE kills the
> guest" ;)  At least this way, we can log the fault string somewhere to
> get a clue.
>   

I see.

This raises a point I've been thinking of - the symmetrical nature of 
the API vs the assymetrical nature of guest/host or user/kernel 
interfaces.  This is most pronounced in ->inject(); in the host->guest 
direction this is async (host can continue processing while the guest is 
handling the interrupt), whereas in the guest->host direction it is 
synchronous (the guest is blocked while the host is processing the call, 
unless the host explicitly hands off work to a different thread).


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/