> If you want to actually lock down a machine to implement content
> protection, then you need secure boot without unlockable boot-loader and a
> pile more bits in userspace.
So let me take my Intel hat off for a moment.
The upstream policy has always been that we don't merge things which
don't
> How about for sensitive video streams in government offices where you
> want to avoid a spy potentially tapping the cable to see the video
> stream?
Last time I checked HDCP did not meet government security requirements -
which is hardly surprising since you can buy $10 boxes from China to
de-hd
; a console and set it
up separately to actually 'enabling' it when you make it visible and
start scribbling. I don't see any other way to make the changeover
locking saner at this point without still having huge potential stalls in
printk().
Reviewed-by: Alan Cox
> offending pages around when vxd392 attaches - i.e. we need to check the
> attached device's dma masks and if there's something offending, migrate
> the buffer with a differen shmem allocation mask. Iirc Alan Cox had
> patches to do just that (but for swapoff, stil
On Sat, 2014-03-08 at 11:25 -0800, Sean V Kelley wrote:
> On Saturday 08 Mar 2014 at 09:25:54 (+), Chris Wilson writes :
> > On Fri, Mar 07, 2014 at 05:13:51PM -0800, Sean V Kelley wrote:
> > > On VLV systems addressing 4GB of memory or greater, memory corruption was
> > > seen
> > > when init
On Fri, 2 Nov 2012 14:43:40 -0700
Jesse Barnes wrote:
> KMS drivers can potentially restore the display configuration without
> userspace help. Such drivers can set a new global, pm_vt_switch, to
> false if they support this feature. In that case, the PM layer won't VT
> switch to the suspend
> that, but how would I even configure a VT split across two adapters
> today? For vgacon we just route VGA to a single adapter, but I'm not
con2fb /dev/fb1 /dev/tty1
> Dunno about suspend vs unload, how do we deal that in other drivers like
> the disk driver for suspend for example? Overall
On Wed, 14 Nov 2012 20:43:31 +
Jesse Barnes wrote:
> SNB graphics devices have a bug that prevent them from accessing certain
> memory ranges, namely anything below 1M and in the pages listed in the
> table. So reserve those at boot if set detect a SNB gfx device on the
> CPU to avoid GPU ha
On Wed, 14 Nov 2012 13:55:34 -0800
Jesse Barnes wrote:
> On Wed, 14 Nov 2012 21:19:05 +
> Alan Cox wrote:
>
> > On Wed, 14 Nov 2012 20:43:31 +
> > Jesse Barnes wrote:
> >
> > > SNB graphics devices have a bug that prevent them from accessing
