<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/arch, branch v3.18.2</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>groups: Consolidate the setgroups permission checks</title>
<updated>2015-01-08T18:30:25+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2014-12-05T23:19:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e726c9a0a24b1381b2714dbeca322ab446fccb4a'/>
<id>e726c9a0a24b1381b2714dbeca322ab446fccb4a</id>
<content type='text'>
commit 7ff4d90b4c24a03666f296c3d4878cd39001e81e upstream.

Today there are 3 instances of setgroups and due to an oversight their
permission checking has diverged.  Add a common function so that
they may all share the same permission checking code.

This corrects the current oversight in the current permission checks
and adds a helper to avoid this in the future.

A user namespace security fix will update this new helper, shortly.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7ff4d90b4c24a03666f296c3d4878cd39001e81e upstream.

Today there are 3 instances of setgroups and due to an oversight their
permission checking has diverged.  Add a common function so that
they may all share the same permission checking code.

This corrects the current oversight in the current permission checks
and adds a helper to avoid this in the future.

A user namespace security fix will update this new helper, shortly.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86/microcode/intel: Fish out the stashed microcode for the BSP</title>
<updated>2015-01-08T18:30:22+00:00</updated>
<author>
<name>Borislav Petkov</name>
<email>bp@suse.de</email>
</author>
<published>2014-12-08T11:08:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f3d4175f055094fca46a81d0066c692c8a7a7bd5'/>
<id>f3d4175f055094fca46a81d0066c692c8a7a7bd5</id>
<content type='text'>
commit 25cdb9c86826f8d035d8aaa07fc36832e76bd8a0 upstream.

I'm such a moron! The simple solution of saving the BSP patch
for use on resume was too simple (and wrong!), hint:
sizeof(struct microcode_intel).

What needs to be done instead is to fish out the microcode patch
we have stashed previously and apply that on the BSP in case the
late loader hasn't been utilized.

So do that instead.

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Link: http://lkml.kernel.org/r/20141208110820.GB20057@pd.tnic
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 25cdb9c86826f8d035d8aaa07fc36832e76bd8a0 upstream.

I'm such a moron! The simple solution of saving the BSP patch
for use on resume was too simple (and wrong!), hint:
sizeof(struct microcode_intel).

What needs to be done instead is to fish out the microcode patch
we have stashed previously and apply that on the BSP in case the
late loader hasn't been utilized.

So do that instead.

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Link: http://lkml.kernel.org/r/20141208110820.GB20057@pd.tnic
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86, microcode: Reload microcode on resume</title>
<updated>2015-01-08T18:30:22+00:00</updated>
<author>
<name>Borislav Petkov</name>
<email>bp@suse.de</email>
</author>
<published>2014-12-03T16:21:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d239198442d300710a2389449a583edbcfb68581'/>
<id>d239198442d300710a2389449a583edbcfb68581</id>
<content type='text'>
commit fbae4ba8c4a387e306adc9c710e5c225cece7678 upstream.

Normally, we do reapply microcode on resume. However, in the cases where
that microcode comes from the early loader and the late loader hasn't
been utilized yet, there's no easy way for us to go and apply the patch
applied during boot by the early loader.

Thus, reuse the patch stashed by the early loader for the BSP.

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit fbae4ba8c4a387e306adc9c710e5c225cece7678 upstream.

Normally, we do reapply microcode on resume. However, in the cases where
that microcode comes from the early loader and the late loader hasn't
been utilized yet, there's no easy way for us to go and apply the patch
applied during boot by the early loader.

Thus, reuse the patch stashed by the early loader for the BSP.

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86, microcode: Don't initialize microcode code on paravirt</title>
<updated>2015-01-08T18:30:22+00:00</updated>
<author>
<name>Boris Ostrovsky</name>
<email>boris.ostrovsky@oracle.com</email>
</author>
<published>2014-12-01T21:27:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=44c4db3ab0378564d40f9b6aafd12908cdcb97ca'/>
<id>44c4db3ab0378564d40f9b6aafd12908cdcb97ca</id>
<content type='text'>
commit a18a0f6850d4b286a5ebf02cd5b22fe496b86349 upstream.

Paravirtual guests are not expected to load microcode into processors
and therefore it is not necessary to initialize microcode loading
logic.

In fact, under certain circumstances initializing this logic may cause
the guest to crash. Specifically, 32-bit kernels use __pa_nodebug()
macro which does not work in Xen (the code path that leads to this macro
happens during resume when we call mc_bp_resume()-&gt;load_ucode_ap()
-&gt;check_loader_disabled_ap())

Signed-off-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Link: http://lkml.kernel.org/r/1417469264-31470-1-git-send-email-boris.ostrovsky@oracle.com
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a18a0f6850d4b286a5ebf02cd5b22fe496b86349 upstream.

Paravirtual guests are not expected to load microcode into processors
and therefore it is not necessary to initialize microcode loading
logic.

In fact, under certain circumstances initializing this logic may cause
the guest to crash. Specifically, 32-bit kernels use __pa_nodebug()
macro which does not work in Xen (the code path that leads to this macro
happens during resume when we call mc_bp_resume()-&gt;load_ucode_ap()
-&gt;check_loader_disabled_ap())

Signed-off-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Link: http://lkml.kernel.org/r/1417469264-31470-1-git-send-email-boris.ostrovsky@oracle.com
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86, microcode, intel: Drop unused parameter</title>
<updated>2015-01-08T18:30:22+00:00</updated>
<author>
<name>Borislav Petkov</name>
<email>bp@suse.de</email>
</author>
<published>2014-12-01T16:50:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=97d0906a8988184ebabe8e5836c00ce77f8d2284'/>
<id>97d0906a8988184ebabe8e5836c00ce77f8d2284</id>
<content type='text'>
commit 47768626c6db42cd06ff077ba12dd2cb10ab818b upstream.

apply_microcode_early() doesn't use mc_saved_data, kill it.

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 47768626c6db42cd06ff077ba12dd2cb10ab818b upstream.

apply_microcode_early() doesn't use mc_saved_data, kill it.

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86, microcode, AMD: Do not use smp_processor_id() in preemtible context</title>
<updated>2015-01-08T18:30:22+00:00</updated>
<author>
<name>Borislav Petkov</name>
<email>bp@suse.de</email>
</author>
<published>2014-12-01T10:12:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6a76bc2d9e7a1d5184692f5dc9c2c183d65f53e4'/>
<id>6a76bc2d9e7a1d5184692f5dc9c2c183d65f53e4</id>
<content type='text'>
commit 2ef84b3bb97f03332f0c1edb4466b1750dcf97b5 upstream.

Hand down the cpu number instead, otherwise lockdep screams when doing

echo 1 &gt; /sys/devices/system/cpu/microcode/reload.

BUG: using smp_processor_id() in preemptible [00000000] code: amd64-microcode/2470
caller is debug_smp_processor_id+0x12/0x20
CPU: 1 PID: 2470 Comm: amd64-microcode Not tainted 3.18.0-rc6+ #26
...

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Link: http://lkml.kernel.org/r/1417428741-4501-1-git-send-email-bp@alien8.de
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2ef84b3bb97f03332f0c1edb4466b1750dcf97b5 upstream.

Hand down the cpu number instead, otherwise lockdep screams when doing

echo 1 &gt; /sys/devices/system/cpu/microcode/reload.

BUG: using smp_processor_id() in preemptible [00000000] code: amd64-microcode/2470
caller is debug_smp_processor_id+0x12/0x20
CPU: 1 PID: 2470 Comm: amd64-microcode Not tainted 3.18.0-rc6+ #26
...

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Link: http://lkml.kernel.org/r/1417428741-4501-1-git-send-email-bp@alien8.de
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86/tls: Don't validate lm in set_thread_area() after all</title>
<updated>2015-01-08T18:30:21+00:00</updated>
<author>
<name>Andy Lutomirski</name>
<email>luto@amacapital.net</email>
</author>
<published>2014-12-17T22:48:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=743fce2698e4cdf6b7b34ff09567deda7f62e721'/>
<id>743fce2698e4cdf6b7b34ff09567deda7f62e721</id>
<content type='text'>
commit 3fb2f4237bb452eb4e98f6a5dbd5a445b4fed9d0 upstream.

It turns out that there's a lurking ABI issue.  GCC, when
compiling this in a 32-bit program:

struct user_desc desc = {
	.entry_number    = idx,
	.base_addr       = base,
	.limit           = 0xfffff,
	.seg_32bit       = 1,
	.contents        = 0, /* Data, grow-up */
	.read_exec_only  = 0,
	.limit_in_pages  = 1,
	.seg_not_present = 0,
	.useable         = 0,
};

will leave .lm uninitialized.  This means that anything in the
kernel that reads user_desc.lm for 32-bit tasks is unreliable.

Revert the .lm check in set_thread_area().  The value never did
anything in the first place.

Fixes: 0e58af4e1d21 ("x86/tls: Disallow unusual TLS segments")
Signed-off-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Acked-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Link: http://lkml.kernel.org/r/d7875b60e28c512f6a6fc0baf5714d58e7eaadbb.1418856405.git.luto@amacapital.net
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3fb2f4237bb452eb4e98f6a5dbd5a445b4fed9d0 upstream.

It turns out that there's a lurking ABI issue.  GCC, when
compiling this in a 32-bit program:

struct user_desc desc = {
	.entry_number    = idx,
	.base_addr       = base,
	.limit           = 0xfffff,
	.seg_32bit       = 1,
	.contents        = 0, /* Data, grow-up */
	.read_exec_only  = 0,
	.limit_in_pages  = 1,
	.seg_not_present = 0,
	.useable         = 0,
};

will leave .lm uninitialized.  This means that anything in the
kernel that reads user_desc.lm for 32-bit tasks is unreliable.

Revert the .lm check in set_thread_area().  The value never did
anything in the first place.

Fixes: 0e58af4e1d21 ("x86/tls: Disallow unusual TLS segments")
Signed-off-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Acked-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Link: http://lkml.kernel.org/r/d7875b60e28c512f6a6fc0baf5714d58e7eaadbb.1418856405.git.luto@amacapital.net
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86/asm/traps: Disable tracing and kprobes in fixup_bad_iret and sync_regs</title>
<updated>2015-01-08T18:30:21+00:00</updated>
<author>
<name>Andy Lutomirski</name>
<email>luto@amacapital.net</email>
</author>
<published>2014-11-25T01:39:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=afe83db5ddb73ffafb4669dfa2e1a3c3ad960155'/>
<id>afe83db5ddb73ffafb4669dfa2e1a3c3ad960155</id>
<content type='text'>
commit 7ddc6a2199f1da405a2fb68c40db8899b1a8cd87 upstream.

These functions can be executed on the int3 stack, so kprobes
are dangerous. Tracing is probably a bad idea, too.

Fixes: b645af2d5905 ("x86_64, traps: Rework bad_iret")
Signed-off-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Link: http://lkml.kernel.org/r/50e33d26adca60816f3ba968875801652507d0c4.1416870125.git.luto@amacapital.net
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7ddc6a2199f1da405a2fb68c40db8899b1a8cd87 upstream.

These functions can be executed on the int3 stack, so kprobes
are dangerous. Tracing is probably a bad idea, too.

Fixes: b645af2d5905 ("x86_64, traps: Rework bad_iret")
Signed-off-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Link: http://lkml.kernel.org/r/50e33d26adca60816f3ba968875801652507d0c4.1416870125.git.luto@amacapital.net
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: mvebu: fix ordering in Armada 370 .dtsi</title>
<updated>2015-01-08T18:30:21+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2014-11-14T20:43:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8f8c0add0c44554ba537a621543ded196bd91452'/>
<id>8f8c0add0c44554ba537a621543ded196bd91452</id>
<content type='text'>
commit ab1e85372168892387dd1ac171158fc8c3119be4 upstream.

Commit a095b1c78a35 ("ARM: mvebu: sort DT nodes by address")
missed placing the system-controller in the correct order.

Fixes: a095b1c78a35 ("ARM: mvebu: sort DT nodes by address")
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Acked-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lkml.kernel.org/r/20141114204333.GS27002@pengutronix.de
Signed-off-by: Jason Cooper &lt;jason@lakedaemon.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ab1e85372168892387dd1ac171158fc8c3119be4 upstream.

Commit a095b1c78a35 ("ARM: mvebu: sort DT nodes by address")
missed placing the system-controller in the correct order.

Fixes: a095b1c78a35 ("ARM: mvebu: sort DT nodes by address")
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Acked-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lkml.kernel.org/r/20141114204333.GS27002@pengutronix.de
Signed-off-by: Jason Cooper &lt;jason@lakedaemon.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: mvebu: remove conflicting muxing on Armada 370 DB</title>
<updated>2015-01-08T18:30:21+00:00</updated>
<author>
<name>Thomas Petazzoni</name>
<email>thomas.petazzoni@free-electrons.com</email>
</author>
<published>2014-10-28T16:08:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6e9c89c4063f8fc3126ddc373b2885fd84392d63'/>
<id>6e9c89c4063f8fc3126ddc373b2885fd84392d63</id>
<content type='text'>
commit b4607572ef86b288a856b9df410ea593c5371dec upstream.

Back when audio was enabled, the muxing of some MPP pins was causing
problems. However, since commit fea038ed55ae ("ARM: mvebu: Add proper
pin muxing on the Armada 370 DB board"), those problematic MPP pins
have been assigned a proper muxing for the Ethernet interfaces. This
proper muxing is now conflicting with the hog pins muxing that had
been added as part of 249f3822509b ("ARM: mvebu: add audio support to
Armada 370 DB").

Therefore, this commit simply removes the hog pins muxing, which
solves a warning a boot time due to the conflicting muxing
requirements.

Fixes: fea038ed55ae ("ARM: mvebu: Add proper pin muxing on the Armada 370 DB board")
Cc: Ezequiel Garcia &lt;ezequiel.garcia@free-electrons.com&gt;
Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Acked-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lkml.kernel.org/r/1414512524-24466-5-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper &lt;jason@lakedaemon.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b4607572ef86b288a856b9df410ea593c5371dec upstream.

Back when audio was enabled, the muxing of some MPP pins was causing
problems. However, since commit fea038ed55ae ("ARM: mvebu: Add proper
pin muxing on the Armada 370 DB board"), those problematic MPP pins
have been assigned a proper muxing for the Ethernet interfaces. This
proper muxing is now conflicting with the hog pins muxing that had
been added as part of 249f3822509b ("ARM: mvebu: add audio support to
Armada 370 DB").

Therefore, this commit simply removes the hog pins muxing, which
solves a warning a boot time due to the conflicting muxing
requirements.

Fixes: fea038ed55ae ("ARM: mvebu: Add proper pin muxing on the Armada 370 DB board")
Cc: Ezequiel Garcia &lt;ezequiel.garcia@free-electrons.com&gt;
Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Acked-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lkml.kernel.org/r/1414512524-24466-5-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper &lt;jason@lakedaemon.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
