<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/x86/boot, branch linux-3.18.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.18.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.18.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2019-02-06T16:34:52Z</updated>
<entry>
<title>x86/kaslr: Fix incorrect i8254 outb() parameters</title>
<updated>2019-02-06T16:34:52Z</updated>
<author>
<name>Daniel Drake</name>
</author>
<published>2019-01-07T03:40:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=444fc5b3c8040ec3b50b8df83f73184b6496d5e7'/>
<id>urn:sha1:444fc5b3c8040ec3b50b8df83f73184b6496d5e7</id>
<content type='text'>
commit 7e6fc2f50a3197d0e82d1c0e86282976c9e6c8a4 upstream.

The outb() function takes parameters value and port, in that order.  Fix
the parameters used in the kalsr i8254 fallback code.

Fixes: 5bfce5ef55cb ("x86, kaslr: Provide randomness functions")
Signed-off-by: Daniel Drake &lt;drake@endlessm.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: bp@alien8.de
Cc: hpa@zytor.com
Cc: linux@endlessm.com
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20190107034024.15005-1-drake@endlessm.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>x86: boot: Fix EFI stub alignment</title>
<updated>2018-11-22T06:32:42Z</updated>
<author>
<name>Ben Hutchings</name>
</author>
<published>2018-09-16T15:22:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=024cbc8a7ec3d7d2db5f3f114dfdec1a98c98b05'/>
<id>urn:sha1:024cbc8a7ec3d7d2db5f3f114dfdec1a98c98b05</id>
<content type='text'>
[ Upstream commit 9c1442a9d039a1a3302fa93e9a11001c5f23b624 ]

We currently align the end of the compressed image to a multiple of
16.  However, the PE-COFF header included in the EFI stub says that
the file alignment is 32 bytes, and when adding an EFI signature to
the file it must first be padded to this alignment.

sbsigntool commands warn about this:

  warning: file-aligned section .text extends beyond end of file
  warning: checksum areas are greater than image size. Invalid section table?

Worse, pesign -at least when creating a detached signature- uses the
hash of the unpadded file, resulting in an invalid signature if
padding is required.

Avoid both these problems by increasing alignment to 32 bytes when
CONFIG_EFI_STUB is enabled.

Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>efi: Avoid potential crashes, fix the 'struct efi_pci_io_protocol_32' definition for mixed mode</title>
<updated>2018-05-25T08:54:54Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2018-05-04T05:59:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=56bd8525fd87605462f8090d25ccfdf4e1d68065'/>
<id>urn:sha1:56bd8525fd87605462f8090d25ccfdf4e1d68065</id>
<content type='text'>
commit 0b3225ab9407f557a8e20f23f37aa7236c10a9b1 upstream.

Mixed mode allows a kernel built for x86_64 to interact with 32-bit
EFI firmware, but requires us to define all struct definitions carefully
when it comes to pointer sizes.

'struct efi_pci_io_protocol_32' currently uses a 'void *' for the
'romimage' field, which will be interpreted as a 64-bit field
on such kernels, potentially resulting in bogus memory references
and subsequent crashes.

Tested-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Matt Fleming &lt;matt@codeblueprint.co.uk&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180504060003.19618-13-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>x86-64: Handle PC-relative relocations on per-CPU data</title>
<updated>2017-09-02T05:05:46Z</updated>
<author>
<name>Jan Beulich</name>
</author>
<published>2014-11-04T08:50:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=edb9d2d5e647e7a8521b0d35f8452deb02dfd138'/>
<id>urn:sha1:edb9d2d5e647e7a8521b0d35f8452deb02dfd138</id>
<content type='text'>
commit 6d24c5f72dfb26e5fa7f02fa9266dfdbae41adba upstream.

This is in preparation of using RIP-relative addressing in many of the
per-CPU accesses.

Signed-off-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Link: http://lkml.kernel.org/r/5458A15A0200007800044A9A@mail.emea.novell.com
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>x86/boot: Add missing declaration of string functions</title>
<updated>2017-08-11T16:30:15Z</updated>
<author>
<name>Nicholas Mc Guire</name>
</author>
<published>2017-01-07T09:38:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=aff24165ba49f42332012661a6b2c040f2404c60'/>
<id>urn:sha1:aff24165ba49f42332012661a6b2c040f2404c60</id>
<content type='text'>
[ Upstream commit fac69d0efad08fc15e4dbfc116830782acc0dc9a ]

Add the missing declarations of basic string functions to string.h to allow
a clean build.

Fixes: 5be865661516 ("String-handling functions for the new x86 setup code.")
Signed-off-by: Nicholas Mc Guire &lt;hofrat@osadl.org&gt;
Link: http://lkml.kernel.org/r/1483781911-21399-1-git-send-email-hofrat@osadl.org
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>x86/boot: Fix BSS corruption/overwrite bug in early x86 kernel startup</title>
<updated>2017-05-20T12:18:41Z</updated>
<author>
<name>Ashish Kalra</name>
</author>
<published>2017-04-19T15:20:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3e576d765dc98ef004bd1706ab27733c50c7b976'/>
<id>urn:sha1:3e576d765dc98ef004bd1706ab27733c50c7b976</id>
<content type='text'>
commit d594aa0277e541bb997aef0bc0a55172d8138340 upstream.

The minimum size for a new stack (512 bytes) setup for arch/x86/boot components
when the bootloader does not setup/provide a stack for the early boot components
is not "enough".

The setup code executing as part of early kernel startup code, uses the stack
beyond 512 bytes and accidentally overwrites and corrupts part of the BSS
section. This is exposed mostly in the early video setup code, where
it was corrupting BSS variables like force_x, force_y, which in-turn affected
kernel parameters such as screen_info (screen_info.orig_video_cols) and
later caused an exception/panic in console_init().

Most recent boot loaders setup the stack for early boot components, so this
stack overwriting into BSS section issue has not been exposed.

Signed-off-by: Ashish Kalra &lt;ashish@bluestacks.com&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Brian Gerst &lt;brgerst@gmail.com&gt;
Cc: Denys Vlasenko &lt;dvlasenk@redhat.com&gt;
Cc: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: http://lkml.kernel.org/r/20170419152015.10011-1-ashishkalra@Ashishs-MacBook-Pro.local
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>x86/boot: Add CONFIG_PARAVIRT_SPINLOCKS quirk to arch/x86/boot/compressed/misc.h</title>
<updated>2017-02-08T08:43:05Z</updated>
<author>
<name>Ingo Molnar</name>
</author>
<published>2012-11-23T18:19:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5e471aea29514fac89871bc23eff49d62f0d8adc'/>
<id>urn:sha1:5e471aea29514fac89871bc23eff49d62f0d8adc</id>
<content type='text'>
commit 927392d73a97d8d235bb65400e2e3c7f0bec2b6f upstream.

Linus reported the following new warning on x86 allmodconfig with GCC 5.1:

  &gt; ./arch/x86/include/asm/spinlock.h: In function ‘arch_spin_lock’:
  &gt; ./arch/x86/include/asm/spinlock.h:119:3: warning: implicit declaration
  &gt; of function ‘__ticket_lock_spinning’ [-Wimplicit-function-declaration]
  &gt;    __ticket_lock_spinning(lock, inc.tail);
  &gt;    ^

This warning triggers because of these hacks in misc.h:

  /*
   * we have to be careful, because no indirections are allowed here, and
   * paravirt_ops is a kind of one. As it will only run in baremetal anyway,
   * we just keep it from happening
   */
  #undef CONFIG_PARAVIRT
  #undef CONFIG_KASAN

But these hacks were not updated when CONFIG_PARAVIRT_SPINLOCKS was added,
and eventually (with the introduction of queued paravirt spinlocks in
recent kernels) this created an invalid Kconfig combination and broke
the build.

So add a CONFIG_PARAVIRT_SPINLOCKS #undef line as well.

Also remove the _ASM_X86_DESC_H quirk: that undocumented quirk
was originally added ages ago, in:

  099e1377269a ("x86: use ELF format in compressed images.")

and I went back to that kernel (and fixed up the main Makefile
which didn't build anymore) and checked what failure it
avoided: it avoided an include file dependencies related
build failure related to our old x86-platforms code.

That old code is long gone, the header dependencies got cleaned
up, and the build does not fail anymore with the totality of
asm/desc.h included - so remove the quirk.

Reported-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>x86, build: copy ldlinux.c32 to image.iso</title>
<updated>2016-06-20T03:47:45Z</updated>
<author>
<name>H. Peter Anvin</name>
</author>
<published>2016-04-06T00:01:33Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2c34097fbfbcfdafca183139cc3524c4e29e27eb'/>
<id>urn:sha1:2c34097fbfbcfdafca183139cc3524c4e29e27eb</id>
<content type='text'>
[ Upstream commit 9c77679cadb118c0aa99e6f88533d91765a131ba ]

For newer versions of Syslinux, we need ldlinux.c32 in addition to
isolinux.bin to reside on the boot disk, so if the latter is found,
copy it, too, to the isoimage tree.

Signed-off-by: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: Linux Stable Tree &lt;stable@vger.kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>x86/efi: Use all 64 bit of efi_memmap in setup_e820()</title>
<updated>2015-08-27T17:25:49Z</updated>
<author>
<name>Dmitry Skorodumov</name>
</author>
<published>2015-07-28T14:38:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3c239f5a90855526c93c38687c1437a153d737eb'/>
<id>urn:sha1:3c239f5a90855526c93c38687c1437a153d737eb</id>
<content type='text'>
[ Upstream commit 7cc03e48965453b5df1cce5062c826189b04b960 ]

The efi_info structure stores low 32 bits of memory map
in efi_memmap and high 32 bits in efi_memmap_hi.

While constructing pointer in the setup_e820(), need
to take into account all 64 bit of the pointer.

It is because on 64bit machine the function
efi_get_memory_map() may return full 64bit pointer and before
the patch that pointer was truncated.

The issue is triggered on Parallles virtual machine and
fixed with this patch.

Signed-off-by: Dmitry Skorodumov &lt;sdmitry@parallels.com&gt;
Cc: Denis V. Lunev &lt;den@openvz.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>x86/efi: Store upper bits of command line buffer address in ext_cmd_line_ptr</title>
<updated>2015-06-28T17:39:26Z</updated>
<author>
<name>Roy Franz</name>
</author>
<published>2015-04-15T23:32:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c2c3964c8567d5d2b6bfa8534202850112de1d7d'/>
<id>urn:sha1:c2c3964c8567d5d2b6bfa8534202850112de1d7d</id>
<content type='text'>
[ Upstream commit 98b228f55014870092c15d7d168fecac69f2f12a ]

Until now, the EFI stub was only setting the 32 bit cmd_line_ptr in
the setup_header structure, so on 64 bit platforms this could be truncated.
This patch adds setting the upper bits of the buffer address in
ext_cmd_line_ptr.  This case was likely never hit, as the allocation
for this buffer is done at the lowest available address.  Only
x86_64 kernels have this problem, as the 1-1 mapping mandated
by EFI ensures that all memory is 32 bit addressable on 32 bit
platforms.  The EFI stub does not support mixed mode, so the
32 bit kernel on 64 bit firmware case does not need to be handled.

Signed-off-by: Roy Franz &lt;roy.franz@linaro.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
</feed>
