RFC: Tainting the kernel on raw I/O access

RFC: Tainting the kernel on raw I/O access

[H. Peter Anvin]

In a meeting earlier today, we discussed MSR access and that it could be
used to do bad things.  The same applies to other forms of raw I/O
(/dev/mem, /dev/port, ioperm, iopl, etc.)

This is basically the same problem with which the secure boot people
have been struggling.

Peter Z. suggested we should taint the kernel on raw I/O access, and I
tend to concur.

So what I would like to suggest is that we create a new kernel helper
function which can return an error in secure boot mode and otherwise
taints the kernel with a raw I/O taint.

What do people think?

	-hpa

Re: RFC: Tainting the kernel on raw I/O access

[Matthew Garrett]

(Cc: Kees)

On Wed, Sep 03, 2014 at 02:20:59PM -0700, H. Peter Anvin wrote:
> In a meeting earlier today, we discussed MSR access and that it could be
> used to do bad things.  The same applies to other forms of raw I/O
> (/dev/mem, /dev/port, ioperm, iopl, etc.)
> 
> This is basically the same problem with which the secure boot people
> have been struggling.
> 
> Peter Z. suggested we should taint the kernel on raw I/O access, and I
> tend to concur.
> 
> So what I would like to suggest is that we create a new kernel helper
> function which can return an error in secure boot mode and otherwise
> taints the kernel with a raw I/O taint.
> 
> What do people think?

Not a bad plan, but there's a couple of places where you'd want to 
forbid stuff in Secure Boot without tainting the kernel in the generic 
use-case, so there's still some problem to solve there.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: RFC: Tainting the kernel on raw I/O access

[One Thousand Gnomes]

On Wed, 03 Sep 2014 14:20:59 -0700
"H. Peter Anvin" <h.peter.anvin@intel.com> wrote:

> In a meeting earlier today, we discussed MSR access and that it could be
> used to do bad things.  The same applies to other forms of raw I/O
> (/dev/mem, /dev/port, ioperm, iopl, etc.)

For MSR I assume writing primarily - but if you block read access you
break a ton of tools, and if you block write access you stop things like
DPTF working (which personally I couldn't care about, but other folks who
are using it to power manage their boxes might be a bit more upset 8)).
Fixing that takes you into the joyful world of whitelists.

> This is basically the same problem with which the secure boot people
> have been struggling.

Not sure that is true

"secure" boot is based upon the premise that you can't fool the machine
into booting a different OS image without the user choosing to do so in a
protected manner that prevents impersonation.

"tainting" on raw I/O is a useful debug tool. There is at best only
minimal overlap in the sense that one is a partial subset of the other
(and only partial because there are safe MSRs, I/O ports and memory
ranges).

> Peter Z. suggested we should taint the kernel on raw I/O access, and I
> tend to concur.
> 
> So what I would like to suggest is that we create a new kernel helper
> function which can return an error in secure boot mode and otherwise
> taints the kernel with a raw I/O taint.

That makes the job instantly about ten times harder. You can add taints
trivially to the kernel but every single taint that might error is a new
error path, and no doubt a new exciting pile of kernel bugs.

> What do people think?

The problem is that it's not just little bits of raw I/O. You've got a
load of kernel command line options that have the same problem and you've
got a load of things like firmware upload in the unsigned firmware case
which may in some cases also need to count but not others. Even things
like the features planned so you can inject missing DTD information int
your ACPI tables (or fix the garbage your vendor provided) raise the same
question.

What is the *actual* goal here, what is the security model, what is the
at least basic proof that it works. We've got 20 years of layered
insecurity by guesswork in the kernel already.

Also how does this work for virtual machines ? Does the hypervisor do the
taint management for ports it doesn't manage and that are not
passthrough. What about passthrough devices on a non signed guest on a
signed master.

If you just want some "detector bits" for bug report filtering them its
quite a different need to fixing "secure" boot mode. Even in the detector
bits case there should be an overall plan and some defined properties
that provide the security and which you can show should always be true.

The failure case for "detector bits" is 'the user did something dumb and
we spent a while looking at a bug that was their fault' and the fix path
is 'get around to adding a new taint'. The 'secure boot' case is a
promise of a security model which implies you can prove its at least
reasonably correct (and can be implemented to be correct).

Alan

Re: RFC: Tainting the kernel on raw I/O access

[H. Peter Anvin]

On 09/03/2014 03:20 PM, One Thousand Gnomes wrote:
> 
> If you just want some "detector bits" for bug report filtering them its
> quite a different need to fixing "secure" boot mode. Even in the detector
> bits case there should be an overall plan and some defined properties
> that provide the security and which you can show should always be true.
> 

As far as I'm concerning this is just a set of "detector bits".  My
observation was simply that this is a *subset* of what "secure boot"
will eventually need.

Secure boot will need the error path no matter what... tainting
obviously doesn't.

(As far as I'm concerned, I'd be happy tainting the kernel for any
operation that requires CAP_RAWIO, but maybe that is too extreme.)

	-hpa

Re: RFC: Tainting the kernel on raw I/O access

[One Thousand Gnomes]

On Wed, 03 Sep 2014 15:25:32 -0700
"H. Peter Anvin" <h.peter.anvin@intel.com> wrote:

> On 09/03/2014 03:20 PM, One Thousand Gnomes wrote:
> > 
> > If you just want some "detector bits" for bug report filtering them its
> > quite a different need to fixing "secure" boot mode. Even in the detector
> > bits case there should be an overall plan and some defined properties
> > that provide the security and which you can show should always be true.
> > 
> 
> As far as I'm concerning this is just a set of "detector bits".  My
> observation was simply that this is a *subset* of what "secure boot"
> will eventually need.

I think that observation is untrue. The only partially overap.
 
> (As far as I'm concerned, I'd be happy tainting the kernel for any
> operation that requires CAP_RAWIO, but maybe that is too extreme.)

You can't then for example format some types of disk in your data center.

Alan

Re: RFC: Tainting the kernel on raw I/O access

[Andi Kleen]

"H. Peter Anvin" <h.peter.anvin@intel.com> writes:

> In a meeting earlier today, we discussed MSR access and that it could be
> used to do bad things.  The same applies to other forms of raw I/O
> (/dev/mem, /dev/port, ioperm, iopl, etc.)

I don't think it makes sense to use the taint flags as a security
mechanism. They would be a very poor (and likely by itself insecure) one.

As for the original purpose of taints, I'm not aware of any
problems with MSR access or port IO causing excessive 
kernel oops reports. Are you?

If there are none I don't think it makes sense.

At least personally I use MSR accesses quite frequently
for benign purposes.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only

Re: RFC: Tainting the kernel on raw I/O access

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

On 2014-09-03 19:46, Andi Kleen wrote:
> "H. Peter Anvin" <h.peter.anvin@intel.com> writes:
> 
>> In a meeting earlier today, we discussed MSR access and that it could be
>> used to do bad things.  The same applies to other forms of raw I/O
>> (/dev/mem, /dev/port, ioperm, iopl, etc.)
> 
> I don't think it makes sense to use the taint flags as a security
> mechanism. They would be a very poor (and likely by itself insecure) one.
> 
> As for the original purpose of taints, I'm not aware of any
> problems with MSR access or port IO causing excessive 
> kernel oops reports. Are you?
Really? Either one can be used to modify the running kernel (or
microcode), and possibly even destroy hardware.  Even if it doesn't
cause an OOPS or panic, that sounds like something that we should at
least taint on.
> If there are none I don't think it makes sense.
> 
> At least personally I use MSR accesses quite frequently
> for benign purposes.
But how much of that is just reading MSR's, and of the writes, how much
are either debugging or things that the average user isn't ever going to do?


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: RFC: Tainting the kernel on raw I/O access

[One Thousand Gnomes]

> > As for the original purpose of taints, I'm not aware of any
> > problems with MSR access or port IO causing excessive 
> > kernel oops reports. Are you?

I'm not. From the bugzilla trends I don't think its a major cause, and we
can usually root out the "user with dumb external module" problem already.

> Really? Either one can be used to modify the running kernel (or
> microcode), and possibly even destroy hardware. 

At least on x86 I would hope not the latter at least on modern systems.
So the most irritating thing you can do is probably rootkit the box. It's
not as if you can't rootkit a typical distribution shipping Linux system
half a dozen other simpler ways than using I/O ports. Besides which once
someone has rootkitted your box it won't show the taint anyway !

As a security measure the tainting is next to useless.

As a debug aid it's potentially handy.

> > If there are none I don't think it makes sense.
> > 
> > At least personally I use MSR accesses quite frequently
> > for benign purposes.
> But how much of that is just reading MSR's, and of the writes, how much
> are either debugging or things that the average user isn't ever going to do?

Most of the uses are benign and sensible things like power monitoring
tools. 

Alan

Re: RFC: Tainting the kernel on raw I/O access

[Ingo Molnar]

* H. Peter Anvin <h.peter.anvin@intel.com> wrote:

> In a meeting earlier today, we discussed MSR access and that it could be
> used to do bad things.  The same applies to other forms of raw I/O
> (/dev/mem, /dev/port, ioperm, iopl, etc.)
> 
> This is basically the same problem with which the secure boot people
> have been struggling.
> 
> Peter Z. suggested we should taint the kernel on raw I/O access, and I
> tend to concur.

Lets start with the 'only for developers and the crazy' 
interfaces, like /dev/msr access, and extend it step by step?

Thanks,

	Ingo

Re: RFC: Tainting the kernel on raw I/O access

[One Thousand Gnomes]

On Thu, 4 Sep 2014 07:07:39 +0200
Ingo Molnar <mingo@kernel.org> wrote:

> 
> * H. Peter Anvin <h.peter.anvin@intel.com> wrote:
> 
> > In a meeting earlier today, we discussed MSR access and that it could be
> > used to do bad things.  The same applies to other forms of raw I/O
> > (/dev/mem, /dev/port, ioperm, iopl, etc.)
> > 
> > This is basically the same problem with which the secure boot people
> > have been struggling.
> > 
> > Peter Z. suggested we should taint the kernel on raw I/O access, and I
> > tend to concur.
> 
> Lets start with the 'only for developers and the crazy' 
> interfaces, like /dev/msr access, and extend it step by step?

/dev/msr is used by standard distribution tools like powertop, and by
chromeos power management layers like dptf.

msr writes might fit the crazy book but I think you'd need to take a
close look at the standard tools first

This is the need a whitelist problem.

Alan