linux-kernel - Re: [PATCH] Xen: Fix retry calls into PRIVCMD

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: <5373EBB3-5CF1-4A2F-B821-1DD788877F75@gridcentric.ca>
Date:	Thu, 1 Aug 2013 07:49:37 -0400
From:	Andres Lagar-Cavilla <andreslc@...dcentric.ca>
To:	David Vrabel <david.vrabel@...rix.com>
Cc:	Andres Lagar-Cavilla <andreslc@...dcentric.ca>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Andres Lagar-Cavilla <andres@...arcavilla.com>,
	<boris.ostrovsky@...cle.com>
Subject: Re: [PATCH] Xen: Fix retry calls into PRIVCMD_MMAPBATCH*.

On Aug 1, 2013, at 7:23 AM, David Vrabel <david.vrabel@...rix.com> wrote:

> On 01/08/13 04:30, Andres Lagar-Cavilla wrote:
>> -- Resend as I haven't seen this hit the lists. Maybe some smtp misconfig. Apologies. Also expanded cc --
>> 
>> When a foreign mapper attempts to map guest frames that are paged out,
>> the mapper receives an ENOENT response and will have to try again
>> while a helper process pages the target frame back in.
>> 
>> Gating checks on PRIVCMD_MMAPBATCH* ioctl args were preventing retries
>> of mapping calls.
> 
> This breaks the auto_translated_physmap case as will allocate another
> set of empty pages and leak the previous set.

David,
not able to follow you here. Under what circumstances will another set of empty pages be allocated? And where? are we talking page table pages?

> 
> This privcmd_enforce_singleshot_mapping() stuff seems very odd anyway.
> Does anyone know what it was for originally?  It would be preferrable if
> we could update the mappings with a new set of foreign MFNs without
> having to tear down the VMA and recreate a new VMA.

I believe it's mostly historical. I agree with you on principle, but recreating VMAs is super-cheap.

Andres
> 
>> --- a/drivers/xen/privcmd.c
>> +++ b/drivers/xen/privcmd.c
> [...]
>> +/* For MMAPBATCH*. This allows asserting the singleshot mapping
>> + * on a per pfn/pte basis. Mapping calls that fail with ENOENT
>> + * can be then retried until success. */
> 
> Comment coding style.
> 
> David

--
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/