Livepatch consistency model, objtool, and s390x arch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi folks,

With Josh's input, I've been looking at the s390x architecture with
respect to the livepatch consistency model and whether we will need to
port objtool to ensure stack frame correctness.

Background on livepatch's consistency model can be found in
Documentation/livepatch/livepatch.txt and objtool's compile-time stack
metadata validation in tools/objtool/Documentation/stack-validation.txt

Using the following s390x references:

  zSeries ELF Application Binary Interface Supplement
  http://refspecs.linuxfoundation.org/ELF/zSeries/lzsabi0_zSeries.pdf

  Enterprise Systems Architecture/390: Principles of Operation
  http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/download/DZ9AR008.pdf

I wrote a tool using objdump and awk [1] that matches various s390x
stack usage patterns across an entire v4.16 'allyesconfig' and
CONFIG_COMPILE_TEST kernel build.  The tool runs a simple heuristic
that reports functions that branch without having allocating stack or
copy/pushed a backchain pointer beforehand.

After scanning ~250000 functions, the objdump+awk tool reported only 23
"interesting" functions (see the 'report' file in the github[1] page).
I've attempted to filter out as many irrelevant functions/object files
as possible (see the 'loop' script), but I suspect that the remaining
23 functions may be false-positives.  Pattern matching improvements or
assembly explanations welcome :)

While the zSeries ELF Application Binary Interface Supplement talks
about setting up stack frames:

  The stack frame

  A function will be passed a frame on the runtime stack by the
  function which called it, and may allocate a new stack frame. A new
  stack frame is required if the called function will in turn call
  further functions (which must be passed the address of the new frame).

I didn't see anything inherent to the architecture that enforces this
convention.  In other words, unlike say x86, I don't think s390x's
calling/return instructions imply anything about the stack. That would
mean it should be possible to craft strange s390x assembly code that
brasl's its way functions deep without setting a backpointer (perhaps
using registers to remember the call chain).

That said, according to the objdump+awk report, it doesn't look like
there is much non-standard s390 stack usage present in the kernel tree,
even in the hand-coded assembly files.

My take is that existing code is generally compliant in setting up
stack frames, but one /could/ bend over backwards to avoid them.
However, I'm not an s390x expert, so I figured I would share these
thoughts and the objdump+awk tool results with those far more
knowledgeable about the architecture and problem space.

[1] https://github.com/joe-lawrence/s390x-objtool

-- Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-s390" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux