On Thu, 4 Sep 2014 07:07:39 +0200
Ingo Molnar wrote:
>
> * 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
> > 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
On Wed, 03 Sep 2014 15:25:32 -0700
"H. Peter Anvin" 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
On 2014-09-03 19:46, Andi Kleen wrote:
> "H. Peter Anvin" 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
On 2014-09-03 19:46, Andi Kleen wrote:
H. Peter Anvin h.peter.an...@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
On Wed, 03 Sep 2014 15:25:32 -0700
H. Peter Anvin h.peter.an...@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
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.
On Thu, 4 Sep 2014 07:07:39 +0200
Ingo Molnar mi...@kernel.org wrote:
* H. Peter Anvin h.peter.an...@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,
* 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
"H. Peter Anvin" 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
(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
On Wed, 03 Sep 2014 14:20:59 -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.)
For MSR I assume writing primarily - but if you
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
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
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
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
On Wed, 03 Sep 2014 14:20:59 -0700
H. Peter Anvin h.peter.an...@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
(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
H. Peter Anvin h.peter.an...@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
* H. Peter Anvin h.peter.an...@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
20 matches
Mail list logo
