linux-kernel - Re: [RFC PATCH 00/11] an introduction of library operating system for Linux (LibOS)

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: <5518F030.4040003@nod.at>
Date:	Mon, 30 Mar 2015 08:41:52 +0200
From:	Richard Weinberger <richard@....at>
To:	Hajime Tazaki <tazaki@....wide.ad.jp>
CC:	linux-arch@...r.kernel.org, arnd@...db.de, corbet@....net,
	cl@...ux.com, penberg@...nel.org, rientjes@...gle.com,
	iamjoonsoo.kim@....com, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	netdev@...r.kernel.org, linux-mm@...ck.org, jdike@...toit.com,
	rusty@...tcorp.com.au, mathieu.lacage@...il.com
Subject: Re: [RFC PATCH 00/11] an introduction of library operating system
 for Linux (LibOS)

Am 29.03.2015 um 17:06 schrieb Hajime Tazaki:
>> What about putting libos into tools/testing/ and make it much more generic and framework alike.
> 
> it's trivial though, libos is not only for the testing (i.e., NUSE).
> # of course tools/libos or something can be the place.

Yep, tool/libos is also perfectly fine.

>> With more generic I mean that libos could be a stubbing framework for the kernel.
>> i.e. you specify the subsystem you want to test/stub and the framework helps you doing so.
>> A lot of the stubs you're placing in arch/lib could be auto-generated as the
>> vast majority of all kernel methods you stub are no-ops which call only lib_assert(false).
> 
> the issue here is the decision between 'no-ops' and
> 'assert(false)' depends on the context. an auto-generated
> mechanism needs some hand-written parameters I think.

The questions is, why do you need stubs which are a no-op but not a
lib_assert(false).
Sounds more like these dependencies shouldn't be linked at all.
Same applies to lib_assert(false) stubs. If they must not get
called from libos better try hard to avoid these dependencies at all.

> one more concern on the out-of-arch-tree design is that how
> to handle our asm-generic-based header files
> (arch/lib/include/asm). we have been heavily used
> 'generic-y' in the Kbuild file to reuse header files.

As noted before, libos is something in between. Maybe the asm-generic
stuff needs some modifications to make it work for libos.

> OTOH, I agree with you on the point of auto-generated glues
> (stubs), or trying to avoid glues (reuse the originals as
> much as possible) as Antti mentioned. that will definitely
> be reduce the amount of maintenance effort.

BTW: There is something really fishy wrt to your build process.
I did a ARCH=i386 build due to my regular kernel work and later a ARCH=lib build.
It seems to pickup old/unrelated object files.
After a make clean ARCH=i386 it build fine.

---cut---
  LIB           liblinux-4.0.0-rc5.so
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: Warning: size of symbol `skb_copy_bits' changed from 10 in ./kernel/bpf/core.o to 441 in ./net/core/skbuff.o
./net/ipv6/fib6_rules.o: In function `fib6_rule_lookup':
/home/rw/linux/net/ipv6/fib6_rules.c:34: multiple definition of `fib6_rule_lookup'
./net/ipv6/ip6_fib.o:ip6_fib.c:(.text+0xd50): first defined here
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `./kernel/sysctl.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `./kernel/params.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `./kernel/notifier.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `./kernel/time/time.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `./kernel/rcu/update.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `./kernel/locking/mutex.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `./kernel/locking/semaphore.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `./kernel/locking/rwsem.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `./kernel/bpf/core.o' is incompatible with i386:x86-64 output
[...]
./kernel/rcu/update.o:(.ref.data+0x20): undefined reference to `trace_event_raw_init'
collect2: error: ld returned 1 exit status
arch/lib/Makefile:223: recipe for target 'liblinux-4.0.0-rc5.so' failed
make: *** [liblinux-4.0.0-rc5.so] Error 1
---cut---

While we're talking about the build process, how can I cross build libos?
Say a i386 libos on x86_64. For UML we have use SUBARCH.
i.e. make linux ARCH=um SUBARCH=i386

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/