[gentoo-dev] TEXTRELs in assembly program

[gentoo-dev] TEXTRELs in assembly program

[Nekun]

Hi all,

Working on the fasm ebuild, have some questions:

1. fasm is written on itself and has two variants: self-contained binary 
for x86 and amd64 and linked with libc only for x86. Also, there are 
tools for working with the proprietary symbolic information format which 
is libc-linked and only x86. So, I provide two USEs, fail in pkg_setup 
if we on amd64 host and hasn't multilib profile if they are set and link 
it with default CC with -m32. Not sure it's a 'clean' way, would be 
happy to get some clarification about handling such cases.

2. When running my ebuild, got two warnings: one about text relocations, 
other about executable stack. Second problem seems trivial, just apply 
patches which adds corresponding ELF sections. But the first one is not 
clear: I found that TEXTRELs occurs due to default '--pie' option passed 
to ld by gcc and seems like it isn't possible to remove default ld 
options (only add to), so I can construct ld commandline for linking 
with libc manually and resolve a bunch of corner cases... But is 
avoiding TEXTRELs in assembly programs really necessary? Performance 
issues in case of assembly-written assembler seems negligible... What's 
best according to ::gentoo policies?

See ebuild draft in attachment.

Re: [gentoo-dev] TEXTRELs in assembly program

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 2495 bytes --]



> On 22 Apr 2021, at 22:07, Nekun <nekokun@firemail.cc> wrote:
> 
> Hi all,
> 

Hi!

> Working on the fasm ebuild, have some questions:
> 
> 1. fasm is written on itself and has two variants: self-contained binary for x86 and amd64 and linked with libc only for x86. Also, there are tools for working with the proprietary symbolic information format which is libc-linked and only x86. So, I provide two USEs, fail in pkg_setup if we on amd64 host and hasn't multilib profile if they are set and link it with default CC with -m32. Not sure it's a 'clean' way, would be happy to get some clarification about handling such cases.

Such pkg_setups are best avoided if possible because they can be confusing and we have other tools to handle it, so I’m glad you asked! I’d provide a USE flag for this tool and mask it on non-multilib amd64 profiles (or mask everywhere and unmask on the multilib amd64 profiles).

> 
> 2. When running my ebuild, got two warnings: one about text relocations, other about executable stack. Second problem seems trivial, just apply patches which adds corresponding ELF sections. But the first one is not clear: I found that TEXTRELs occurs due to default '--pie' option passed to ld by gcc and seems like it isn't possible to remove default ld options (only add to), so I can construct ld commandline for linking with libc manually and resolve a bunch of corner cases... But is avoiding TEXTRELs in assembly programs really necessary? Performance issues in case of assembly-written assembler seems negligible... What's best according to ::gentoo policies?
> 

Two points.

1) The TEXTREL QA warning primarily exists because of the security issues associated with them - they prevent PIC.

The following links may be useful:
- https://flameeyes.blog/2016/01/16/textrels-text-relocations-and-their-impact-on-hardening-techniques/
- https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide

However, I think it’s not really likely to be a real world issue if the program in question is an assembler. You’re just going to hit possible portability issues
but I’m not sure what the details are there.

2) Passing -fno-PIE and friends should work if you use append-* from flag-o-matic.eclass?

But yeah, we have a nice legacy there in terms of good defaults which made their way upstream. See the Gentoo Hardened project’s history for more information.


> See ebuild draft in attachment.

Can’t see it here.

Regards,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] TEXTRELs in assembly program

[Nekun]

Ah, looks like attachment isn't attached, post my ebuild in plain text.

EAPI=7

inherit multilib toolchain-funcs

DESCRIPTION="Open source assembly language compiler"
HOMEPAGE="https://flatassembler.net"
SRC_URI="https://flatassembler.net/${P}.tgz"

LICENSE="MIT"
SLOT="0"
KEYWORDS="amd64 x86"

IUSE="-tools -libc"

DEPEND=""
RDEPEND=""

S="${WORKDIR}/${PN}"
PATCHES=( "${FILESDIR}/1-fix-gnu-stack.patch" )

TOOLS=(listing prepsrc symbols)

pkg_setup() {
	if use tools || use libc; then
		if [[ ${ARCH} = "amd64" && ! $(get_all_abis) =~ "x86" ]]; then
			die "Multilib profile must be selected to build 32-bit tools or 
libc-linked FASM for amd64 target"
		fi
	fi
	CC=$(tc-getCC)
}

src_compile() {
	# fasm is written on itself; so, if fasm already installed,
	# assemble it with system fasm, otherwise assemble it
	# with binary provided in tarball
	if has_version -b "${CATEGORY}/${PN}"; then
		FASM="${PN}"
		is_bootstrap=1
	elif [[ ${ARCH} = "x86" ]]; then
		einfo "Bootstrapping fasm from binary"
		FASM="./${PN}"
	else # amd64
		einfo "Bootstrapping fasm from binary"
		FASM="./${PN}.x64"
	fi

	if ! use libc; then
		if [[ ${ARCH} = "x86" ]]; then
			${FASM} "source/Linux/${PN}.asm" "${T}/${PN}" || die
		else # amd64
			${FASM} "source/Linux/x64/${PN}.asm" "${T}/${PN}" || die
		fi
	else
		${FASM} "source/libc/fasm.asm" || die
		${CC} -m32 ${LDFLAGS} -o "${T}/${PN}" "source/libc/fasm.o" || die
	fi

	if use tools; then
		# bootstrapping is done at this point, we can use
		# our homebrewed binary for building tools
		[[ -v is_bootstrap ]] && FASM="${T}/${PN}"

		for tool in "${TOOLS[@]}"; do
			${FASM} "tools/libc/${tool}.asm" || die
			${CC} -m32 ${LDFLAGS} -o "${T}/${tool}" "tools/libc/${tool}.o" || die
		done
	fi
}

src_install() {
	exeinto /usr/bin
	doexe "${T}/${PN}"
	dodoc "${PN}.txt"
	if use tools; then
		for tool in "${TOOLS[@]}"; do
			doexe "${T}/${tool}"
		done
		dodoc "tools/fas.txt"
	fi
}

Re: [gentoo-dev] TEXTRELs in assembly program

[Nekun]

On 2021-04-22 21:23, Sam James wrote:
> Such pkg_setups are best avoided if possible because they can be
> confusing and we have other tools to handle it, so I’m glad you asked!
> I’d provide a USE flag for this tool and mask it on non-multilib amd64
> profiles (or mask everywhere and unmask on the multilib amd64
> profiles).
Fasm itself can be built and run in pure amd64 environment, so we need 
to mask only USEs for building additional tools and building fasm itself 
against libc in non-multilib amd64 (native x86 is correct platform too) 
it this approach.

> 1) The TEXTREL QA warning primarily exists because of the security
> issues associated with them - they prevent PIC.
> 
> The following links may be useful:
> -
> https://flameeyes.blog/2016/01/16/textrels-text-relocations-and-their-impact-on-hardening-techniques/
> - https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide
> 
> However, I think it’s not really likely to be a real world issue if
> the program in question is an assembler. You’re just going to hit
> possible portability issues
> but I’m not sure what the details are there.
Seems like gcc when used as linker frontend expects PIE-aware code in 
object file and pass '-pie' to linker, but fasm doesn't know anything 
about PIE, so ld fallbacks to TEXTRELs, AFAIK. Suggest two approaches: 
disable passing PIE in gcc in some way or ignore textrel issues. Manual 
linking seems to be error-prone in any non-standard configuration, such 
as ${ROOT}/${SYSROOT} cross-environments, binary hosts, etc... maybe I 
too scared because not so familiar with linking, however.

> 2) Passing -fno-PIE and friends should work if you use append-* from
> flag-o-matic.eclass?
Passing -fno-pie to gcc has no effect, `strace --string-limit -vfe 
execve` shows that '--pie' is passed to ld anyway.

> Can’t see it here.
Looks like it accidentaly not posted by my stupid webmail client, posted 
in plaintext in reply to original post.