Jarkko Sakkinen
Posts
4543Following
316Followers
477OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
jarkko
I got already boot time back down to 8.7s which is only 1.7s more given the encryption overhead but I think we can do better:
https://lore.kernel.org/linux-integrity/D4DICMSZJXCG.8X4SU03FPJ4X@kernel.org/
I noticed a lot of round trips to TPM with small requests of random data by hwrng.
So next thing I'm gonna do to improve performance is to create a fixed size chip pool for random and fill that and serve most of random data requests by fetching from internal pool.
This could have a small effect on improving the boot time but further this should factor out radically the amount of wait states caused by TPM after the boot while system is running :-)
Uh oh, now I really need to get off to the gym! Got stuck in LKML.
#linux #kernel
https://lore.kernel.org/linux-integrity/D4DICMSZJXCG.8X4SU03FPJ4X@kernel.org/
I noticed a lot of round trips to TPM with small requests of random data by hwrng.
So next thing I'm gonna do to improve performance is to create a fixed size chip pool for random and fill that and serve most of random data requests by fetching from internal pool.
This could have a small effect on improving the boot time but further this should factor out radically the amount of wait states caused by TPM after the boot while system is running :-)
Uh oh, now I really need to get off to the gym! Got stuck in LKML.
#linux #kernel
0
1
4
@ljs I've implemented all that in user space for https://github.com/enarx/enarx :-) It perfectly highlights the SGX issue (which might be unsolvable by kernel). Easy to recall because I draw almost the same picture to my notebook when I did it: https://github.com/enarx/mmledger/blob/main/src/lib.rs
Not proud of it all., On the contrary this exactly the code that I'd like to see some day deleted. Since SGX is the lowest common denominator we also need to use it with AMD SNP, Intel TDX and ARM CCA if gets ever supported. Not sure if it is possible but would be nice to delegate merging of VMAs back to the kernel (which is not possible as of today).
I'm sure whatever merge code is kernel is factors more mature and better but this is unfortunately as of today only piece of code that works :-)
Not proud of it all., On the contrary this exactly the code that I'd like to see some day deleted. Since SGX is the lowest common denominator we also need to use it with AMD SNP, Intel TDX and ARM CCA if gets ever supported. Not sure if it is possible but would be nice to delegate merging of VMAs back to the kernel (which is not possible as of today).
I'm sure whatever merge code is kernel is factors more mature and better but this is unfortunately as of today only piece of code that works :-)
0
0
0
Jarkko Sakkinen
jarkko
Edited 10 months ago
to the monday gym, have got my weekly exercise routine back after some struggle ;-)
0
0
1
Jarkko Sakkinen
jarkko
Edited 10 months ago
If Intel goes down, are there any other players than TSMC and Samsung doing semiconductors? That could have even geopolitical impact given their neighboring countries, close proximity of all manufacturing in the world etc.
IMHO that is pretty worrying situation, more even so than possibility of Intel going down.
Like for instance consider this. A single nuke could destroy the whole in the world within minutes with that physical topology.
IMHO that is pretty worrying situation, more even so than possibility of Intel going down.
Like for instance consider this. A single nuke could destroy the whole in the world within minutes with that physical topology.
1
0
0
@ljs That said, obviously core mm would better suit to any "random intel feature" as long as it has a user base :-) it is as random or not random feature as e.g. oracle database. Or any other random user for that matter. I think all three are equivalent.
I get your point tho, mm cannot be tuned to SGX at expense of Oracle DB, some random user or any other work load. Still I thought that it is good to a biennial query at LKML if there is something new in mm that could help to improve this part of the driver or something not too intrusive that could be changed in mm :-) I think this somewhat fair standing point.
I get your point tho, mm cannot be tuned to SGX at expense of Oracle DB, some random user or any other work load. Still I thought that it is good to a biennial query at LKML if there is something new in mm that could help to improve this part of the driver or something not too intrusive that could be changed in mm :-) I think this somewhat fair standing point.
1
0
0
Jarkko Sakkinen
jarkko
I don’t get this Sudoku. How do I detach that display? The replacement is on left but there is like no attachment points in it.
0
0
0
Jarkko Sakkinen
jarkko
Edited 10 months ago
One of the most useful purchases this year: rocket sockets. Could not live without:
https://peperspedals.bigcartel.com/product/rocket-sockets
https://peperspedals.bigcartel.com/product/rocket-sockets
0
0
0
@ljs Well as long as VMA setup stays static it's not a big of a deal. And I get the point. It just happens SGX ranges are always managed from in VMA level as they were regular memory but obviously core mm cannot trust on that even if that was the case.
I just check periodically if we could improve something in this area that's all.
I just check periodically if we could improve something in this area that's all.
1
0
1
@ljs Yeah, you know I fully get it :-) While doing SGX I really turned all rocks in the area of merging VMA's ,PAT etc. And I had Sean, Dave and Borislav helping me out while doing that.
I don't have better vision how to make SGX merging work without user space help so not blaming you guys really either.
If I did blame the implementation, the patches would be out there for review already... And we were able to nail virtualization, NUMA and cgroups for SGX and people do use it so it's exactly just a manageable glitch. World is not perfect :-)
I don't have better vision how to make SGX merging work without user space help so not blaming you guys really either.
If I did blame the implementation, the patches would be out there for review already... And we were able to nail virtualization, NUMA and cgroups for SGX and people do use it so it's exactly just a manageable glitch. World is not perfect :-)
0
0
0
@ljs I guess it could be perhaps treated separately in "E820" (or today EFI provided) code and mark it with something else than PFNMAP. But it also depends on direct PFN manipulation in order to evict pages between regular and enclave memory (PRMRR registers preserve fixed amount of memory for SGX use).
I guess with SGX we can conclude that mm subsystem does not fully scale to that task but since it is only of its kind how it uses memory I neither expect it to 🤷 And really cannot put any blame because I have no suggestions how to exactly fix mm.
I mean if there was two subsystems then I could imagine something like VM_PFNMAP_MERGEABLE or similar VMA type: SGX memory areas as far as merging VMA's go work 1:1 as regular memory areas. It is the access to them that differs.
I guess with SGX we can conclude that mm subsystem does not fully scale to that task but since it is only of its kind how it uses memory I neither expect it to 🤷 And really cannot put any blame because I have no suggestions how to exactly fix mm.
I mean if there was two subsystems then I could imagine something like VM_PFNMAP_MERGEABLE or similar VMA type: SGX memory areas as far as merging VMA's go work 1:1 as regular memory areas. It is the access to them that differs.
1
0
0