Received: by 10.192.165.148 with SMTP id m20csp3713242imm; Mon, 23 Apr 2018 11:01:41 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/flQQ65NqTw4bW3vprS/kLCMDXFeRuzlfS7xUQyQbIwc8LY71+RR3j25PQWgBSupraDWvZ X-Received: by 10.98.214.5 with SMTP id r5mr12979229pfg.8.1524506501655; Mon, 23 Apr 2018 11:01:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524506501; cv=none; d=google.com; s=arc-20160816; b=GlVIrQgErYBoSzj+qnlw7IfCtA7oFv56XD1ip4PKTKQfhYucxcvYneS2w4u9IwAqAz XjDUSRaJjZjUCMwt5RIu+zoUcbWoPEGCG6TRuN64hbDQ6z7yePjivh1Rju++7gLUTWoP S+uAXrEUCmR4G4lRyyLqUDsGwm/FCyP6qzPxCJPSJXlM8G7MvRQ8cS0D6zY7kmTWL1cs sfAJW83gFx9rZC86rG0Uq0jbccNL7jn50W0dEW+beoMUAVLhpGRIDIbubVU8RsDzoyot fykHvzVBm5AO9y7fhd/uo/Rv8im03h3qs/HvbPY99RA5lRDI41jSyINOhCJHiPg+p+r4 06WQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=j5S9liaOUonMLLBiXOi3inFUu9lFdKjlL8gI9/2j1KM=; b=yiqSE42a7vX9MhV7UEIjVb6rEjT00kbSVpD6VToPWDKw/Tlnt3T1JVosEycemMXqvF dSSqAHRhyGwH5JDywozBsmoyOCTB9fX2hJ0FfS/42hmjOOqIaaZSwtm2PNn76fI3RqOj nu/Ag0aU+p3JvZWyRvIi7R7pHjkMzr7F3HutagMAxCX/r+/pyCuse0BeDQitstXA74aV 5ArjE4fFn1zuo8OCpuaBLht4If28qEdkfCPVYYIjs6Dz/EdMW85dtP2VH0AHmbDIBDqY Z6andqb3Grj3oAlBETRlMKqslzQUK7HAbFF/FPpTCSGUyG8x2N+9xWgeEvfweocBpzRQ QT4w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r11si11724411pff.160.2018.04.23.11.01.26; Mon, 23 Apr 2018 11:01:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932362AbeDWSAN (ORCPT + 99 others); Mon, 23 Apr 2018 14:00:13 -0400 Received: from mx2.suse.de ([195.135.220.15]:36024 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932200AbeDWSAL (ORCPT ); Mon, 23 Apr 2018 14:00:11 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 44918AED3; Mon, 23 Apr 2018 18:00:10 +0000 (UTC) Date: Mon, 23 Apr 2018 20:00:09 +0200 From: Joerg Roedel To: Kees Cook Cc: Joerg Roedel , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , X86 ML , LKML , Linux-MM , Linus Torvalds , Andy Lutomirski , Dave Hansen , Josh Poimboeuf , Juergen Gross , Peter Zijlstra , Borislav Petkov , Jiri Kosina , Boris Ostrovsky , Brian Gerst , David Laight , Denys Vlasenko , Eduardo Valentin , Greg KH , Will Deacon , Anthony Liguori , Daniel Gruss , Hugh Dickins , Andrea Arcangeli , Waiman Long , Pavel Machek , "David H . Gutteridge" Subject: Re: [PATCH 27/37] x86/mm/pti: Keep permissions when cloning kernel text in pti_clone_kernel_text() Message-ID: <20180423180009.tubsdgxlmo56usq7@suse.de> References: <1524498460-25530-1-git-send-email-joro@8bytes.org> <1524498460-25530-28-git-send-email-joro@8bytes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 23, 2018 at 10:06:20AM -0700, Kees Cook wrote: > Why are there R/W text mappings in this range? I find that to be > unexpected. Shouldn't CONFIG_DEBUG_WX already complain if that were > true? It actually complains, I have seen that with the base-kernel too. I guess this is because of the different mark_rodata_ro() and mark_nxdata_nx() implementations between 32 and 64 bit. They actually protect different regions, I think one reason is that some regions are not hupe-page aligned on 32 bit and doing the right protections as on 64 bit would require to split the 2M mappings into 4k mappings. But I havn't looked deeper into that and whether it can be unified and fixed for 32 bit. It is probably out-of-scope for this patch-set. Regards, Joerg