lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <33953236-138f-4141-a5af-9ea60d148ed3@samsung.com>
Date: Tue, 24 Sep 2024 10:51:43 +0200
From: Daniel Gomez <da.gomez@...sung.com>
To: Marc Zyngier <maz@...nel.org>
CC: Masahiro Yamada <masahiroy@...nel.org>, Nathan Chancellor
	<nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>, Lucas De Marchi
	<lucas.demarchi@...el.com>, Thomas Hellström
	<thomas.hellstrom@...ux.intel.com>, Rodrigo Vivi <rodrigo.vivi@...el.com>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard
	<mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, David Airlie
	<airlied@...il.com>, William Hubbs <w.d.hubbs@...il.com>, Chris Brannon
	<chris@...-brannons.com>, Kirk Reiser <kirk@...sers.ca>, Samuel Thibault
	<samuel.thibault@...-lyon.org>, Paul Moore <paul@...l-moore.com>, "Stephen
 Smalley" <stephen.smalley.work@...il.com>, Ondrej Mosnacek
	<omosnace@...hat.com>, Catalin Marinas <catalin.marinas@....com>, Will
	Deacon <will@...nel.org>, Oliver Upton <oliver.upton@...ux.dev>, James Morse
	<james.morse@....com>, Suzuki K Poulose <suzuki.poulose@....com>, Zenghui Yu
	<yuzenghui@...wei.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Jiri Slaby" <jirislaby@...nel.org>, Nick Desaulniers
	<ndesaulniers@...gle.com>, Bill Wendling <morbo@...gle.com>, Justin Stitt
	<justinstitt@...gle.com>, Simona Vetter <simona.vetter@...ll.ch>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org>,
	"intel-xe@...ts.freedesktop.org" <intel-xe@...ts.freedesktop.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"speakup@...ux-speakup.org" <speakup@...ux-speakup.org>,
	"selinux@...r.kernel.org" <selinux@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "kvmarm@...ts.linux.dev"
	<kvmarm@...ts.linux.dev>, "linux-serial@...r.kernel.org"
	<linux-serial@...r.kernel.org>, "llvm@...ts.linux.dev"
	<llvm@...ts.linux.dev>, Finn Behrens <me@...enk.dev>, "gost.dev@...sung.com"
	<gost.dev@...sung.com>, "Daniel Gomez (Samsung)" <d+samsung@...ces.com>
Subject: Re: [PATCH v2 8/8] Documentation: add howto build in macos

On 9/8/2024 11:03 AM, Marc Zyngier wrote:
> On Sat, 07 Sep 2024 10:32:20 +0100,
> "Daniel Gomez (Samsung)" <d+samsung@...ces.com> wrote:
>>
>> On Sat, Sep 7, 2024 at 10:33 AM Masahiro Yamada <masahiroy@...nel.org> wrote:
>>>
>>> On Fri, Sep 6, 2024 at 8:01 PM Daniel Gomez via B4 Relay
>>> <devnull+da.gomez.samsung.com@...nel.org> wrote:
>>>>
>>>> From: Daniel Gomez <da.gomez@...sung.com>
>>>>
>>>> Add documentation under kbuild/llvm to inform about the experimental
>>>> support for building the Linux kernel in macOS hosts environments.
>>>>
>>>> Signed-off-by: Daniel Gomez <da.gomez@...sung.com>
>>>
>>>
>>> Instead, you can add this instruction to:
>>>
>>> https://protect2.fireeye.com/v1/url?k=f33af8a2-92b1ed94-f33b73ed-74fe485cbff1-7d382b34bfd617fc&q=1&e=c7a3e869-d48e-4168-88a9-03cd717797f0&u=https%3A%2F%2Fgithub.com%2Fbee-headers%2Fhomebrew-bee-headers%2Fblob%2Fmain%2FREADME.md
>>
>> Sure, that can be done as well. But the effort here is to have this
>> integrated. So, I think documentation should be in-tree.
> 
> I think this ship sailed the moment you ended-up with an external
> dependency.

The external dependency is not different in Linux hosts. We depend on 
byteswap.h, elf.h and endian.h headers. However, these are provided by 
glibc and musl, and macOS (at least in arm64/Homebrew) does not provide 
any of these.

To fix the dependency with these missing headers, it was suggested in v1 
[1][2] to create a "development kit" for this hosts. And that is what 
Bee Headers [3][4] aims to provide.

[1]https://lore.kernel.org/all/20240807-mottled-stoic-degu-d1e4cb@lindesnes/
[2]https://lore.kernel.org/all/ZrSoOM9z4VnqhOf2@fjasle.eu/

[3] https://github.com/bee-headers/headers
[4] https://github.com/bee-headers/homebrew-bee-headers

I don't see any other alternative to provide the missing headers other 
than the suggested. Please let me know if you think other paths can be 
explored and tested.

> 
> Having looked at this series (and in particular patch #4 which falls
> under my remit), I can't help but think that the whole thing should
> simply live as a wrapper around the pristine build system instead of
> hacking things inside of it. You already pull external dependencies
> (the include files). Just add a script that sets things up
> (environment variables that already exist) and calls 'make' in the
> kernel tree.

Agree. This aligns very well with other feedback.

I've added a script to the Bee Headers [5] to help users init their 
shell/Makefile environment.

[5] 
https://github.com/bee-headers/homebrew-bee-headers/blob/main/bee-headers.rb#L28

> 
> I also dislike that this is forcing "native" developers to cater for
> an operating system they are unlikely to have access to. If I break
> this hack tomorrow by adding a new dependency that MacOS doesn't
> provide, how do I fix it? Should I drop my changes on the floor?
> 
> As an alternative, and since you already have to create a special
> file-system to contain your kernel tree, you may as well run Linux in
> a VM, which I am told works pretty well (QEMU supports HVF, and there
> are plenty of corporate-friendly alternatives). This would solve your
> problem once and for all.

This is a use case I'm trying to avoid with this series. QEMU HVF works 
very well indeed but extracting the built objects/vmlinux/*.ko etc is 
tedious and slow. Building natively allows users to boot a VM with QEMU 
and -kernel argument directly. This is way faster than the suggested 
alternative. In addition, lldb can be used to debug the kernel from the 
host.

> 
> Please don't take the above the wrong way. I'm sympathetic to what you
> are trying to do. But this is IMO going in the wrong direction.

First patch has been merged already and after some fixes in the build 
system from Masahiro, this series only requires a small change in 
xe_gen_wa_oob to make this work if users of this provide the missing 
headers and set up the build environment properly.

I will send a v3 later today with the remaining patch.

Thanks Marc for sharing your views!

> 
> Thanks,
> 
> 	M.
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ