Automated rollback of commit 9c2174446004e4f712cb566ade05721be6653ed0.

PiperOrigin-RevId: 559063479
Change-Id: I4ccf8d5717b8669921c5b580eb415975cd625eaf
This commit is contained in:
Wiktor Garbacz 2023-08-22 03:59:08 -07:00 committed by Copybara-Service
parent 8a6b689c29
commit e75be07bb0
2 changed files with 22 additions and 8 deletions

View File

@ -29,6 +29,21 @@
namespace sapi {
namespace {
bool SealFile(int fd) {
constexpr int kMaxRetries = 10;
for (int i = 0; i < kMaxRetries; ++i) {
if (fcntl(fd, F_ADD_SEALS,
F_SEAL_SEAL | F_SEAL_SHRINK | F_SEAL_GROW | F_SEAL_WRITE) == 0) {
return true;
}
}
return false;
}
} // namespace
EmbedFile* EmbedFile::instance() {
static auto* embed_file_instance = new EmbedFile();
return embed_file_instance;
@ -57,13 +72,11 @@ int EmbedFile::CreateFdForFileToc(const FileToc* toc) {
return -1;
}
// Ideally, we'd seal the file here using fcntl(). However, in rare cases,
// adding the file seals F_SEAL_SEAL | F_SEAL_SHRINK | F_SEAL_GROW |
// F_SEAL_WRITE results in EBUSY errors.
// This is likely because of an interaction of SEAL_WRITE with pending writes
// to the mapped memory region (see memfd_wait_for_pins() in Linux'
// mm/memfd.c). Since fsync() is a no-op on memfds, it doesn't help to
// ameliorate the problem.
// Seal the file
if (!SealFile(embed_fd.get())) {
SAPI_RAW_PLOG(ERROR, "Couldn't apply file seals to FD=%d", embed_fd.get());
return -1;
}
// Instead of working around problems with CRIU we reopen the file as
// read-only.

View File

@ -249,8 +249,9 @@ bool CreateMemFd(int* fd, const char* name) {
// Usually defined in linux/memfd.h. Define it here to avoid dependency on
// UAPI headers.
constexpr uintptr_t MFD_CLOEXEC = 0x0001;
constexpr uintptr_t MFD_ALLOW_SEALING = 0x0002;
int tmp_fd = Syscall(__NR_memfd_create, reinterpret_cast<uintptr_t>(name),
MFD_CLOEXEC);
MFD_CLOEXEC | MFD_ALLOW_SEALING);
if (tmp_fd < 0) {
if (errno == ENOSYS) {
SAPI_RAW_LOG(ERROR,