On Fri, Apr 05, 2019 at 12:54:31AM +0200, Jann Horn wrote:
> [ 159.485731] microcode: CPU7 found a matching microcode update with
> version 0x25 (current=0x19)
Yeah, that printk can be kinda misleading :)
> I thought I had checked /sys/devices/system/cpu/cpu0/microcode/version
> afterwards. But
On Thu, Apr 4, 2019 at 6:47 PM Borislav Petkov wrote:
> On Thu, Apr 04, 2019 at 06:31:37PM +0200, Jann Horn wrote:
> > Uuuh. I *definitely* tested this. I ran this yesterday evening on my
> > home machine, on top of commit
> > 14c741de93861749dfb60b4964028541f5c506ca from Linus' tree, plus two
>
On Thu, Apr 04, 2019 at 06:31:37PM +0200, Jann Horn wrote:
> Uuuh. I *definitely* tested this. I ran this yesterday evening on my
> home machine, on top of commit
> 14c741de93861749dfb60b4964028541f5c506ca from Linus' tree, plus two
> cherry-picked fixes for drm/ttm. I specifically made sure that
On Thu, Apr 4, 2019 at 6:28 PM Borislav Petkov wrote:
>
> On Thu, Apr 04, 2019 at 01:11:28PM +0200, Jann Horn wrote:
> > This changes generic_load_microcode() to use the iov_iter API instead of
> > an open-coded version. This allows us to avoid explicitly casting between
> > user and kernel
On Thu, Apr 04, 2019 at 01:11:28PM +0200, Jann Horn wrote:
> This changes generic_load_microcode() to use the iov_iter API instead of
> an open-coded version. This allows us to avoid explicitly casting between
> user and kernel pointers.
>
> Because the iov_iter API makes it hard to read the same
This changes generic_load_microcode() to use the iov_iter API instead of
an open-coded version. This allows us to avoid explicitly casting between
user and kernel pointers.
Because the iov_iter API makes it hard to read the same location twice, as
a side effect, this also fixes a double-read of
6 matches
Mail list logo
