On Mon, Sep 07, 2009 at 03:48:07PM -0500, Anthony Liguori wrote:
>>
>> int kvm_set_irq_level(kvm_context_t kvm, int irq, int level, int *status)
>> @@ -1515,6 +1546,38 @@ static void sig_ipi_handler(int n)
>> {
>> }
>>
>> +static void sigbus_handler(int n, struct signalfd_siginfo *siginfo, void *ctx)
>> +{
>> + if (siginfo->ssi_code == BUS_MCEERR_AO) {
>> + uint64_t status;
>> + unsigned long paddr;
>> + CPUState *cenv;
>> +
>> + /* Hope we are lucky for AO MCE */
>>
>
> Even if the error was limited to guest memory, it could have been generated
> by either the kernel or userspace reading guest memory, no?
Only user space reads or asynchronously detected errors
(e.g. patrol scrubbing) are reported this way. Kernel reading
corrupted memory always leads to panic currently.
>
> Does this potentially open a security hole for us? Consider the following:
>
> 1) We happen to read guest memory and that causes an MCE. For instance,
> say we're in virtio.c and we read the virtio ring.
> 2) That should trigger the kernel to generate a sigbus.
> 3) We catch sigbus, and queue an MCE for delivery.
> 4) After sigbus handler completes, we're back in virtio.c, what was the
> value of the memory operation we just completed?
Yes for any errors on accessing qemu internal memory that is not
owned by the guest image you should abort. I thought Ying's patch
did that already though, by aborting if there's no slot match.
-Andi
--
ak@xxxxxxxxxxxxxxx -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
