qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
kevinrowland has quit [Quit: Client closed]
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
emdevt has joined #yocto
prabhakarlad has quit [Quit: Client closed]
zhmylove has quit [Quit: Leaving]
shakta has quit [Quit: Client closed]
sakman has quit [Quit: Leaving]
emdevt__ has joined #yocto
emdevt has quit [Ping timeout: 245 seconds]
paulg has quit [Ping timeout: 258 seconds]
paulg has joined #yocto
ablu has quit [Ping timeout: 248 seconds]
ablu has joined #yocto
zelgomer has quit [Remote host closed the connection]
zelgomer has joined #yocto
shakta has joined #yocto
<shakta>
Why does kernel image w/ bundled initramfs image not get deployed to rootfs automatically?
<shakta>
The initramfs bundling task in poky is added after install before deploy. It does not get included in the *package* build directories but the kernel with out the bundled initramfs does.
jclsn has quit [Ping timeout: 255 seconds]
emdevt__ has quit [Remote host closed the connection]
jclsn has joined #yocto
jclsn has quit [Ping timeout: 252 seconds]
jclsn has joined #yocto
shakta has quit [Quit: Client closed]
amitk has joined #yocto
Minvera has quit [Ping timeout: 260 seconds]
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
Chaser has joined #yocto
davidinux has quit [Ping timeout: 255 seconds]
rob_w has joined #yocto
davidinux has joined #yocto
alessioigor has joined #yocto
ablu has quit [Remote host closed the connection]
ablu has joined #yocto
sakman has joined #yocto
jmiehe has joined #yocto
olani has quit [Ping timeout: 255 seconds]
xmn has quit [Ping timeout: 245 seconds]
amitk_ has joined #yocto
Saur has quit [Ping timeout: 240 seconds]
amitk has quit [Ping timeout: 255 seconds]
linfax_ has joined #yocto
linfax_ has quit [Quit: Leaving]
Max1980 has joined #yocto
linfax has joined #yocto
<Max1980>
goodmorning all! sorry for bothering....is there any guide on how enable encryption on filesystem during yocto building ?
mvlad has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
* RP
doesn't know whether to put rc1 of 4.3 through QA or to try again with different kernel fixes
tnovotny has quit [Quit: Leaving]
<ablu>
Max1980: There are a lot of options here... Do you want a per-device key? Same key across all devices? Do you have a TPM?
<mcfrisk>
RP: at least I have not seen the tty bug on real HW, or even on qemu with our setup
leon-anavi has joined #yocto
<ablu>
Max1980: For TRS (Trusted Reference Stack) we do it from initramfs with a per-device key derived from the TPM.
jmiehe has quit [Quit: jmiehe]
pabigot has quit [Ping timeout: 260 seconds]
rfuentess has joined #yocto
grma has joined #yocto
frieder has joined #yocto
<RP>
mcfrisk: it seems to be more infrequent after some of the changes
pabigot has joined #yocto
zpfvo has joined #yocto
Daanct12 has joined #yocto
zpfvo has quit [Ping timeout: 255 seconds]
<mcfrisk>
RP: yep. it is sad that only yocto qemu test env triggers these. in previous projects we had dedicated machines for virtual tests, and kept a close eye on the load there. the autobuilders are really tough on qemu and SW stack
rfuentess has quit [Read error: Connection reset by peer]
rfuentess has joined #yocto
mckoan|away is now known as mckoan
goliath has joined #yocto
<mcfrisk>
if kernel tty layer has regressions, that should be a problem for all BSP vendors, not just yocto upstream maintainers. if you could afford it, I'd try to shield the qemu test jobs from each other and give them more CPU, memory etc resources. This would cost either time or more resources/machines though, but that's better than burning maintainers out with all the races and odd errors..
<LetoThe2nd>
yo dudX
<mckoan>
LetoThe2nd: hey!
<Max1980>
@ablu: sorry for late response. I've a custom rpi3 image conf for a custom board with a CM3 module onboard. The eMMC contains 4 partitions ( boot, 2 rootfs, opt ). i need to encrypt all 4 partitions
<Max1980>
@ablu: to answer your question: no TPM
zpfvo has joined #yocto
Kubu_work has joined #yocto
alessioigor has quit [Quit: alessioigor]
<mcfrisk>
Max1980: encryption just moves the problem elsewhere. Where is the key and how secure is that, e.g. secure boot...? meta-security and meta-secure-core have several building blocks but maybe not full solutions because those may depend on SoC specific secure boot magic.
alessioigor has joined #yocto
<ablu>
Max1980: For unattended boot, you probably want a TPM. Either from hardware or from software (via TrustZone). That said, RPI does not provide the necessary memory isolation for TrustZone.
<ablu>
The Yocto integrations that I am aware of mostly depend on TPM.
<ablu>
Of course nothing stops you from just generating a partition guarded by a compile-time key. You just need someone at the machine to enter it at boot.
<mckoan>
Max1980: you can't do that in a completely trusted way with a RPI (Broadcom)
pretec has joined #yocto
<LetoThe2nd>
Max1980: plus, encryption at scale requires some form of PKI plus key management, a manufacturing/provisioning process thats fit for it, and so on, and so on. It can be done, but as mckoan already pointed out - without any secure HW anchor of trust, it is relatively m00t.
<Max1980>
let's say that: ok it's not perfectly secure...but the cybs teams says that "it's ok" xD
florian_kc is now known as florian
<Max1980>
i've read about doing secure boot ..c.reating a fitImage...but actually there's not so much documentations
<Max1980>
or maybe i haven't found
<LetoThe2nd>
Max1980: if your cyb team is happy with the form of security that can be broken by just attaching a serial cable and accessing the u-boot terminal (because thats effectively what you're saying), then you should severely question their competence, at least for embedded devices.
<LetoThe2nd>
Max1980: same story for secure boot, how do you verify the first loader?
<LetoThe2nd>
Max1980: and even legally speaking, if you're shipping anything GPLv3 then you are legally required to give your customers a documented way of changing the software on the device.
<LetoThe2nd>
upon request, that is.
<Max1980>
so the only way to do it in a "secure way" is using TPM. just for tryin without...how can i modify my local.conf to test it ?
<mckoan>
Max1980: it's a sensitive subject we can't discuss details publicly
<Max1980>
okkey ...tnx anyway for your answers!
<ablu>
Max1980: If you do not know where to start, maybe look into systemd-cryptenroll and friends. Support in Yocto is a bit rocky, but it also has supports non-TPM backed keys.
<ablu>
100% ACK to that doing this in production is a bad idea of course.
bhstalel has joined #yocto
olani has joined #yocto
frieder has quit [Ping timeout: 255 seconds]
<mckoan>
Max1980: however the most secure solution you have with a RPI is an HW module: https://www.zymbit.com/
varjag has joined #yocto
<dvergatal>
Max1980: if your using arm platform u can always use arm trust zone
<dvergatal>
instead of tpm
<Max1980>
ablu: ok i'll try to read somthing
<dvergatal>
but on RPI trust zone is not secure at all
<Max1980>
mckoan: yep i know...but as i said, it's only for testing
<Max1980>
dvergatal: ok ..there's something on that topic on the yocto docs ?
<dvergatal>
generally this mbed tls tee blob is already being build within op-tee source code
frieder has joined #yocto
prabhakarlad has joined #yocto
OnkelUlla has quit [Read error: Connection reset by peer]
jmiehe has quit [Quit: jmiehe]
<Max1980>
thank you all guys :*
OnkelUlla has joined #yocto
<LetoThe2nd>
Max1980: and as you mentioned 2x rootfs, I guess you are using a form of A/B update. Next step, think about which things are encrypted where, by which key, how they are transported, how to deal with per-device keys, rotation, etc. pp.
OnkelUlla has quit [Remote host closed the connection]
<LetoThe2nd>
working for an OTA provider, my experience is "encrypting the rootfs" is usually a checkbox requirement for some department, but they hardly are aware of it being about 5% of the whole story. possibly even less.
ptsneves has joined #yocto
OnkelUlla has joined #yocto
<neverpanic>
My guess is that a signature over the rootfs (e.g. using dm-verity) would in most cases be better than actually encrypting it.
Saur has joined #yocto
<neverpanic>
Encryption isn't tamper-protection, but many people assume that it is. If you use AES-XTS, attackers can still flip bits in your rootfs.
<neverpanic>
They can't if you use signatures.
florian_kc has joined #yocto
Danct12 has quit [Ping timeout: 258 seconds]
<LetoThe2nd>
neverpanic: but..but...BUT...IT WILL HIDE MY SECRETS! NOBODY CAN SEE MY GLIBC!
<LetoThe2nd>
(if you spotted hints of irony in the above post, rest assured, it is completely unintentional ;-) )
Rich_1234 has quit [Quit: Connection closed]
prabhakarlad has quit [Quit: Client closed]
<LetoThe2nd>
for those who wonder: my take on things is to not just use encryption blindly "because it is secure", but to understand the requirements and processes first, build a threat model, and then choose mitigations accordingly. this *can* mean rootfs encryption, but in most cases it actually does *not* in my experience.
<qschulz>
encryption is IP protection when the device is powered off basically, not much more than this
bhstalel has quit [Ping timeout: 245 seconds]
<Max1980>
neverpanic: signing with dm-verity it means that everything is "readable" but you can't use any file that isn't signed?
<neverpanic>
Well, with dm-verity you have a choice, either attempting to read files that have been tampered will fail with an error, or the system will reset.
<neverpanic>
Depending on how you set it up
<Max1980>
uhm..not applicable to my case
<LetoThe2nd>
qschulz: well there are definitely some more advanced techniques available, but yeah - rootfs encryption is mostly that.
<Max1980>
i have to try with encryption...
<neverpanic>
Also what qschulz is saying. If you don't have a strategy to quickly address CVEs to prevent attackers from gaining code execution on your device, don't bother with rootfs encryption, because whatever you *think* you are protecting on there, you're probably failing at it.
<neverpanic>
All that encryption doesn't stop somebody who already has code execution on the running device.
<Max1980>
the time "that guy" has this device in his hand....it's over :)
<neverpanic>
So you're really just trying to protect your images while they are being transferred to the device?
<qschulz>
I mean, there's nothing 100% secure so.. in a way, yes.
<qschulz>
threat model and everything, but that LetoThe2nd has already said a few words about
mihai has quit [Quit: Leaving]
Vonter has quit [Ping timeout: 258 seconds]
Vonter has joined #yocto
Rich_1234 has joined #yocto
<landgraf>
is there documented (and ideally easy) way to run tests in autobuilder-like environment? My patchset causes test failures in autobuilder but same test is passed locally and I'd like to debug this.
pabigot has quit [Ping timeout: 246 seconds]
<LetoThe2nd>
landgraf: asking halstead for a shopping list and rebuilding the autobuilder locally is probably the most documented and easiest way :-)
<landgraf>
LetoThe2nd: s/easy/cheap/ then :D
<LetoThe2nd>
landgraf: how böring.
<landgraf>
LetoThe2nd: I can't afford second expensive hobby :-)
<bhstalel>
How do I distinguish between patches for oe-core and poky ? I sometimes send patches to poky and it should be sent to oe-core, I thought every change in poky project is related to poky mailing list
<qschulz>
bhstalel: look into openembedded-core git repo, if what you change is in there, send it to OE-Core
<qschulz>
bhstalel: could you also please use -v X when using git format-patch or git send-email so we know which version of the patch you sent is the latest (it's not that uncommon to have people answer to older versions of the patchsets)
<ablu>
bhstalel: poky's README.md also has a breakdown of which changes to send where.
mckoan is now known as mckoan|away
<bhstalel>
qschulz Now I see, I get confused because oe-core source is already in poky project, I will keep "-v X" in mind, I did not know about this, I am new to contributions :))
<bhstalel>
LetoThe2nd Any updates about the Summit ?
<qschulz>
bhstalel: poky is a special case yes
mbulut has joined #yocto
<LetoThe2nd>
bhstalel: we will hopefully finish speaker notifications by the end of this week
<bhstalel>
LetoThe2nd Thanks.
mbulut has quit [Client Quit]
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
Chaser has quit [Remote host closed the connection]
Chaser has joined #yocto
prabhakarlad has joined #yocto
<rburton>
bhstalel: just remember you never actually send a patch for *poky*. that's a generated repository by glueing together oe-core + bitbake + yocto-docs + meta-yocto
<rburton>
it's absolutely common to grab bitbake + oe-core + BSP layers + your own distro layer and not use poky at all
<bhstalel>
rburton Thanks for the clarification. This helps a lot
Max1980 has quit [Remote host closed the connection]
paulg has quit [Ping timeout: 255 seconds]
paulg has joined #yocto
hcg has joined #yocto
frieder has quit [Quit: Leaving]
<hcg>
Hi, I wonder if someone could explain what the task do_ar_original does and if it is possible to bypass it under certain circumstances? I am currently doing development in the kernel rebuilding kernel code on a regular basis and the do_ar_original step takes >12 minutes on my build machine, wheeras the actual kernel and modules build takes ~5
<hcg>
minutes
<rburton>
hcg: don't enable the source archive and it won't run at all
<rburton>
you've INHERIT += "archiver" somewhere
<rburton>
(if you're doing development enabling the archiver is a massive waste of time)
<hcg>
I see someone had enabled it in one of our configuration files - yes, it is a huge waste of time, thank you very much for the quick response
<rburton>
absolutely use it for GPL compliance in a release build, but not on every build :)
Chaser has quit [Remote host closed the connection]
zpfvo has quit [Ping timeout: 252 seconds]
Chaser has joined #yocto
zpfvo has joined #yocto
Rich_1234 has joined #yocto
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
tnovotny has quit [Read error: Connection reset by peer]
tnovotny has joined #yocto
<LetoThe2nd>
rburton: wat, you don't release every build? ;-)
Daanct12 has quit [Quit: WeeChat 4.0.5]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
bhstalel has quit [Ping timeout: 245 seconds]
rob_w has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
hcg has quit [Quit: Client closed]
hcg has joined #yocto
Minvera has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
bhstalel has joined #yocto
Danct12 has joined #yocto
xmn has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<hcg>
Recently, in my build environment, I have noticed errors like:
<hcg>
Setup complete, sending SIGUSR1 to pid 2990189.
<hcg>
I am using a newer release of meta-ti, but I am not sure if that is the cause of the issue
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
<hcg>
The only way I can then build my image is to completely delete my build directory, but as I have an external download cache and sstate-cache, this is not an expensive operation
<denix>
hcg: that looks like a pseudo abort issue. doesn't seem to be meta-ti related. there have been some fixes for that in master - are you using master or a stable release?
<hcg>
I am using kirkstone 4.0.8 currently
<denix>
yeah, we are also seeing a lot of those in kirkstone... I was wondering if we can backport those fixes from master, but they are not trivial and invasive
bhstalel has quit [Quit: Client closed]
<denix>
hcg: btw, are you getting this on consecutive do_rootfs calls? if so, you can try to clean up it in-between. e.g. bitbake your-image -c clean
<denix>
your-image = core-image-minimal
<hcg>
It always happens when I am building the rootfs, thanks for the tip, I will try this next time it happens
prabhakarlad has quit [Quit: Client closed]
wooosaiiii has quit [Ping timeout: 252 seconds]
Xagen has joined #yocto
bhstalel has joined #yocto
hcg has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
bhstalel has quit [Quit: Ping timeout (120 seconds)]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
hcg has joined #yocto
vladest has quit [Quit: vladest]
linfax has quit [Ping timeout: 240 seconds]
vladest has joined #yocto
brrm has quit [Ping timeout: 245 seconds]
zelgomer has quit [Remote host closed the connection]
zelgomer has joined #yocto
brrm has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
hcg has quit [Quit: Client closed]
sakman has quit [Quit: Leaving]
leon-anavi has quit [Remote host closed the connection]
kscherer has joined #yocto
Chaser has quit [Quit: Chaser]
ptsneves has quit [Ping timeout: 240 seconds]
florian has quit [Quit: Ex-Chat]
Kubu_work has quit [Quit: Leaving.]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
RobertBerger has joined #yocto
rber__ has quit [Read error: Connection reset by peer]
florian_kc has quit [Ping timeout: 255 seconds]
zpfvo has quit [Remote host closed the connection]
frieder has joined #yocto
rfuentess has quit [Remote host closed the connection]
zenstoic has joined #yocto
jmd has joined #yocto
tnovotny has quit [Quit: Leaving]
florian_kc has joined #yocto
silbe has quit [Ping timeout: 264 seconds]
jmd has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 240 seconds]
Chaser has joined #yocto
frieder has quit [Ping timeout: 245 seconds]
silbe has joined #yocto
frieder has joined #yocto
pretec has quit [Read error: Connection reset by peer]
Guest67 has joined #yocto
<Guest67>
hi all, I think yocto is fetching tar source files via wget. Is it possible to ask it to use something else like curl instead?
Chaser has quit [Remote host closed the connection]
Chaser has joined #yocto
<mischief>
Guest67: what for?
Chaser has quit [Remote host closed the connection]
Chaser has joined #yocto
zelgomer has quit [*.net *.split]
GNUmoon has quit [*.net *.split]
Guest67 has quit [*.net *.split]
goliath has joined #yocto
florian_kc has joined #yocto
frieder has quit [Remote host closed the connection]
Chaser has quit [Quit: Chaser]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
bhstalel has joined #yocto
<bhstalel>
I am always wondering if all Yocto developers, architects and stuff are working on other companies or some of them are working in The linux foundation it self ?
hcg has joined #yocto
tlwoerner has quit [Remote host closed the connection]
tlwoerner_ has joined #yocto
prabhakarlad has joined #yocto
zelgomer has joined #yocto
hcg has quit [Quit: Client closed]
hcg has joined #yocto
<hcg>
denix: I mentioned earlier that I am using a newer release of meta-ti. I am busy working on updating our am625-based product from a release of meta-ti which was from mid November 2022. We also have an am335x product based on the same release and we never ever see this pseudo abort issue, and these builds are done frequently by over 30 developers,
<hcg>
as well as 6 or 7 products doing nightly CI builds. I am currently updating to basically the HEAD of meta-ti and it is only since I started this work that I see these errors. I am still using kirkstone-4.0.8, which is the same as we have for out stable releases of both out am62x and am335x products. I am not sure if it is a co-incidence, but that
<hcg>
is why I mentioned the newer meta-ti.
<hcg>
denix: and I see these errors on probably every 2nd or 3rd build I do
alessioigor has quit [Quit: alessioigor]
zenstoic has quit [Quit: Connection closed for inactivity]
bhstalel has quit [Quit: Client closed]
Guest67 has joined #yocto
<JaMa>
anyone with opinion about pseudo and io_uring? nodejs >= 20.3.0 now in meta-oe started to use it and pseudo doesn't intercept it correctly
<RP>
JaMa: 3) is obviously the ideal long term approach. I have no idea how complicated io_uring is
<RP>
JaMa: hmm, do we have to intercept liburing?
<JaMa>
libuv doesn't seem to use liburing
* JaMa
knows close to nothing about io_uring and libuv, just bisected to this change few hours ago
<mischief>
that sounds like a lovely world of pain :-)
Guest67 has quit [Quit: Client closed]
speeder has joined #yocto
drkhsh has quit [Quit: WeeChat 3.8]
prabhakarlad has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]
drkhsh has joined #yocto
behanw has joined #yocto
<RP>
JaMa: if it is using the syscalls directly we might not be able to intercept
olani- has joined #yocto
<moto-timo>
networkmanager seems unbuildable on kirkstone and the recipe looks no better in master for this specific issue. The 'vapi' PACKAGECONFIG also requires -Dintrospection=true, but then I think it DEPENDS on glib-2.0 for Gio-2.0 but then Gio-2.0.gir is not found.
<JaMa>
before 1.45.0 version it was using syscall() only for __NR_copy_file_range, __NR_statx, __NR_getrandom,
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hcg has quit [Quit: Client closed]
<JaMa>
we can also call "chown root:root ${D}" in do_install after calling webpack (that's what I've used now as work around for this)
<JaMa>
with -R
<RP>
JaMa: I can't remember if syscall() is inlined or a glibc function?
<RP>
if it is a glibc function we can intercept and it just going to be painful to intercept and decode the syscall info. If it is inlined, we can't intercept
<RP>
JaMa: one way to do it is make the syscall return ENOSYS and force the code to use a fallback
<JaMa>
RP: thanks for pointers, will check pseudo code again after some sleep (in hope that someone else will beat me to it) and after finishing some other nasty bug we have in internal build which is blocking current release :(
<moto-timo>
but later commits wiped out that comment and merges happen
<JaMa>
nodejs LTS should move from 18 to 20 in 5 days according to https://github.com/nodejs/release#release-schedule so it's probably good it was merged in nanbield (even with the pain it caused me in last couple weeks)
<Ch^W>
How many gigs of RSS per thread does NodeJS 20 require these days?
<JaMa>
around 2G
* Ch^W
cringes...
<JaMa>
if you mean for building it
<Ch^W>
yeah
<Ch^W>
For Hardknott allocating 2.5 Gigs of RAM per CPU core seems to be about the right ratio for stuff that includes NodeJS and OpenJDK.
<JaMa>
chromium does the same, so on 64t threadripper I'm triggering OOMK with 128G ram if I don't restrict PARALLEL_MAKE a bit
<JaMa>
pressure regulation unfortunatelly doesn't help much with OOMK and also now needs different thresholds for kirkstone and nanbield
<Ch^W>
Yeah, PSI is not a silver bullet. It is an awesome feature, but not a silver bullet.
<JaMa>
it could be much better with PSI-aware job-server for make and ninja, regulating on bitbake task granularity is too coarse (when such tasks are nodejs and chromium do_compile)
<JaMa>
as all looks fine until these 2 get scheduled at the same time (which is quite typical in all of my builds)
<Ch^W>
Those lovely progress bars from cmake builds are just divine. Almost worth wrapping my head around yet another build tool.
<JaMa>
wrap it around bazel and you'll gladly return to CMake :)
mvlad has quit [Remote host closed the connection]
amitk_ has quit [Ping timeout: 255 seconds]
<moto-timo>
JaMa: I guarantee that 99% of all YP consumers are not ready for even NodeJS 18. but hey, who's counting
<moto-timo>
Anyone that complains about any build system should be required to use bazel.
<moto-timo>
"Node.js 21 will replace Node.js 20 as our ‘Current’ release line when Node.js 20 enters long-term support (LTS) later this month. As per the release schedule, Node.js 21 will be ‘Current' release for the next 6 months, until April 2024."