-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Thu, Feb 13, 2025 at 10:09:21PM +0000, 'grandbronze111' via qubes-devel wrote: > I'm using the mailing list as I can't use GitHub with Tor Browser. > > This mailing list post is a succinct version of my forum thread > https://forum.qubes-os.org/t/mac-randomization-is-flawed-proposed-new-solution/32150 > > https://github.com/QubesOS/qubes-issues/issues/938 needs to be reopened. > > We can’t rely solely on either udev (Tails approach) or NetworkManager (Qubes > approach) to ensure the true MAC address is never leaked. Some drivers > restore to the true/permanent MAC on sleep/suspend and udev doesn't handle > this. NM, in normal operation, brings the NIC 'up' with the true MAC address > which can result in leaks. NM also restores to the true MAC address in other > cases, such as when the user restarts the NM service to apply an updated > config. Even if NM did do everything properly, drivers can still leak the > true MAC address.
Device gets re-initialized after suspend, and NM does re-apply its configuration on resume, including relevant MAC randomization setting. _If_ that doesn't work (the above looks like just speculation, not actual observed behavior), then relevant piece may need fixing. But none of those pieces are qubes-specific. If setting MAC is broken either in some specific driver or in Network Manager, then it needs to be reported in appropriate place (the driver maintainers or NetworkManager bug tracker). > As originally proposed in /issues/938, patching drivers is the only way to do > this without the possibility of leaks occurring. Patching these drivers is > usually very simple, as most of them already support generating random MACs > for situations where the EEPROM MAC is invalid. If driver maintainers would accept such patch, then maybe. We are not going to carry such patch ourselves. > As an initial proposal, I suggest Qubes hosts a contrib repository where > these patches can be submitted. Then, Qubes can build a separate kernel with > these modified drivers that users can optionally set for their NetVM. I can > do the necessary work, but I would want Qubes to confirm how they would like > this structured so that it will be accepted. I have built a modified kernel > locally with qubesbuilderv2, but I'm not familiar enough with Qubes' build > system to say for certain what the best way to do all of this is. It may be > that there's an entirely different way to supply the modified drivers that > makes more sense than building a separate kernel. See https://docs.kernel.org/process/submitting-patches.html how to submit Linux patches. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmevI8oACgkQ24/THMrX 1yyJawf+K7IGlmRzuulRDIiCVtqGjnvj8E3/BsYrqPYruchmFS5JF/Lbj4eqHNHR CNLpRLrShWgATu9/4GABAUTBInIohP6d0CK4WiCtLxZyJyjpEr879k324TyiXPf5 c42GQ8HzKItagUYY7d+T7TO+J2PTVGVAoAnT8VQtDMUK+/9B3G6oQGsqtSCi3Wm3 imz5MvTPmnTeJErUCyvKITN/TX9WEum0+On9H1SvypjbLqpxBjTmBj2ybP65wr/d +jyPg6LYznSd+4jciRv7AqhA63DT85EydqMSsfZVDPJTJOYwzJ9CCcMC8IpVs+0S bns0MvlGCgfF7tESpPeaAxzZ7WCrxQ== =8Rfy -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/qubes-devel/Z68jygcJfZbSekzN%40mail-itl.
