From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752746AbbJFQkq (ORCPT ); Tue, 6 Oct 2015 12:40:46 -0400 Received: from mail-wi0-f179.google.com ([209.85.212.179]:34915 "EHLO mail-wi0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752347AbbJFQkp (ORCPT ); Tue, 6 Oct 2015 12:40:45 -0400 Subject: Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X To: "Michael S. Tsirkin" References: <1443652138-31782-1-git-send-email-stephen@networkplumber.org> <1443652138-31782-3-git-send-email-stephen@networkplumber.org> <20151001104505-mutt-send-email-mst@redhat.com> <20151005215455.GA7608@redhat.com> <20151006013000-mutt-send-email-mst@redhat.com> <561384EF.8020100@cloudius-systems.com> <20151006164259-mutt-send-email-mst@redhat.com> <5613DF71.7090207@cloudius-systems.com> <20151006175634-mutt-send-email-mst@redhat.com> Cc: hjk@hansjkoch.de, dev@dpdk.org, gregkh@linux-foundation.org, Stephen Hemminger , linux-kernel@vger.kernel.org From: Vlad Zolotarov Message-ID: <5613F989.6010503@cloudius-systems.com> Date: Tue, 6 Oct 2015 19:40:41 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20151006175634-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/06/15 18:00, Michael S. Tsirkin wrote: > On Tue, Oct 06, 2015 at 05:49:21PM +0300, Vlad Zolotarov wrote: >>> and read/write the config space. >>> This means that a single userspace bug is enough to corrupt kernel >>> memory. >> Could u, pls., provide and example of this simple bug? Because it's >> absolutely not obvious... > Stick a value that happens to match a kernel address in Msg Addr field > in an unmasked MSI-X entry. This patch neither configures MSI-X entries in the user space nor provides additional means to do so therefore this "sticking" would be a matter of some extra code that is absolutely unrelated to this patch. So, this example seems absolutely irrelevant to this particular discussion. thanks, vlad >