From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760278Ab3BMRWY (ORCPT ); Wed, 13 Feb 2013 12:22:24 -0500 Received: from terminus.zytor.com ([198.137.202.10]:40422 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759964Ab3BMRWV (ORCPT ); Wed, 13 Feb 2013 12:22:21 -0500 Message-ID: <511BCB6E.8080102@zytor.com> Date: Wed, 13 Feb 2013 09:20:46 -0800 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Matthew Garrett CC: Borislav Petkov , Kees Cook , LKML , Thomas Gleixner , Ingo Molnar , "x86@kernel.org" , "linux-efi@vger.kernel.org" , linux-security-module Subject: Re: [PATCH] x86: Lock down MSR writing in secure boot References: <1360355671.18083.18.camel@x230.lan> <51157C9C.6030501@zytor.com> <20130208230655.GB28990@pd.tnic> <1360366012.18083.21.camel@x230.lan> <5115A4CC.3080102@zytor.com> <1360373383.18083.23.camel@x230.lan> <20130209092925.GA17728@pd.tnic> <1360422712.18083.24.camel@x230.lan> <511AE2CC.5040705@zytor.com> <1360733962.18083.30.camel@x230.lan> <511B2EB9.5070406@zytor.com> <1360736860.18083.33.camel@x230.lan> <511B33BC.9080307@zytor.com> <1360737709.18083.36.camel@x230.lan> In-Reply-To: <1360737709.18083.36.camel@x230.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/12/2013 10:41 PM, Matthew Garrett wrote: > On Tue, 2013-02-12 at 22:33 -0800, H. Peter Anvin wrote: > >> That is just batshit crazy. If you have CAP_SYS_RAWIO you can do iopl() >> which means you can reprogram your northbridge, at which point you most >> definitely *can* modify the running kernel. > > Well right, that's the point of this patchset - it adds some extra > permission checks to some of the existing CAP_SYS_RAWIO checks. > CAP_SYS_RAWIO hasn't meant "I can perform arbitrary pio and mmio" for > years - it means "I can do things that might maybe break something > somehow". So sure, removing CAP_SYS_RAWIO would give us basically all > the security we want in a secure boot environment, but it would also > block things that we *want* to work. > So, let 's see... Problem: Someone adds SYS_CAP_RAWIO to some places it definitely does not belong. Solution: Break all the *appropriate* (as defined)uses of SYS_CAP_RAWIO? What the heck? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.