Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ext4: Copied preprocessed code when it shouldn't #17

Open
marcosps opened this issue Apr 29, 2024 · 3 comments
Open

ext4: Copied preprocessed code when it shouldn't #17

marcosps opened this issue Apr 29, 2024 · 3 comments
Labels
bug Something isn't working kernel Issue found on Linux Kernel

Comments

@marcosps
Copy link
Collaborator

When trying to create a livepatch for function ext4_reconfigure, file fs/ext4/super.c, on upstream, it generates the following code:

__attribute__((gnu_inline)) __attribute__((unused)) __attribute__((no_instrument_function)) static inline bool ext4_has_feature_metadata_csum(struct super_block *sb) {                                                                                                   
    return ((EXT4_SB(sb)->s_es->s_feature_ro_compat & ((__le32)(__u32)(1024))) != 0);                                                
}  

The original code, a macro in this case, has the following code on file fs/ext4/ext4.h:

...
static inline bool ext4_has_feature_##name(struct super_block *sb) \                                                                 
{ \                                                                                                                                  
        return ((EXT4_SB(sb)->s_es->s_feature_compat & \                                                                             
                cpu_to_le32(EXT4_FEATURE_COMPAT_##flagname)) != 0); \                                                                
} \     
...

For this livepatch specifically it should be good to import the code as it was written, instead of copying the preprocessed one. When a livepatch is generated for multiple architectures, resolving cpu_to_le32 is problematic, since it changes according the machine architecture it's being generated on.

@marcosps marcosps added bug Something isn't working kernel Issue found on Linux Kernel labels Apr 29, 2024
@giulianobelinassi
Copy link
Collaborator

Just a note:

It is not safe to extract code from x86_64 architecture to run on PPC, as the define paths would differ. The correct way of doing this would be to extract from both arch and compare the differences. If there are none, then it is safe to use on both, else you may need to merge the things together.

@marcosps
Copy link
Collaborator Author

I agree. As we are using clang-extract as an experiment for kernel livepatches, maybe it would be nice to add some info about possible differences on the clang-extract README.md. Would it be safe to target PPC for example when generating code using clang-extract using cross compilation on a x86_64 machine? This would nice to have in the README as well.

@giulianobelinassi
Copy link
Collaborator

Cross-compilation from x86_64 to another arch is safe.

In any case, yes. The readme should have instructions about that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working kernel Issue found on Linux Kernel
Projects
None yet
Development

No branches or pull requests

2 participants